On May 4, 2009, at 4:48 PM, Mike Lewis wrote:
Having passwords encrypted in MD5 sent in plaintext is probably almost worse than just sending them in plaintext.
I was about to say something similar, until I read more about Paul's scheme. :)
Paul is using a hand-shake method whereby the password MD5 is only transmitted when the user first creates their account, *or* when they change their password. Other than that, the password *nor* the MD5 of the password is every transmitted at all. Instead the system relies on the client processing information, I believe this is an accurate summary:
* Server knows MD5* Client will know MD5 once it hashs the users password on the client- side
Server includes in the form, a hidden field containing a timestamp, for use with their password, so client-side Javascript will return as the password value:
MD5(timestamp + MD5(password))Since the server knows the MD5(password) as well, it then does the same calculation, and see if they have the same value. If not, it can generate a new timestamp to ask for on the next request.
Obviously, given the weakness of MD5, SHA-1 should be used (or even SHA-256). But other than that, this really does seem *waaaaaay* better than transmitting passwords in the clear every single time a user logs in. This way the crypted password is only sent in the clear for new account creation, and password changing (and even then, only the crypted form *never* the clear-text).
For better security, the server should also provide a random salt for the original creation as well, such that a plan SHA/MD5 version of *just* the password will never be sent.
Once the scheme is updated to SHA-1 or SHA-256, I think it'd be a great alternative to sending passwords in the clear over non-SSL as Paul suggests.
Cheers, Ben
smime.p7s
Description: S/MIME cryptographic signature
