CREDENTIAL: Apply hash functions before POSTing passwords?

[mikewest]

From @mikewest on April 21, 2015 11:26

It might be interesting to allow sites to hash a password before sending it over the wire for comparison. Maybe something like:

credential.send({
  'url': 'https://example.com/signin-endpoint',
  'hash': {
    'algorithm': 'bcrypt',
    'options': {
      'rounds': 12,
      ...
    }
  }
});

Copied from original issue: w3c/webappsec#288

[mikewest]

From @jmajnert on April 21, 2015 12:38

What problem does this solve? Wouldn't this effectively replace the password with its hash for all intents and purposes?

[mikewest]

Some sites have a flow where they do client-side hashing of sensitive information (passwords, credit cards, etc) before passing it to a backend. This can have regulatory/compliance benefits, as the frontend servers never see the plaintext the user typed. @domenic suggested something similar in an earlier bug that I now can't find.

[mikewest]

From @jmajnert on April 21, 2015 12:51

Oh, so this is not only about passwords, but other fields as well. I get it. Thanks

[mikewest]

Well, the client-side hashing is about fields in general. This particular bug is about PasswordCredential objects, which only hold passwords.

[mikewest]

From @pfreitag on April 21, 2015 13:27

On Tue, Apr 21, 2015 at 8:38 AM, Janusz Majnert notifications@github.com wrote:

What problem does this solve? Wouldn't this effectively replace the password with its hash for all intents and purposes?

If the salt contains a timestamp, the server can make sure the timestamp is within acceptable bounds to limit the validity period as well.

[mikewest]

From @hillbrad on April 21, 2015 16:33

I'm not a great fan of this strategy generally, because it makes the hash equivalent to the password. Part of the point of hashing is that the hash is "safe to disclose" (for some values of safe, Moore's law being what it is) because it is a one-way function. If you allow submission of a hash over the wire, then you lose that property and any leak of a verification database becomes equivalent to a leak of the plaintext credentials. See, e.g., the years and years of pain using the NTOWF this way has caused Windows.

On Tue, Apr 21, 2015 at 6:27 AM Pete Freitag notifications@github.com wrote:

On Tue, Apr 21, 2015 at 8:38 AM, Janusz Majnert notifications@github.com wrote:

What problem does this solve? Wouldn't this effectively replace the password with its hash for all intents and purposes?

If the salt contains a timestamp, the server can make sure the timestamp is within acceptable bounds to limit the validity period as well.

— Reply to this email directly or view it on GitHub https://github.com/w3c/webappsec/issues/288#issuecomment-94793463.

[mikewest]

From @domenic on April 21, 2015 17:10

Yeah, this seems pretty sketchy to me. "regulatory/compliance benefits", indeed...

[mikewest]

@domenic: You raised it as an issue that we'd probably need to address (or at least, this is what I thought you were referring to in https://github.com/w3c/webappsec/issues/241#issuecomment-93440298)! :)

shrug My impression is that folks are doing this today, and they won't be able to if we lock password away inside a POST-only interface. Since I'm not particularly interested in not doing that, providing some mechanism for folks with this use case to continue using it seems reasonableish.

But yeah, this isn't something I want for v1. This is just a tracking bug to leave room for it in the future.

[mikewest]

From @domenic on April 21, 2015 18:5

Yeah I guess I did :). It was more part of a general point though that "people do lots of crazy things before sending the credentials to the server and we have to decide whether to enable that or draw the line, and if so where."