Intent to Implement and Ship: The password property of PasswordCredential

[Jan Wilken]

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:

• https://github.com/w3c/web-platform-tests/tree/master/credential-management

 

These will be updated accordingly in the implementation CL.

 

OWP launch tracking bug

http://crbug.com/718416

 

Entry on the feature dashboard

https://www.chromestatus.com/features/5689327799500800

 

Requesting approval to ship?
Yes

[Jochen Eisinger]

The PR has landed. I have reached out to +John Wilander who initially commented on this, but haven't heard back since then.

lgtm1

[d...@google.com]

Hi, I'm on intent security triage (https://www.chromium.org/blink/intent-security-triage) duty this week and I'm digging into this one a bit...

I think that the justification for this feature depends on the assumption that, assuming XSS in an origin, it will always be possible to grab the password.  To some extent this is true if only because of phishing.  Though you could argue that the password property provides access to the password immediately without requiring the user to re-type it.

Serviceworker fetchevents might also expose the password even if a password property doesn’t exist explicitly in the Credential Manager API.  This is similar to the phishing scenario though (it would require the user type their password).

The justification given in the issue [https://github.com/w3c/webappsec-credential-management/issues/75] points to the possibility of a same-origin endpoint that replays the password.  This doesn't seem like a strong argument though.  Though these endpoints are likely common, what if such an endpoint _doesn’t_ exist on a given site?  Then the proposed password property would enable direct access to the password that wouldn’t otherwise be available.

All in all, I think there's an argument that this feature, at least in some cases, enables an XSS exploit to more easily obtain the user's password.  Is there a flaw in my logic?

Dave

[Dominic Battre]

Hi.

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.

Overall we had the feeling that there are so many possible attacks that concealing the password and limiting access to posting it via Fetch adds little security but has a big negative impact on the adoption. We discussed this with the Chrome Security UX team and concluded that if this API leads to less phishing, more generated passwords and more adoption of federated logins, then that outweighs the extra protection we give up with the limitation.

Best regards,

Dominic

-- 

Google Germany GmbH - Erika-Mann-Str. 33 - 80636 München - Germany

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

[David Ross]

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.

Ref: https://msdn.microsoft.com/en-us/library/ms533032(v=vs.85).aspx

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

[Eric Lawrence]

Prior to IE11, yes, IE's password manager required user interaction (what we call "Fill on account select") and that saved us from a great many vulnerabilities.IE11 relaxed password filling to compete with Chrome and Firefox, leading to some interesting bugs like this one: http://webdbg.com/ie/InPrivateInfoDisc.htm

Chrome contains some code that attempts to prevent XSS attacks from harvesting credentials trivially, but it's easily circumvented. 

-Eric

[Dominic Battre]

Hi.

On Thu, May 11, 2017 at 6:57 PM, David Ross <d...@google.com> wrote:

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.

Ref: https://msdn.microsoft.com/en-us/library/ms533032(v=vs.85).aspx

"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 browser may choose to offer users an opt-in such that they get auto-signed in. Chrome asks users whether they want that behavior. IE could choose not to offer such an opt-in and would be fully spec compliant.

Best regards,

Dominic

[David Ross]

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.

[Dominic Battre]

Hi.

On Thu, May 11, 2017 at 10:32 AM, David Ross <d...@google.com> wrote:

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.

The spec recommends (even after this change) that the Credential object (or the PasswordCredential if you will) is only accessible after user interaction. The spec allows a browser to make those objects directly accessible.

Once the user has selected a credential, the password attribute would be accessible to JavaScript.

I think that this is compatible with Chrome's and other browsers' current implementation of password managers that make the password accessible to the DOM by filling it into password form fields.

[Chris Harrelson]

LGTM2

It sounds like the Chrome security team is ok with this intent, and otherwise things seem to be in order.

--
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/CAFa1-K1CDnnEXRFhYJmFNFEehostCigQvynjfhOSScL1nB-WQA%40mail.gmail.com.

[Rick Byers]

Agreed, LGTM3

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.