RE: Upcoming changes to Chrome’s WebAuthn implementation (Chrome 112 / 113)

Hi Martin,

 

Thanks for the heads-up,

 

I have one important functional issue with 2. : Android still doesn’t support UV on security keys. So if I understand correctly the interactions, it means that credentials created on Chrome won’t be usable on Android. Until Android is updated, of course.

 

Do you have any guidance on this use case?

 

Best regards,

 

-- 

Thomas Duboucher

 

From: Martin Kreichgauer <martinkr@google.com> 
Sent: jeudi 9 mars 2023 22:48
To: public-webauthn-adoption@w3.org; W3C Web Authn WG <public-webauthn@w3.org>
Subject: Upcoming changes to Chrome’s WebAuthn implementation (Chrome 112 / 113)

 

Greetings WebAuthn Adoption Community Group and WebAuthn Working Group,

 

We would like to give you an early heads-up to some changes in Chrome’s WebAuthn platform authenticator on macOS, and Chrome’s interaction with FIDO2 security keys.

 

1- 

On macOS, Chrome provides its own platform authenticator that stores credentials in the user’s Chrome profile on the local device only. This authenticator currently always performs  <https://www.w3.org/TR/webauthn-2/#user-verification> User Verification whenever it creates or asserts a credential. I.e., it prompts the user for Touch ID, or for the local device password when Touch ID is unavailable. Touch ID may be unavailable because it isn’t supported by the device, or because it’s temporarily unavailable, e.g. because the display lid is closed.

 

Starting with  <https://chromiumdash.appspot.com/schedule> Chrome 113, Chrome’s macOS platform authenticator will no longer prompt for either factor if the Relying Party sets the  <https://www.w3.org/TR/webauthn-2/#enum-userVerificationRequirement> User Verification Requirement for the request to “preferred” or “discouraged” and Touch ID is unavailable. If the User Verification Requirement is set to “required”, Chrome continues to enforce user verification as before, and falls back to prompting for the device password if necessary. The  <https://www.w3.org/TR/webauthn-2/#flags> UV bit in the response will faithfully reflect whether user verification was performed or not.

 

This change minimizes user disruption flows in situations where Touch ID cannot be used for user verification, and makes Chrome’s implementation align more closely with Safari’s.

 

2- 

Since some sites are setting uv=preferred to get this, more convenient, behavior we’ve also been considering its interaction with security keys. If a site does not require user verification on an assertion, and the user has stored a credential on a security key, then physical possession of the security key is sufficient to create a valid assertion. This is fine if the assertion is a 2nd-factor, but surprising if the credential is the sole authentication factor.

 

Chromium has long set  <https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html#sctn-credProtect-extension> credProtect to userVerificationOptionalWithCredentialIDList when creating discoverable credentials, but some sites use a flow where the user enters their username and the site makes a WebAuthn request with an allowlist. In this case, physical possession of the security key gives access to the account, which is probably undesired.

 

To address this,  <https://chromiumdash.appspot.com/schedule> Chrome 112 will set credProtect to userVerificationRequired when creating a credential where residentKey is required and userVerification is preferred. Such credentials couldn’t then be used in a uv=discouraged assertion.


Cheers,
Martin Kreichgauer for the Chrome WebAuthn team