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

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

>
> > 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.
>
> There are various ways to get around this. E.g. have a stored password
> hash of hash2(hash1(password+public_salt)+private_salt), and ask the
> browser to compile hash1 using the public salt, and then the server will
> apply hash2 itself. Details can be worked out, but will get more complex
> the more types of hashes we want to be support.


My point here is that many websites may not have the ability to migrate to
this format. If today your hashes are not stored in a format that would be
supported, you could only migrate if you see users plain text passwords and
can recompute the hash.


> >     > 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.
>
> True. I am saying that hashing should primarily be used for passwords
> that aren't typed. And that we should create a system which induces
> people to not have to type (nor remember) their passwords, a system
> which could be applied fully automated and guaranteed securely, through
> the browser, including in the face of e.g. XSS on the front end of the
> server.
>

Even if we do this, the encryption argument applies to other things, like
credit cards.


> > 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.
>
> A token to log in? Isn't that the same as a password, alternatively a
> long lived cookie? If we send this token in clear text, and it has the
> power to log the user in, this is essentially the same as sending a
> short-lived password in clear text.


This gives the site more information about the origin of the credientials.
For example, if a user has a phone and a laptop both of which store a token
and XSS allows the compromise of one of the tokens, we could tell exactly
where the credentials came from.

Received on Thursday, 16 October 2014 13:41:53 UTC