forms and secure authentication

[Eric Soroos]

> >Auth Scheme
> >Person logs in with username "username", password "greatPassword".
> > Web page javascript creates MD5 has from password before sending to server.
> >Only encrypted password is sent, and that only once.

> 
> This really isn't any more secure than simply sending the password in the 
> clear.  (The one advantage is that for people who use the same password for 
> many different services, a successful attacker could impersonate them only 
> for this service, and would not gain the actual password which could be 
> used elsewhere.  So this is a step better than sending a cleartext 
> password.)

If you're going to write login algorithims that rely on some for of hashing or encryption, PLEASE look at relevant RFCs for similar services so that you don't get bitten by subtle of not so subtle bugs. 

Maybe I should rephrase that. If you're going to create algorithims that use crypto, please look at current practice. 

Some things that you may want to worry about:

Replay attacks, both login and cookie. 
Comprimised clients.
Cleartext transmission of password.
Transmission of password equivalents. 
Effect of NAT/Proxy gateways. 

In general, you have 4 options:

1) store plaintext pw, transmit hash(pw + salt), hash your copy of the pw with the salt and compare.
2) store hash(pw + salt) transmit plaintext pw, hash it with salt and compare.
3) store plaintext pw, transmit plaintext pw, compare. (What you're doing currently) 
4) More complicated systems like challenge-response, certs, etc. 

Of course, where I sey transmit plaintext, that may be through an ssl tunnel, in which case it's only plaintext to the server, not to snoopers.

eric