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

Thanks Jacob!

On Fri, Aug 1, 2014 at 6:48 PM, Jacob S Hoffman-Andrews <jsha@eff.org> wrote:
> I think the CSP directive is unnecessary and makes things more fragile. The
> 'protect this credential from XSS' attribute should be a property of a
> stored credential, not a web site. If the site has the correct CSP headers
> on 99% of its website, but then for some reason doesn't have them on one
> page, that page is a potential vector to expose the credential.

1. Nothing in the 'writeonly' document prevents UAs from using some
sort of heuristic to determine when to fill forms. We already look at
things like the form action, there's no reason we couldn't also look
at the page-level policy, or field-level attributes. Tagging the
credential as 'writeonly' is certainly compatible with this approach.

2. We need CSP anyway in order to specify where forms may permissibly
be submitted. Using it as a mechanism for setting a writeonly policy
seems like a reasonable extension.

> I think making input fields write-only is more powerful than we strictly
> need. When a user is manually entering a password, it's okay for the page to
> be able to read the value they are typing in. If the page has been modified
> by an attacker at this point, it's too late.

It seems like we could prevent this attack if we stop firing events on
'writeonly' fields. At best, that would prevent reading the value. At
worst, that would make the attacker's job harder (she'd have to layer
an invisible field over the password field and do magic to get the
value out of the one and into the other).

> What we want is a mechanism to specify 'once this value is stored in a
> password manager*, protect it from future JS on this page.' That's why I
> feel like it's relevant to define credential management APIs for the web.
>
> *or credit card autofiller.

1. How do we retroactively apply this policy to users' existing
credentials? 'writeonly' is a nice, drop-in solution that works for
existing credentials as well as new credentials.

2. I'd prefer not to rely on multiple subsystems' understanding of the
"protect from JS" concept. In Chrome, at least, credit cards and
passwords are in separate databases, and filled via different code
paths. I suspect that doing the work once at the DOM-level would be
less error-prone.

> The write-only spec fully breaks XHR form submission (style C in my earlier
> mail). As Brian pointed out, the placeholder approach can be made to work
> with XHR if you're willing to do a little extra inspection of arbitrary
> XHRs.

This approach breaks XHR-based systems which read the data directly
from the form field. It doesn't necessarily break an API-driven
mechanism.

> Also, as you pointed out, write-only breaks client-side validation.
> Client-side validation is very broadly used for password strength meters
> during signup and change password. I think interfering with strength meters
> would make it a lot harder for implementers to adopt the spec.

Would we need strength meters for sign-in forms? We'd really only need
those for sign-up forms when users are creating an account, right? If
we can find a reasonable way of distinguishing the two, we can address
this use case.

For example, if we set a CSP which includes
`autocomplete="current-password"`, but excludes
`autocomplete="new-password"` (and we assert that browsers are updated
to exclude 'new-password' from autofill), we'd get the advantages of a
blanket page-level policy, while allowing developers to help users
create strong passwords.

>> I'm curious about the use cases for protecting the password from the
>> webserver.
>>
> One common use case for client-side crypto is removing systems from scope in
> PCI (payment card industry) compliance. There's a set of standards related
> to the handling of credit/debit cards that involve auditing all systems that
> have card data. There are third-party services that offer compliance by
> having you encrypt card data in JS and pass it, encrypted, through all your
> non-compliant systems and into their secure vault where it is decrypted.

Interesting. The proposal I've made doesn't support this use case. How
common do you believe it is? If we need to support it, then blocking
JS-level access to the form data will be difficult.

-mike

Received on Saturday, 2 August 2014 05:41:28 UTC