free source authentication script

Discussion in 'Perl Misc' started by Robin, May 5, 2004.

  1. Robin

    Robin Guest

    www.infusedlight.net/robin/temp/auth.txt

    Comments on this? The bottom two subs are meant for the script that the
    auth.pl script goes to and the way the cookies are set, makes it secure in
    that if someone forgets to logout of the administration or other script that
    auth.pl goes to and someone else points their browser to that script that
    auth points to, it will simply redirect them to whatever page the webmaster
    chooses, ie: auth.pl again or the entry point to auth.pl. Some of you may
    have been doing this very same thing, pointing your browser to the admin
    script or something similar, and I spent an hour improving the script so
    this major security flaw won't be present. At least now my site won't be
    defaced in this form, anyway.
    hehe...

    --
    Regards,
    -Robin
    --
    [ webmaster @ infusedlight.net ]
    www.infusedlight.net
    Robin, May 5, 2004
    #1
    1. Advertising

  2. Also sprach Robin:

    > www.infusedlight.net/robin/temp/auth.txt
    >
    > Comments on this? The bottom two subs are meant for the script that the
    > auth.pl script goes to and the way the cookies are set, makes it secure in
    > that if someone forgets to logout of the administration or other script that
    > auth.pl goes to and someone else points their browser to that script that
    > auth points to, it will simply redirect them to whatever page the webmaster
    > chooses, ie: auth.pl again or the entry point to auth.pl. Some of you may
    > have been doing this very same thing, pointing your browser to the admin
    > script or something similar, and I spent an hour improving the script so
    > this major security flaw won't be present. At least now my site won't be
    > defaced in this form, anyway.


    So after a successful login procedure, you do a redirect to the actual
    CGI script (e.g. admin.pl). Fine as far as that goes. However, how does
    this script figure out that a user is properly authenticated? A visitor
    could always call admin.pl directly.

    Now I see that auth.pl does two other things: It creates a file
    "Loggedinfile.log" and sets a cookie. Would admin.pl use these two
    things to determine whether a user is logged in? I hope not.
    "Loggedinfile.log" only exists once which means that anybody could log
    in as long as at least one person is already authenticated. Doing
    authentication based on a cookie is a very bad idea as well, as cookies
    reside on the client machine and anybody could create such a thing
    manually.

    Tassilo
    --
    $_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
    pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
    $_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
    Tassilo v. Parseval, May 5, 2004
    #2
    1. Advertising

  3. Robin

    gnari Guest

    "Robin" <webmaster @ infusedlight . net> wrote in message
    news:c7a18h$pk7$...
    > www.infusedlight.net/robin/temp/auth.txt
    >

    [snip bragging about very weak security feature]

    > ... At least now my site won't be
    > defaced in this form, anyway.


    is this an invitation ?

    gnari
    gnari, May 5, 2004
    #3
  4. Tassilo v. Parseval wrote:

    > in as long as at least one person is already authenticated. Doing
    > authentication based on a cookie is a very bad idea as well, as cookies
    > reside on the client machine and anybody could create such a thing
    > manually.

    There are ways of doing it securely: the eagle book has a good example, which basically includes
    a checksum of the cookie's data (eg username,date,ipaddress) combined with a secret. The
    integrity of the cookie can thus be verified when it is resubmitted to the server.

    Mark
    Mark Clements, May 5, 2004
    #4
  5. Also sprach Mark Clements:

    > Tassilo v. Parseval wrote:
    >
    >> in as long as at least one person is already authenticated. Doing
    >> authentication based on a cookie is a very bad idea as well, as cookies
    >> reside on the client machine and anybody could create such a thing
    >> manually.

    > There are ways of doing it securely: the eagle book has a good example, which basically includes
    > a checksum of the cookie's data (eg username,date,ipaddress) combined with a secret. The
    > integrity of the cookie can thus be verified when it is resubmitted to the server.


    Well, naturally it can be done via some digest-mechanisms. However, does
    this also work with the constant cookie

    cookie (-name=>'Log', -value=>'', -path=>'./');

    that Robin uses?

    :)

    Tassilo
    --
    $_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
    pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
    $_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
    Tassilo v. Parseval, May 5, 2004
    #5
  6. Robin

    gnari Guest

    "Mark Clements" <> wrote in message
    news:4098a57b$...
    > Tassilo v. Parseval wrote:
    >
    > > in as long as at least one person is already authenticated. Doing
    > > authentication based on a cookie is a very bad idea as well, as cookies
    > > reside on the client machine and anybody could create such a thing
    > > manually.

    > There are ways of doing it securely: the eagle book has a good example,

    which basically includes
    > a checksum of the cookie's data (eg username,date,ipaddress) combined with

    a secret. The
    > integrity of the cookie can thus be verified when it is resubmitted to the

    server.

    yes, but that is definitively not the case here!

    gnari
    gnari, May 5, 2004
    #6
  7. Tassilo v. Parseval wrote:
    > Well, naturally it can be done via some digest-mechanisms. However, does
    > this also work with the constant cookie
    >
    > cookie (-name=>'Log', -value=>'', -path=>'./');
    >
    > that Robin uses?
    >
    > :)

    Er, as stands, no. I'm not really bothering to read his code anymore as it makes my ears bleed
    and my comments tend to be rather repetitive. I thought it would be more helpful to lead him
    towards doing cookie authentication properly rather than just saying "it's a bad idea". If you
    like we can take bets on the chances of him implementing it properly :)

    Mark
    Mark Clements, May 5, 2004
    #7
  8. Robin

    Tore Aursand Guest

    On Tue, 04 May 2004 22:22:45 -0800, Robin wrote:
    > www.infusedlight.net/robin/temp/auth.txt


    A short summary:

    * You're _still_ not indenting your code properly.
    * You're _still_ not using 'strict' (or 'warnings').
    * You're _still_ not checking the outcome of 'open()'.
    * Yoy're _still_ using 'exit' where it's inappropriate.
    * You're _still_ calling subroutines with '&', without
    knowing really why (obviously).
    * You're _still_ mixing HTML and Perl code.
    * You're _still_ not validating the data you are using
    throughout the script.
    * You're _still_ not listening to the people in this
    group. Why do you bother at all? You don't want to
    learn anything, obviously!?

    As for this particular script:

    * Do you know how cookies work? You're definitely not
    using cookies the way they should (...) be used.
    * It is possible to access (and download) the "private"
    files you are using. How secure is that?

    Could you _please_ do something with _all_ of my comments before you post
    another useless [1] script?

    [1] Not really, as it works as a reminder on how to _not_ to things, but
    you should state so in your postings and scripts;

    "This code most probably doesn't work as expected and has been
    written to demonstrate on how _not_ to do things in Perl."

    Thanks.


    --
    Tore Aursand <>
    "The pure and simple truth is rarely pure and never simple." (Oscar
    Wilde)
    Tore Aursand, May 5, 2004
    #8
  9. Also sprach Tore Aursand:

    > On Tue, 04 May 2004 22:22:45 -0800, Robin wrote:
    >> www.infusedlight.net/robin/temp/auth.txt

    >
    > A short summary:
    >
    > * You're _still_ not indenting your code properly.


    Well, it was indented this time. The curlies were just arranged in a
    rather odd and - for me anyways - unpleasant way.

    > * You're _still_ mixing HTML and Perl code.


    I'd rather gnaw my arm off than recommending the use of a templating
    system to anyone. I tried quite a few and hated each one of them.

    Perl already is the best templating system around with all its
    capabilities of interpolating variables and code in strings. Templating
    systems tend to come with their own syntax. This is a waste of time when
    considering that one already knows Perl.

    A necessary corollary from that is that HTML and Perl code will be
    mixed. It's the same with templating systems. There you'll have HTML
    mixed with the templating system's code. I fail to see the advantage of
    that.

    Tassilo
    --
    $_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
    pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
    $_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
    Tassilo v. Parseval, May 5, 2004
    #9
  10. Robin

    Robin Guest

    "Tassilo v. Parseval" <> wrote in message
    news:c7a2jr$1bs0g$-berlin.de...
    > Also sprach Robin:
    >
    > > www.infusedlight.net/robin/temp/auth.txt
    > >
    > > Comments on this? The bottom two subs are meant for the script that the
    > > auth.pl script goes to and the way the cookies are set, makes it secure

    in
    > > that if someone forgets to logout of the administration or other script

    that
    > > auth.pl goes to and someone else points their browser to that script

    that
    > > auth points to, it will simply redirect them to whatever page the

    webmaster
    > > chooses, ie: auth.pl again or the entry point to auth.pl. Some of you

    may
    > > have been doing this very same thing, pointing your browser to the admin
    > > script or something similar, and I spent an hour improving the script so
    > > this major security flaw won't be present. At least now my site won't be
    > > defaced in this form, anyway.


    > Now I see that auth.pl does two other things: It creates a file
    > "Loggedinfile.log" and sets a cookie. Would admin.pl use these two
    > things to determine whether a user is logged in? I hope not.
    > "Loggedinfile.log" only exists once which means that anybody could log
    > in as long as at least one person is already authenticated. Doing
    > authentication based on a cookie is a very bad idea as well, as cookies
    > reside on the client machine and anybody could create such a thing
    > manually.



    Your right, I didn't think of that at all, but still, who's gonna go into
    the temp internet folder and create a cookie? At least not most users. The
    way it does it is that admin.pl checks for the loggedinfile.log file and the
    cookie using the sub "login" and if one of them isn't there it redirects
    back to another page: ie: the login page. If someone is already
    authenticated, someone else won't be able to access admin.pl directly
    because they won't set the cookie unless they know the password, or create
    the cookie manually, because the cookie is set when the password is typed in
    right or when the password is initially set... When someone logs out of the
    admin script the static cookie, Log is set to a null value so it will not be
    read.
    -Robin
    Robin, May 5, 2004
    #10
  11. Robin

    Robin Guest

    "Tore Aursand" <> wrote in message
    news:p...
    > On Tue, 04 May 2004 22:22:45 -0800, Robin wrote:
    > > www.infusedlight.net/robin/temp/auth.txt

    >
    > A short summary:
    >
    > * You're _still_ not indenting your code properly.


    It's indented in the way I like it. How would you define "properly"?

    > * You're _still_ not using 'strict' (or 'warnings').


    Most of my code does and this one will too, as soon as I get around to it.

    > * You're _still_ not checking the outcome of 'open()'.


    Yeah, I figure that there won't be too much of a race condition or anything
    like that because there's only one person who accesses the code who runs the
    files, unless there's more than one person who has the password and even so
    it's minimal...

    Also, this is a modified older script, I will get around to it, and I
    apologize for not "doing my best" before posting it.

    > * Yoy're _still_ using 'exit' where it's inappropriate.


    Where? :)

    > * You're _still_ calling subroutines with '&', without
    > knowing really why (obviously).


    I'll grant you that, I have to read perlsub.

    > * You're _still_ mixing HTML and Perl code.


    Well, as tassilo said, what's the point of not using perl? Perl is great for
    interpolation of variables in html code and stuff.

    > * You're _still_ not validating the data you are using
    > throughout the script.


    What do you mean exactly?

    > * You're _still_ not listening to the people in this
    > group. Why do you bother at all? You don't want to
    > learn anything, obviously!?
    >
    > As for this particular script:
    >
    > * Do you know how cookies work? You're definitely not
    > using cookies the way they should (...) be used.


    How should they be used?

    > * It is possible to access (and download) the "private"
    > files you are using. How secure is that?


    Not the password file, I've already tried that... and the loggedinfile.log
    file means nothing if you download it. If you found a way to download the
    password file, let me know where it is in the code.


    -Robin
    Robin, May 5, 2004
    #11
  12. Robin

    Paul Lalli Guest

    On Wed, 5 May 2004, Robin wrote:
    >
    > "Tassilo v. Parseval" <> wrote in message
    > news:c7a2jr$1bs0g$-berlin.de...
    > >
    > > Now I see that auth.pl does two other things: It creates a file
    > > "Loggedinfile.log" and sets a cookie. Would admin.pl use these two
    > > things to determine whether a user is logged in? I hope not.
    > > "Loggedinfile.log" only exists once which means that anybody could log
    > > in as long as at least one person is already authenticated. Doing
    > > authentication based on a cookie is a very bad idea as well, as cookies
    > > reside on the client machine and anybody could create such a thing
    > > manually.

    >
    >
    > Your right, I didn't think of that at all, but still, who's gonna go into
    > the temp internet folder and create a cookie? At least not most users.


    Of course *most* users aren't going to do that. *Most* users aren't
    trying to hack your site! You don't program securely for *most* users -
    you program securely for the few users who *are* trying to be malevolent.
    The fact that you keep taking these completely unnecessary risks with the
    security of anyone foolish enough to use your scripts continues to prove
    that you are NOT ready to be releasing code to the public. It's
    irresponsible and rude, frankly.

    Paul Lalli
    Paul Lalli, May 5, 2004
    #12
  13. Robin

    Paul Lalli Guest

    On Wed, 5 May 2004, Robin wrote:

    > "Tore Aursand" <> wrote in message
    > news:p...
    > > On Tue, 04 May 2004 22:22:45 -0800, Robin wrote:
    > > > www.infusedlight.net/robin/temp/auth.txt

    > >
    > > A short summary:
    > >
    > > * You're _still_ not indenting your code properly.

    >
    > It's indented in the way I like it. How would you define "properly"?
    >


    How many people have told you to read perldoc perlstyle so far? You
    clearly haven't done it. From said doc:

    Regarding aesthetics of code lay out, about the only thing
    Larry cares strongly about is that the closing curly bracket
    of a multi-line BLOCK should line up with the keyword that
    started the construct. Beyond that, he has other
    preferences that aren't so strong:

    o 4-column indent.

    o Opening curly on same line as keyword, if possible,
    otherwise line up.

    o Space before the opening curly of a multi-line BLOCK.

    Therefore:

    if ($foo) {
    bar();
    }

    or

    if ($foo)
    {
    bar();
    }

    are good. What you do:

    if ($foo)
    {
    bar();
    }

    is not.


    > > * You're _still_ not using 'strict' (or 'warnings').

    >
    > Most of my code does and this one will too, as soon as I get around to it.
    >


    Why on earth would you cause that much extra work for yourself? Do you
    truly not see that having strict and warnings enabled at the beginning of
    development will take you *far* less time than trying to go back later and
    making everything work with strict enabled?

    > > * You're _still_ not checking the outcome of 'open()'.

    >
    > Yeah, I figure that there won't be too much of a race condition or anything
    > like that because there's only one person who accesses the code who runs the
    > files, unless there's more than one person who has the password and even so
    > it's minimal...


    Do you honestly believe that's the only reason open() might fail? If
    so... damn, I don't even know what to say to that. And even if it *was*
    the only reason - you again decide that the risk is small enough to not
    bother simply typing 'or die'? That's one of your biggest problems, Robin
    - that you consider there to be "acceptable risks" when it comes to
    program security, functionality, and robustness. There aren't.


    > Also, this is a modified older script, I will get around to it, and I
    > apologize for not "doing my best" before posting it.


    STOP FRIGGIN' DOING THAT. In the first place, no one here is ASKING to
    see your scripts - you're posting these of your own accord, much like a
    cat putting a dead mouse on the door, hoping we all say "ohhh, isn't that
    wonderful!". If you insist on deluging us with all these scripts no one
    cares about, you could *at least* have the decency to post the final
    drafts rather than works in progress!


    Excuse me while I go take several long deep breaths.

    Paul Lalli
    Paul Lalli, May 5, 2004
    #13
  14. Paul Lalli wrote:
    > That's one of your biggest problems, Robin - that you consider
    > there to be "acceptable risks" when it comes to program security,
    > functionality, and robustness. There aren't.


    Yes, there are. If there weren't, we all should better cease with
    programming.

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
    Gunnar Hjalmarsson, May 5, 2004
    #14
  15. Robin

    Paul Lalli Guest

    On Wed, 5 May 2004, Gunnar Hjalmarsson wrote:

    > Paul Lalli wrote:
    > > That's one of your biggest problems, Robin - that you consider
    > > there to be "acceptable risks" when it comes to program security,
    > > functionality, and robustness. There aren't.

    >
    > Yes, there are. If there weren't, we all should better cease with
    > programming.


    Yes, you're correct, there are of course some acceptable risks. I
    overspoke. My point should have been that Robin considers far too many
    unacceptable risks acceptable, and doesn't bother eliminating far too many
    of the easily avoided risks.

    Paul Lalli
    Paul Lalli, May 5, 2004
    #15
  16. Robin

    Jim Cochrane Guest

    In article <>, Paul Lalli wrote:
    > On Wed, 5 May 2004, Robin wrote:
    >
    >> "Tore Aursand" <> wrote in message
    >> news:p...
    >> > On Tue, 04 May 2004 22:22:45 -0800, Robin wrote:
    >> > > www.infusedlight.net/robin/temp/auth.txt
    >> >
    >> > A short summary:
    >> >
    >> > * You're _still_ not indenting your code properly.

    >>
    >> ...

    >
    >> > * You're _still_ not checking the outcome of 'open()'.

    >>
    >> Yeah, I figure that there won't be too much of a race condition or anything
    >> like that because there's only one person who accesses the code who runs the
    >> files, unless there's more than one person who has the password and even so
    >> it's minimal...

    >
    > Do you honestly believe that's the only reason open() might fail? If
    > so... damn, I don't even know what to say to that. And even if it *was*


    Perhaps he's operating on a different plane of reality, using a system that
    never has file storage failures, files are always readable and writable by
    everyone, files are never locked, etc.


    --
    Jim Cochrane;
    [When responding by email, include the term non-spam in the subject line to
    get through my spam filter.]
    Jim Cochrane, May 5, 2004
    #16
  17. Paul Lalli wrote:
    > Gunnar Hjalmarsson wrote:
    >> Paul Lalli wrote:
    >>> That's one of your biggest problems, Robin - that you consider
    >>> there to be "acceptable risks" when it comes to program
    >>> security, functionality, and robustness. There aren't.

    >>
    >> Yes, there are. If there weren't, we all should better cease with
    >> programming.

    >
    > Yes, you're correct, there are of course some acceptable risks. I
    > overspoke. My point should have been that Robin considers far too
    > many unacceptable risks acceptable, and doesn't bother eliminating
    > far too many of the easily avoided risks.


    Then we are agreed. :)

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
    Gunnar Hjalmarsson, May 5, 2004
    #17
  18. On 5 May 2004 14:01:24 -0600, Jim Cochrane wrote:
    > Perhaps he's operating on a different plane of reality, using a system
    > that never has file storage failures, files are always readable and
    > writable by everyone, files are never locked, etc.


    Sure, Robin is really some Vingean Entity from the outer reaches of the
    Galaxy.

    Welcome to the Unthinking Depths, dude. :)

    NO CARRIER
    John J. Trammell, May 5, 2004
    #18
  19. Robin

    Jim Cochrane Guest

    In article <-swifto.com.invalid>, John J. Trammell wrote:
    > On 5 May 2004 14:01:24 -0600, Jim Cochrane wrote:
    >> Perhaps he's operating on a different plane of reality, using a system
    >> that never has file storage failures, files are always readable and
    >> writable by everyone, files are never locked, etc.

    >
    > Sure, Robin is really some Vingean Entity from the outer reaches of the
    > Galaxy.
    >
    > Welcome to the Unthinking Depths, dude. :)
    >
    > NO CARRIER
    >


    I was thinking, perhaps, another universe, where the laws of physics are
    entirely different :)

    --
    Jim Cochrane;
    [When responding by email, include the term non-spam in the subject line to
    get through my spam filter.]
    Jim Cochrane, May 5, 2004
    #19
  20. Robin

    Robin Guest

    "Paul Lalli" <> wrote in message
    news:...
    > On Wed, 5 May 2004, Robin wrote:
    > >
    > > "Tassilo v. Parseval" <> wrote in message
    > > news:c7a2jr$1bs0g$-berlin.de...
    > > >
    > > > Now I see that auth.pl does two other things: It creates a file
    > > > "Loggedinfile.log" and sets a cookie. Would admin.pl use these two
    > > > things to determine whether a user is logged in? I hope not.
    > > > "Loggedinfile.log" only exists once which means that anybody could log
    > > > in as long as at least one person is already authenticated. Doing
    > > > authentication based on a cookie is a very bad idea as well, as

    cookies
    > > > reside on the client machine and anybody could create such a thing
    > > > manually.

    > >
    > >
    > > Your right, I didn't think of that at all, but still, who's gonna go

    into
    > > the temp internet folder and create a cookie? At least not most users.

    >
    > Of course *most* users aren't going to do that. *Most* users aren't
    > trying to hack your site! You don't program securely for *most* users -
    > you program securely for the few users who *are* trying to be malevolent.
    > The fact that you keep taking these completely unnecessary risks with the
    > security of anyone foolish enough to use your scripts continues to prove
    > that you are NOT ready to be releasing code to the public. It's
    > irresponsible and rude, frankly.


    maybe...www.infusedlight.net clearly states that my scripts might be
    insecure.
    -Robin
    Robin, May 5, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. mutant
    Replies:
    0
    Views:
    419
    mutant
    Nov 27, 2005
  2. george
    Replies:
    0
    Views:
    1,066
    george
    Aug 29, 2008
  3. Rajat
    Replies:
    3
    Views:
    673
    Jorgen Grahn
    Jan 8, 2010
  4. VYAS ASHISH M-NTB837
    Replies:
    2
    Views:
    528
    Jan Kaliszewski
    Jan 7, 2010
  5. mohammed_a_o
    Replies:
    0
    Views:
    252
    mohammed_a_o
    Nov 30, 2010
Loading...

Share This Page