Contact emails
jdoe...@chromium.org, vas...@chromium.org, zk...@chromium.org
Specification:
https://w3c.github.io/webappsec-credential-management/
Motivation:
The current security model of the Credential Manager API is not as effective as desired (see e.g. https://github.com/w3c/webappsec-credential-management/issues/58) and the current fetch based infrastructure has reported usability issues (e.g. it's impossible to send JSON or apply a hash to the password before sending).
Please see https://github.com/w3c/webappsec-credential-management/issues/75 for more details.
This proposal addresses this by exposing a new password property on PasswordCredential, which allows developers to directly read the password from JavaScript.
For more details see the accompanying pull request to the specification:
https://github.com/w3c/webappsec-credential-management/pull/76
Interoperability and Compatibility Risk
Edge: No public signals
Firefox: neutral, commented on the PR
Safari: initially concerned but no further feedback despite several pings
Web developers: Positive
Is this feature fully tested by web-platform-tests?
Yes, existing tests are here:
These will be updated accordingly in the implementation CL.
OWP launch tracking bug
Entry on the feature dashboard
https://www.chromestatus.com/features/5689327799500800
Requesting approval to ship?
Yes
Another attack is possible due to the current password manager filling in credentials into login forms that can be extracted via JavaScript. An XSS can create such a login form and wait for it to be filled.
Another attack is possible due to the current password manager filling in credentials into login forms that can be extracted via JavaScript. An XSS can create such a login form and wait for it to be filled.I need to check the current Edge behavior, but my recollection is that IE's password manager doesn't go as far as automatically propagating the password into the page. Iirc, it was necessary to start typing the corresponding username into the username drop-down, then click the username in the IE-provided dropdown. It wasn't possible to automate this short of a (somewhat contrived) clickjacking attack."User information saved in the AutoComplete data store is safeguarded, because Web sites cannot automatically fill in forms using the data store..."In the context of the W3C spec, it may be reasonable to consider this case of a password manager implementation such as IE's -- one that does not directly enable access to the password even assuming XSS (modulo any bugs). For such an implementation, the password property could still be considered to enable password access that wouldn't otherwise be possible.
The default case for the Credential Management API is that credentials are only passed to the website after user mediation (see here).
The default case for the Credential Management API is that credentials are only passed to the website after user mediation (see here).Is user mediation required before the password manager injects a password into the DOM? Or before the password property would be available? Or both?I'm thinking it makes sense for the spec to recommend against implementation of the password property for more conservative password managers require user interaction prior to putting passwords in the DOM. But in Chrome at least, it looks like the password property is reasonable to implement given the password is already accessible in the DOM, by design.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFa1-K1CDnnEXRFhYJmFNFEehostCigQvynjfhOSScL1nB-WQA%40mail.gmail.com.--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw88NOF025Qz7_Qt2VsdPTSOAux8%3DFLgyokpozNY6KW5%2Bw%40mail.gmail.com.