[whatwg] Hashing Passwords Client-side

[Mat Carey]

Thanks Sean,

> The server SHOULD still hash the password it receives, before storing it in the database (i.e., the client would send a hashed password, and the server would hash the hash)

I agree, but if the server-side hashing should be implemented regardless of whether the client-side hashes then are we truly adding a feature? If not then I fear we are merely adding issues caused by legacy browsers co-existing with current/future browsers as highlighted in your original post (disadvantage 2 stated "Server-side code might be complicated for dealing with legacy, non-hashing browsers").  

> Your use case is possible, where a naive webmaster blindly copies the client-hashed value into the database.  Just as webmasters today blindly copy the plain-text password into databases.  The proposal helps to add security to these (unfortunate) use cases.


My (potentially controversial) opinion is that even though these 'unfortunate' cases may seem to benefit from a client-side hash the same webmasters may be unaware of the need for legacy support and that client-side hashing will not secure their passwords at a DB/HTTP level.  I fear we would be encouraging more webmasters/developers to follow the client-side hashing will be to the detriment of server-side hashing.  A developer who is able to implement a database storage in a server-side language should be able to encrypt in that language, if this is true they should be strongly encouraged to do this on the server-side and not confused by adding client-side hashing.  I feel client-side hashing implies to the partially-informed webmaster/developer that server-side hashing can be replaced by client-side hashing which would lead to more security holes across the web.

>  the browser should synthesize a new form value to submit, which has the benefit that JavaScript could be used by legacy browsers to "upgrade" their behavior.

There is no guarantee that your user is using Javascript, which means this upgrade would not be available and it accidentally becomes the same as TJ's suggestion:

(from Tab Atkins Jr. 16th June 2011 22:08:36 GMT+01:00)
> you can just ignore legacy browsers and store the passwords directly.  Those older browsers will just have security vulnerabilities.


The problem I see here is that I can register using one browser (e.g. FF3.6 with JS off or an accessible browser which doesn't run JS) and my password is sent (and potentially stored) in plain text (described as 'just have security vulnerabilities'), then try to login in after the FF comes out supporting this feature and I will be unable to log in because my hashed password that is now sent does not equate to the unhashed version which is stored.  This problem also exists the other way around and pushes the developer/webmaster into the position where they need to allow pre-hashed and plain-text passwords to be sent from the browser.  I feel a can of worms could be opened and not easily closed.  

I am of the opinion that the cross-browser/legacy-browser issues that _could_ come from this are very hard to recover from and _even if_ it were fully cross-browser and legacy-browser compatible I don't see a strong enough reason to rely upon it as users would be able to tamper with the fields and request data mitigating any potential security benefit.

NOTE: I am assuming it goes without saying that SSL should be used for registrations, logins etc. _even if_ this client-side hashing is present.

To qualify some of my position I feel it's worth mentioning that I have consulted on a large site (which was created years before I was involved) where there are is a mix of MD5'd and plain text passwords - it's a situation I would not want to encourage anyone to get themselves into and some of the circumstances I have commented on have been real problems for that site.

Mat Carey