Thanks for your reply Wiggins d'Anconia. I understand the part about just setting the cookie to an empty value, but I don't understand the part about the secret key and a check failing. Could you explain further? When would this happen: initially setting the cookie's value, or everytime you check the cookie to see if the username and password are correct?
Remember to group reply so everyone can help and be helped. Essentially you would take the username and password once, at that time you create a hashed value of some user information such as an id # or the username if you want, etc. and any other information you want, IP and expiration time, plus a "secret" key, basically any phrase that your site knows that no one else does. (insert rant about how that is not secure because anyone with access to the code can see it, blah blah blah...) and you hash the values together (check out Digest::MD5 or Digest:SHA1 for two good hashing modules, I prefer the second for other reasons). Then each time you want to verify the user is who they say they are you take the information they provide (aka their username or id as mentioned above) and the hash you generated above which can be stored in teh same cookie and then you create the hash in the same manner as before and check to see that the hashes match. (There is a much better explanation on this with code samples in the O'Reilly Apache Modules with Perl and C book.)
It is *very difficult* (nothing is completely secure) for the user to create a hash that will be authentic based only on the knowledge they have, aka what the cookie looks like and what their user id is. They could guess that you are using a hash of something fairly easily, and that if their user id is 245 that there is probably user ids 1-244 but they can't guess your secret passphrase so to recreate a hash is nearly impossible.
This also prevents the need to be passing the username/password around other than on initial login, and is much better than simply setting a single cookie and checking for its existence for obvious reasons.
Examples:
#
# Method to generate authentication cookie
#
use Digest::SHA1;
sub authentication_string {
my $self = shift;
my $uid = $self->id; my $time = time; my $expires = 2592000;
my $data = join(':', CONFIG_AUTH_KEY, $time, $expires, $uid); my $hash = Digest::SHA1::sha1_hex($data);
return "uid=$uid time=$time expires=$expires hash=$hash"; }
The above code assumes a 'User' object with an instance method of 'id' that returns the user's id, and a constant CONFIG_AUTH_KEY that contains the site's "secret" key.
I leave the method for validating the authentication to the reader (mostly because mine has lots of non-standard error checking in it).
Thoughts/comments from any of the gurus?
http://danconia.org
-----Original Message----- From: Wiggins d'Anconia [mailto:[EMAIL PROTECTED] Sent: Thursday, September 18, 2003 6:17 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Cookies
------------------------------------------------ On Wed, 17 Sep 2003 20:33:00 -0800, "Alejandro Chavarria - CyPage" <[EMAIL PROTECTED]> wrote:
Hey,
I have a script and I want to allow an administrator log on to it. Once logged in they can change things... etc. Basically stuff I don't want
other
people to be able to do. I have decided that cookies is the best way to
go.
I've been looking and looking on the internet for a way to add a "logout" button in the script that will delete the cookie that has the username and password so they are essentially logged out. I have read that you can
fill
in the "expires" field in with 1. a date in the past (ie. -1d) or 2. the word "now". I have heard about problems with both these methods.
What do you suggest?
In general I would reset the cookie to the empty string with no expiration date, and then on the other end your check should be that the cookie exists *and* has a correct value. Then make the "correct" value very hard (because nothing is 100% secure) to figure out how to generate. In other words hash it with a secret key or some such that only the server has. So the cookie exists but the check fails, and as soon as the session ends the cookie is no longer stored.
http://danconia.org
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
