I'm not a guru... ;-P But I was in a similar situation some months ago. First of all I would tell Alejandro not to send Username-Password with the cookie, but a Session ID, but I arrived late.
There are two modules (at least I only know them) to handle "sessions" with cookies. Apache::Session and CGI::Session Even been them complete solutions (I think so, I haven't really used them), not all systems support them, that's my case, my web host doesn't has any of them installed (That's because I haven't used them). My suggestion is to create sessions, using cookies and generating the ID as described in the previous message (not mine). But in Alex situation he might want to give access only to the Administrator, wich makes things easier. I am not sure right now, but I believe that I found useful hints in an online course, from Ovid Check this link http://users.easystreet.com/ovid/cgi_course/ -rm- ----- Original Message ----- From: "Wiggins d'Anconia" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, September 20, 2003 10:24 AM Subject: Re: Cookies > Alejandro Chavarria - CyPage wrote: > > 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] > > -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
