Login and Session Thoughts

Martin A has asked for the wisdom of the Perl Monks concerning the following question:

Hi fellow monks. A time ago I asked for the wisdom of monks in this write up. The answers i got mainly pointed out that letting the server set a session cookie to the client and then remembering witch sessions are logged in and witch are not would be the best way. But when I made some more research I found out that perlmonks.org does the other way around. They set a cookie with the user name and password and then verify that on every page request. Then i thought to my self, if the gods of perl them self do it this way, maybe this is the best way. I would really like someone with experience on this subject pointing out some ups and down with both solutions, because this really got me confused.

// Martin

Comment on Login and Session Thoughts

Replies are listed 'Best First'.
Re: Login and Session Thoughts by fongsaiyuk (Pilgrim) on Dec 04, 2000 at 19:55 UTC
If you'd like to dig a little deeper on how perlmonks.org works check out chromatic's discussion over on everydevel.com. (hopefully this is the same chromatic here! :) ) Anatomy of an Everything Request I know... FMTYRWTK Another method, kinda building on what Fastolfe said, is how the phplib library for PHP works. It sets a unique SessionID in a cookie which is then tied to a record in a SQL database where the session variable are held. The ID is created relatively randomly and then encoded with a "secret password". The password is put into the phplib Session object definition. I'm pretty sure that the md5 algorithm is used in the encoding process. The weakness is keeping the file that contains the secret password safe from the whily crackerz. So, I think, it's like this: md5( <random number> + <secret password>) = SessionID fongsaiyuk	[reply]
Re: Login and Session Thoughts by Fastolfe (Vicar) on Dec 04, 2000 at 19:24 UTC
A username is just a session identifier that also contains useful information. Since it can be guessed so easily, though, you go on step further and supplement it with something extra, and a password works just as well. This is also less secure than a random state ID, since the information is being passed in the clear over the 'Net, and cookies aren't generally treated as secure by most browsers. Generally it's better to authenticate the user relatively securely, pass back a reasonably un-guessable session ID, and use that for the duration of the session (expiring it after too much time has elapsed between visits). Associate that ID internally with the username. I think this is just how "Everything" works (the codebase this site is built from). That doesn't mean it's approved by the higher-ups on the site or that they'd have done it that way if they had to choose.	[reply]
(bbq) Re: Re: Login and Session Thoughts by BBQ (Curate) on Dec 04, 2000 at 22:16 UTC
I second Fastolfe's suggestion with one minor variation: Instead of setting one cookie witht the username + password, what I usually do is set two cookies with different expires. Username expires whenever you want, and password exprires at the end of the browser session. Unless it were a low security requirement site (such as perlmonks, we aren't exactly the NSA here :)) I would never keep the full combination of usernames and passwords on the cookie at the client. Its way too easy for someone to use the same computer later, inspect the cookies and use that information to impersonate the user. Just my US$0.02. #!/home/bbq/bin/perl # Trust no1!	[reply]
Re: Login and Session Thoughts by merlyn (Sage) on Dec 04, 2000 at 19:45 UTC
You just need to ensure that there's enough stuff coming from the browser that you can verify that they are who they say they are. That could be username+password, or randomly-generated-hard-to-guess session ID. And remember, it doesn't have to be a cookie. See my previous post on making HTTP stateful. -- Randal L. Schwartz, Perl hacker	[reply]


Do you know where your variables are?
	PerlMonks