[ale] User authentication in web app
Chris Fowler
cfowler at outpostsentinel.com
Tue Mar 16 09:15:08 EST 2004
The reason the passwd was stored in the cookie encrypted is because our
CGI system did not track cookies. All data for a session was stored in
the cookie as a blowfished hex string.
We also checked against IP. So if the IP was different than that would
immediately invalidate the cookie.
On Tue, 2004-03-16 at 09:08, George Carless wrote:
> > I want to do a similar thing in the webapp. I plan on using a table in
> > our database to store user accounts for the application. So during the
> > login phase I'll get their password and do a select on that table. I
> > could simply use the password() function in mysql like this:
> >
> > select * from users where PASSWORD like PASSWORD('value');
>
> You should key against both the username and the password. Also, I'd
> recommend using something like md5() rather than password(), for stronger
> passwords.. and it's probably best to create the md5 sum within your
> application server rather than at the database, to avoid passing
> unencrypted passwords around. And don't use "like" on a known value; use
> "=".
>
> > Next question I have is on session tracking. I can then use the servlet
> > session API and then add this encrypted string to the cookie. Every
> > time the user access a page I can then do this:
> > select * from users where PASSWORD like PASSWORD('value');
>
> I would think you would be better off storing a table of known valid
> sessions, keyed perhaps against user id, session id, IP address. If you
> absolutely must store the password in the cookie (which I don't think you
> should), make sure you're storing a hash of it and NOT anything that can
> be used to determine the original password. And to be honest I would
> probably say, with my usual disclaimer that I'm not trying to be rude (I'm
> just British) that if you're needing to ask these questions then you're
> probably not *that* concerned about mega security beyond good basic
> precautions, in which case you might be as well off just checking against
> a userid/sessionid/ip address match. I can't see any gain from storing
> the password in the cookie, except insomuch as it provides another key to
> check against to prevent people from faking/guessing session variables.
> But you should probably store some other arbitrary value if you're looking
> for that, anyhow.
>
> If anyone disagrees massively with me then please chip in, especially
> since my own session handling routines are gradually becoming a
> spaghetti-like mess of code and could probably use a rework some time
> soon.
>
> Cheers,
> --George
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
More information about the Ale
mailing list