Write-only form fields (was Re: Proposal for a credential management API.)

Forking this out into a separate thread, as I think it's a great idea, but
tangential to the original proposal. :)

TL;DR: I put together a strawman based on these suggestions which defines a
'writeonly' attribute on HTMLInputElement:
http://projects.mikewest.org/credentialmanagement/writeonly/, WDYT?

On Thu, Jul 31, 2014 at 6:37 PM, Brian Smith <brian@briansmith.org> wrote:
> And/or the password form could be annotated with an attribute that
> indicates for which domain an XHR should be allowed to submit the
> password to. And/or, you could have a submit-password CSP directive to
> indicate which domains passwords are allowed to be submitted to.

We already have 'form-action', I think that serves the purpose suitably
well:
https://w3c.github.io/webappsec/specs/content-security-policy/#directive-form-action

> particular, if we are worried about XSS stealing passwords then we
> have to consider the possibility that XSS has inserted a form without
> any httponly attributes being used, right?

Correct. I think we'd also want a new CSP directive which toggles
write-only status for all password fields on a given page: how about
http://projects.mikewest.org/credentialmanagement/writeonly/#credentials-directive
?

> I was thinking the placeholder would be a base64url-encoded
> cryptographically-random nonce of sufficient length, so that the
> browser can replace the placeholders within arbitrary HTTP requests,
> regardless of (most) use of JS to mangle forms before submitting them,
> and without worrying about replacing the wrong part.

I agree, but I don't think we need to specify this normatively. User agents
will know what they can easily replace and what they can't, if they choose
to go down a nonce route.

> This would work with (C) too, would it not? It may be a good idea to
> add an attribute to XHR to trigger such replacement, so that the
> browser doesn't have to attempt substitution for every HTTP request.

I think we'd be able to get away with relying on magical UA behavior: if
the browser process hands a nonce to a renderer, it can set a flag, and
then look at POSTs generated by the page. As soon as one POST contains the
nonce, clear the flag. My suspicion is that most login pages don't do much
POSTing, so the overhead would be trivial.

I'd prefer that approach, because I don't think we want to expose the
actual mechanics to the web. The website shouldn't need to care about
whether or not the password it's received is the "real" password or not.

> Based on a quick read of Mike's proposal, this would require Mike's
> proposed API to change to pass around tokens that represent passwords,
> instead of the password values themselves. This would add
> complication, but it would be useful.

This approach adds complication to the UA's implementation, but shouldn't
add complexity to the site consuming the API.


> This would probably not interact well with use of the WebCrypto API to
> encrypt the contents of input fields (passwords, credit card numbers,
> etc.) before submission.

I'm pretty happy to break that use case, given that the credential API I've
proposed is locked to secure origins. There's no advantage to using
WebCrypto to doubly encrypt the password in this context, and I don't think
it's something we should encourage.

Thanks!

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