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

Your proposal decouples spec from implementation more than the 
placeholder approach does, which is good.

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.

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.

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.

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.

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.

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

Received on Friday, 1 August 2014 16:48:42 UTC