free source authentication script

[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.
hehe...

 

[Tassilo v. Parseval]

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

 

[gnari]

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

 

[Mark Clements]

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

 

[Tassilo v. Parseval]

Also sprach Mark Clements:

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

 

[gnari]

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

 

[Mark Clements]

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

 

[Tore Aursand]

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.

 

[Tassilo v. Parseval]

Also sprach Tore Aursand:

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

 

[Robin]

Also sprach Robin:

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]

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

 

[Paul Lalli]

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]

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.

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?

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

 

[Gunnar Hjalmarsson]

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.

 

[Paul Lalli]

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

 

[Jim Cochrane]

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.

 

[Gunnar Hjalmarsson]

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.

 

[John J. Trammell]

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

 

[Jim Cochrane]

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

 

[Robin]

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