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

Forking this out into a separate thread, as I think it deserves some
additional consideration.

On Thu, Oct 16, 2014 at 5:05 AM, Roger Hågensen <rescator@emsai.net> wrote:

> There is also legitimate needs for being able to edit the password field
> from a script.
> I have a custom login system (that is currently in public use) that takes
> the password, does a HMAC on it (plus a salt and some time limited
> info). This allows login in without having to send the password in the
> clear. It's not as secure as https but it's better than plaintext.
>

Sigbjørn Vik (CC'd) suggested something similar in a previous conversation.

I think it's probably reasonable for a password field to specify that some
sort of operation be done on its value before it's sent over the network.
It's not clear to me exactly what would be necessary in order to prevent
replay attacks, but it seems quite possible for the site to ask the browser
to salt and hash the value in some known way before passing it on:

If user agents offered some sort of well-understood set of operations that
could be performed on a password before sending it over the wire, they
could potentially avoid ever knowing the password, which might be nice
(though it would certainly require substantial rewrites on their backends).

As a hand-wavey strawman that I haven't thought too much about:

* Server stores credentials as `sha512(password + username)`.
* Server provides a nonce ('a') as part of a sign-in form, saves that nonce
for the given session, and points to the username field as a salt.
* The user agent injects a nonce ('b') into the sign-in form in some
well-known field, and fills the password field with `sha512(sha512(password
+ username) + a + b)`.

The server now has everything it needs to compute the same hash as the
client. If the hashes match, yay. Sign the user in.

There are certainly better ways to do this, perhaps even some that wouldn't
require really significant work on the server side to support.

Any limitations on form manipulations should be based on same origin
> limitations instead, such that only a javascript with the same origin as
> the html with the form can read/write/manipulate the form.


This is a very difficult problem, as evidenced by Chrome and Firefox's
struggles to allow extensions to bypass CSP. It's tough to keep track of
the origin of an action, especially when that action is the result of an
event handler or some other asynchronous action that no longer has a clear
call stack back to it's originator.

It's unlikely to be implemented. CSP locking down the sources of script is
the best we can offer, I think.

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Received on Thursday, 16 October 2014 07:52:50 UTC