Sean, thanks for the suggestion. I have the following comments (my first comment on here, please instruct me if I get the style wrong):
>> Why? The server can first try comparing the submitted password to the >> stored hash, then if that fails, hash the submitted password and compare >> that to the stored hash. > > Imagine the use case where a user joins a site on a legacy browser. The > legacy browser sends the un-hashed password. They then attempt to login > using a modern browser, which correctly hashes the password before sending > it. The authentication will fail. I see a theoretical (but potentially major) problem accepting a) Accepting the hashed value blindly and b) Multiple passwords being accepted by the server. Currently my browser accepts the value "password1" to an <input name="pass" type="password"/> field, sends it in the POST data as "&pass=password1" and my serverside encrypts it to the (non-salted for ease of example) MD5 "7c6a180b36896a0a8c02787eeafb0e4c". I find a lot of safety in the knowledge that I can't do anything malicious with a well-encrypted password even though I can read the encrypted value clearly in the DB. If, however, my browser made the request should include "&pass=7c6a180b36896a0a8c02787eeafb0e4c" then I can copy and paste your hashed password into a curl request and log in as you, or do the same after manipulating the <input/> field to remove hashing instructions. > There needs to be a way for the server to distinguish when the hash has been > correctly applied. As mentioned in a previous e-mail, I would imagine this > work being done by a server-side framework automatically (eventually). There is a theoretical and pedantic use-case where I as a user can have a 32 char hex-decimal password which looks like an MD5. In this case how would any framework distinguish between my browser's MD5 and my intentionally written 32 char hex-deci password? To summarise: I feel that client-side hashing does not add the security it seems to on the surface and it would add some potential new issues. A developer who is able to store a password on the server-side should be encouraged to encrypt it on the serverside and I feel that this addition would encourage excited HTML5 on-lookers into what I would consider to be a false-sense of security. Mat Carey
