[whatwg] Hashing Passwords Client-side

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

Received on Friday, 17 June 2011 02:17:51 UTC