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

On Fri, Aug 1, 2014 at 3:31 PM, Brian Smith <brian@briansmith.org> wrote:

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

I hadn't considered autofilled credit cards; that's a reasonable use case.

We could address credit cards by turning the CSP directive into a list
of autocomplete attribute values: `form-readonly cc-number cc-csc ...
current-password new-password`. That seems like it would address the
credential use case, while leaving flexibility for future field types
that developers might care about giving extra protection.

That said, it gets quite verbose. If we go this route, perhaps we
could come up with a chunk of those types we'd expect developers to
want to protect, and give them a special keyword expression:
`form-readonly 'the-usual-stuff'`.

> I am not sure that looking only at POSTs is sufficient.

I don't think we should encourage GET-based submission of valuable information.

> websites put login forms on every page (whether they should or not).

If we filled a form on every page, but the user never logged in, there
would indeed be a (marginal?) performance impact if we had to examine
every POST a website made. That feels like an edgy enough case that we
don't have to worry too much about it, but I don't have any numbers to
back that up.

> But, I agree that it would be better to avoid the need for the
> attribute if we can.

The less work we make the website do to get some security benefit, the better.

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

If the field is write-only, they won't be able to do client-side
validation. That's a necessary consequence of keeping the password out
of the renderer, and out of reach of JavaScript. I agree that this is
more problematic for SSN or CC fields than for passwords, but I don't
see an alternative that would keep the renderer in the dark about the
actual value.

If they use the credential management API to get credentials, they'll
only be getting credentials the user saved. Presumably the user
wouldn't save credentials that weren't valid for the site.

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

I'm curious about the use cases for protecting the password from the webserver.

I've had some conversations with Sigbjørn Vik about returning hashed
passwords rather than "real" passwords, which might be going along the
lines you're thinking. That is, the site would provide hash function
and a server nonce when requesting credentials, and the UA would
return a client nonce and a LocalCredential whose password value was
`hash(password + server nonce + client nonce)`. I think that's worth
exploring, but it's tough to do well without requiring the site to
hold passwords in plaintext.

Is that the kind of use case you're considering?

--
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 Friday, 1 August 2014 13:59:17 UTC