[whatwg] Hashing Passwords Client-side

[Sean Connelly]

Thank you for your input.  I had forgotten about the <input type="image">
fields.

Yes, as these issues have been brought up, I've also imagined additional
disadvantages as well.  For documentation purposes, here are some additional
items to consider if this topic comes up again:

1. I'm not clear how a server-side framework could automatically apply
hashes to password fields from legacy browsers.  The framework would not be
able to identify which form values were password fields (and therefore,
which ones it would need to hash).

2. Some use cases for password fields are simply to mask what the user is
typing, and SHOULDN'T be hashed.  For example, I have seen
financial/government sites that mask SSN input through a password field.
 Their intention is never to hash the value.

3. As Mat brought up, I think it is reasonable to imagine webmasters who
think client-side hashing is good enough.  This can give them a false sense
of security.

Ultimately, I think my next step is to develop a JavaScript library that
implements the behavior (by perhaps injecting ".hash" form values).  This
can help me to figure out the details in private, and see if this is
worthwhile to include in the HTML standard.  I may return to WHATWG in the
future with my results if I feel there is a tangible benefit.

Thanks again for everyone who contributed to help me think through this
problem.

~Sean

On Fri, Jun 17, 2011 at 2:34 PM, Aryeh Gregor <Simetrical+w3c at gmail.com>wrote:

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