Re: [whatwg] Hashing autofilled data (was Re: Proposal: Write-only submittable form-associated controls.)

On Thu, Oct 16, 2014 at 2:46 PM, Sigbjørn Vik <sigbjorn@opera.com> wrote:

> On 16-Oct-14 14:22, Ben Maurer wrote:
> > I think it'd be worth supporting encrypting the password.
>
> That would be a valuable goal, but doesn't mean hashing isn't also.
>

Agreed.


> > 1) It is unlikely that whatever standard format the browser supports
> > will be exactly how passwords are hashed today. It is possible to
> > migrate hashes (if the user doesn't use the new hash format, on the
> > first login, take their plain text password and re-hash it.
> > alternatively, you can make your new format an extra hash on top of the
> > old format). Both of these require either an unhashed password or a
> > password hashed in some custom format.
>
> To avoid this, a browser would have to be able to support a set of
> operations. E.g. SHA-2 on top of SHA-1 on top of MD5 applied 32 times.
> (In some cases, best practice is to run a hash function multiple times.)


What about a salt that only exists on the server? I believe that the
ability to customize the format could meet the needs of many sites, but
it'd be worth supporting encryption for sites where the existing format
wasn't compatible with this method.

> 2) Some sites may take measures to handle typos. For example, if your
> > password is MyPassword and you log in with the password mYpASSWORD,
> > Facebook lets you log in. The password does not need to be stored in
> > plain text. You can simply do the reverse-all-caps transform and re-hash
> > the password to verify. In theory a site could solve this by storing
> > multiple hashes.
>
> A solution like this makes less sense on user typed passwords, it makes
> the most sense for password manager applied passwords, which is what we
> should advocate in any case. A solution like this protects the password
> from e.g. XSS, but XSS can intercept a password while it is being typed
> instead. A password manager could also warn if the hashing instructions
> suddenly disappeared, while this would be harder to do for manager-less
> types of logins.
>

Not sure I get this comment. For a user typed password, they might
accidentally use capslock.

Could we handle the password manager case by allowing the website to give
the browser a token to use to log in again. Eg, on a successful login, the
browser could send a meta tag:

<meta name="logincredentials" content="username:bmaurer;password:<base64
string">. Rather than autofilling the user's password the browser would
autofill this token. This avoids the browser ever storing the users
password.

Received on Thursday, 16 October 2014 12:55:03 UTC