OK, I know this is getting a little off-topic, but I think security is a big
issue, especially with newbies like myself, and deserves some good
discussion. Also, there's probably not a perl-cgi-beginners-security list,
nor should there be.
I looked at the perlmonks article, and had some trouble making sense of it,
but here is my idea:
1) User first signs up, gives a password. The password is passed through
MD5
to make a digest, and the digest is stored in a password database.
2) A session ID is generated and written to the cookie (instead of the
password), and to a database. The ID is itself digest based on username,
time, and another string, $rand.
3) The script reads the session ID from the cookie, compares it to the
database, and if it is found, then the user is considered logged in
4) When the user logs out, the session ID is deleted from the DB, and any
other session IDs older than, say, 1 day are deleted from the DB as well, to
take care of people who don't log out properly.
Is making the session ID a digest just extra processing, or does it have a
point?
My application is for a student group I'm involved in, and I'm guessing
other student groups might enjoy trying to hack in and put bad data into the
database I'm interacting with, to make my group look bad. Kinda reminds me
of West Side Story, but a lot geekier and with less singing.
Thanks for any help,
Ryan
----- Original Message -----
From: Curtis Poe <[EMAIL PROTECTED]>
To: CGI Beginners <[EMAIL PROTECTED]>
Sent: Wednesday, August 08, 2001 12:42 PM
Subject: RE: Cookies and Security
> --- Joel Hughes <[EMAIL PROTECTED]> wrote:
> > Curtis,
> > are you sure that sending the digest back to the client in cookie form
is a
> > good idea?
> >
> > I mean, if I were a hacker, could I not register and then retrieve the
> > digest - you then have the plain text and the cipher text. (admittedly
you
> > would have to know that whats in your cookie is a digest rather than
another
> > form of session id but stilll...)
> >
> > I'm not sure how easy it is then discover which algorithm is used when
you
> > have the plain & cipher but, seeing as MD5, is fairly popular - that
might
> > be a good starting point for the hacker to mount an assault on
discovering
> > the function.
> >
> > joel
>
> Joel,
>
> That's a good question. The idea here is that the best security protocols
should have their
> details openly available to anyone and still be relatively hard to crack.
The solution is
> suggested, while not the best, is still relatively secure if implemented
properly. However, if
> you're protecting banking information or medical records, I'd opt for an
even more secure
> mechanism.
>
> Regarding your concerns, here's one scenario of what happens, if I am a
cracker:
>
> 1. I register for a site several times and each time I am sent back a
cookie with a fixed length
> value. Hmm... that suggests to me that it might be a digest.
>
> 2. Since I already know the plaintext and now have the ciphertext, I can
run my plaintext through
> various known digest algorithms to see if I have a quick match. If not,
that suggests that
> they're either using an algorithm that I'm not familiar with or they've
added some extra data to
> my password that makes a brute force more difficult.
>
> 3. If I can't get the quick match, I'm forced to do a more rigorous
analysis of the
> ciphertext/digest or try to gain more information about the system (see if
I can grab source code
> or use social engineering to get info). I could also try to brute force
the extra data, if I
> thinks it's being added.
>
> Sending back a password digest then relies on two secrets: the password
and $rand text that's
> added (I say $rand text, but it should never change. I mean rand as in
'difficult to guess').
> Since it's a one-way function, *in theory* it should be difficult to crack
password even without
> the extra text that's added ... assuming that a secure password policy is
put in place -- but such
> policies are usually a joke.
>
> That being said, I do agree with Joel that sending back a password digest
is not the most secure
> method. It's not a *bad* method, if implemented properly, but it was a
quick and easy fix for the
> original question. A better method is to send back a session ID that's
completely unrelated to
> the information that needs to be secured. That's why I suggested reading
> http://www.perlmonks.org/index.pl?node_id=101247. It relies on randomly
generated session ID's to
> track users. It's much more secure, but it's also more difficult to
implement properly if you're
> new to Perl.
>
> Cheers,
> Curtis Poe
>
> =====
> Senior Programmer
> Onsite! Technology (http://www.onsitetech.com/)
> "Ovid" on http://www.perlmonks.org/
>
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.yahoo.com/
>
> --
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
