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

On Fri, Aug 1, 2014 at 5:37 AM, Mike West <mkwst@google.com> wrote:
> On Thu, Jul 31, 2014 at 6:37 PM, Brian Smith <brian@briansmith.org> wrote:
>> 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?

There is some tension here between making things password-specific and
simple vs. making them general and harder to understand. Defining this
as a mechanism to protect only passwords keeps it simple. But, it
seems wrong to have a way to protect passwords but not credit card
numbers and social security numbers and other very sensitive input
fields that don't use <input type=password>.

>> 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 am not sure that looking only at POSTs is sufficient. Also, some
websites put login forms on every page (whether they should or not).
But, I agree that it would be better to avoid the need for the
attribute if we can.

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

I suspect some websites will want to disable some aspects of their
form validation code if they are dealing with placeholders instead of
the real values, especially if the mechanism is extended to things
such as social security numbers and credit card numbers.

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

I think it is fine to say that this would be mutually-exclusive with
WebCrypto-based approaches to encrypting passwords in the short term.
However, I think it is too early in the history of WebCrypto to say
that there's advantage to encrypting passwords (or other sensitive
information like credit card numbers) in a way that protects them from
the from the web server. I think it is likely that some way of
composing WebCrypto and this mechanism will be necessary, eventually.

Cheers,
Brian

Received on Friday, 1 August 2014 13:31:39 UTC