[whatwg] Hashing Passwords Client-side
Mat Carey
mat at matcarey.co.uk
Fri Jun 17 02:17:51 PDT 2011
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
More information about the whatwg
mailing list