[whatwg] Hashing Passwords Client-side

[Aryeh Gregor]

On Thu, Jun 16, 2011 at 5:39 PM, Daniel Cheng <dcheng at chromium.org> wrote:
> A variation of this idea has been proposed in the past but was largely seen
> as undesirable--see
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-May/026254.html. In
> general, I feel like the same objections are still true of this proposal.

This proposal is considerably better formulated than that one was.
But yes, in the end, the only real benefit is that the user can
confirm that their original plaintext password can only be retrieved
by brute-forcing the hash, which protects them only against reuse of
the password on different sites.  So on consideration, it will
probably lead more to a false sense of security than an actual
increase in security, yes.  It no longer seems like a good idea to me.

On Thu, Jun 16, 2011 at 7:28 PM, Sean Connelly <sean at pbwhere.com> wrote:
> This strikes me as abnormal; I'm not aware of the browser injecting form
> values for any other functionality.  However, one benefit of this method is
> that a developer can create a JavaScript file to drop in to pages that will
> perform hashing for legacy browsers.  The JavaScript could check to see if
> the browser performs hashing, and if not, add listeners on all form
> submissions.  It could hash the password fields prior to submission, and
> inject the the synthesized form value.  This would provide a path for legacy
> support.

Side point: there are some existing cases where magic form values are
injected.  <input type=image> submits .x and .y values, for instance.

> The disadvantage to this approach is that, years from now, the default may
> be compromised (like md5).

Another side point: MD5 is actually not compromised for the purposes
of password storage.  There are collision attacks, but no preimage
attacks.  Even MD4, which has had a working collision attack since
1995, still has nothing more than a theoretical preimage attack.  So
this isn't a huge worry in practice.  Collision attacks aren't
relevant to our use-case.  (But don't use MD5 for things like
certificate signing where collision resistance is important!)

> Yes, the site should.  In fact, the webmaster should be doing additional
> hashing on the server side.  However, we can't control that.  If the
> webmaster is clueless and just stores the data directly (which webmasters do
> in the real world, unfortunately), at the very least, this solution will
> improve security.

Only in one very narrow case: it will prevent a passive network
attacker or someone who compromises the database from learning the
original plaintext password without brute-forcing the hash.  It will
not stop them from logging in as the user on the same site, only from
logging in as the user on other sites.  On the other hand,
administrators would be likely to assume that because the passwords
now look like gibberish, they must be secure, which is totally wrong.

Proper use of server-side hashing will leak no info about passwords to
an attacker at all without brute-forcing, and proper use of
client+server-side hashing will leak no info about passwords to a
passive network attacker without brute-forcing.  Making it easy to do
hashing badly will discourage people from doing it well.

> I've read some of the thread... Please keep in mind that my proposal is not
> a catch-all solution to password management.  It is intended to solve one
> specific problem.  It is intended to be incremental progress.

The problem is it solves much less of the problem than hashing is
supposed to solve, but to the uninitiated it looks the same as a real
hashing scheme.  It gives a false sense of security that probably
outweighs any actual security benefit (which is very limited).