[whatwg] Hashing Passwords Client-side

[Sean Connelly]

Hi Mat,

The simple solution to your problem is: 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).  Ideally,
all servers should be doing this, with per-user salts.  However, the reality
is that many servers do not, or they use compromised hash functions
(specifically, md5 with no salt).

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.

Ideally, the client AND server would hash the password.  We cannot control
the server, but we can control the client.  So this proposal attempts to
standardize the client-side hashing.

Please note an additional benefit: with this proposal, passwords are not
sent as plain-text over HTTP.  This improves security for many use cases
(with the exception of HTTPS, and webmasters who already use JavaScript to
locally hash the password before sending).

> 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?

In the proposal, I suggested a new header value to be sent by the client
when the password is hashed: X-Password-Hash: 1

Tab Atkins Jr. suggested, instead of a new header, that 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.

Thank you for the feedback.

~Sean


On Fri, Jun 17, 2011 at 5:17 AM, Mat Carey <mat at matcarey.co.uk> wrote:

> 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
>