- From: Jacob S Hoffman-Andrews <jsha@eff.org>
- Date: Fri, 01 Aug 2014 12:48:09 -0400
- To: Mike West <mkwst@google.com>, Brian Smith <brian@briansmith.org>, Sigbjørn Vik <sigbjorn@opera.com>
- CC: Webapps WG <public-webapps@w3.org>
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