[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