forms and secure authentication

[Eric Soroos]

Brad,

> As I looked through my documentation, I realized that I had realized that. I
> had been doing Eric's #3, but switched to #1 - kind of. I store a hash that
> is the md5 of a (md5(password) + salt). I did this because if the database
> is compromised the passwords are already obfuscated.
> 

What it sounds like is:

client types password.
client machine does md5(password)
transmit md5(password)
your server does md5(md5(password)+salt)
your server compares to DB. 

This is equivalent to:

client types magic string
transmit magic string
server computes md5(magic string + salt), compares.

Where magic string is either a password or md5(password) (i.e. a password equivalent) The only difference is what the password looks like. 

As far as I know, you have two choices:  You can transmit a hashed password, or you can store a hashed password. If you try to have both, one of your hashes works out to be a password equivalent. 

One example of secure login is APOP, which is a hashed system for pop email. 
In the negotiation, the server sends a banner that is globally unique, with time and host stamping. The client takes this banner and hashes md5(password+banner) and returns that to the server. The server then compares the hash with what it thinks it should be. Someone monitoring the system doesn't gain anything useful from the hash, since the banner will be different if they try to login. 

 (note that there are probably attacks against this if you can change the packets going each way, but that's a harder attack than sniffing. It's also possible to mount a dictionary attack against the hashed password+known banner) 

You may want to check out digest authentication. It's what the control panel uses. It's a basic authentication with challenge-response, iirc. Your other good option is ssl for the transport.  Note also that cookies have a lot of the same issues as transmitting passwords, as they can also be authentication tokens.

eric