Inconsistent Passkey Authentication in Google Chrome

[CyberCtzn]

Description

During regular usage of the MacBook Pro model with a AppleM2 chip, running macOS in Version 14.0, we came across an unusual behavior, allowing us to skip the passkey fingerprint authentication in the latest Google Chrome version (including Canary).

We have tested the same scenario with some other popular web browsers, all of them behave differently and don't allow the login with the fingerprint sensor (or other biometric device) being disabled.
Also the same testing scenario in Google Chrome on a different Operating System did not yield the same behavior. Chrome on Windows doesn't behave like this and doesn't allow the login via Windows Hello, if the camera is unplugged.

PoC

1. In order to trigger the behavior, it is required to put the MacBook into so-called Clamshell mode, meaning closing the lid while working on attached hardware (monitor, mouse and keyboard).
   In this state the system will detect the closure of the MacBook lid and consider the inbuilt Fingerprint sensor as “deactivated”.

2. When trying to login to a web application that has been set up with the Passkey of the user, and trying to login via Passkey functionality, the popup in the Web browser will appear, but instead of asking the user to authenticate via fingerprint or password to unlock the Passkey, the dialogue just presents a “Continue”-button, which can be clicked.

(Clamshell mode Passkey Dialog)

3. When clicking this continue-button, the user gets forwarded and successfully authenticated with the web application, without the necessity to provide his or her fingerprint.
   Based on: https://www.w3.org/TR/webauthn-2/#dom-userverificationrequirement-preferred , preferred is the default value in the configuration.

Details

We tried the same login scenario on a self-hosted web application with:
UserVerficationRequirement = required
Received the unchanged and same behavior in Google Chrome browser.

Google Chrome did not acknowledge this as a Bug.

[agl]

The WebAuthn group isn't the place for reporting issues with specific browsers, but this isn't a bug either: this is valid behaviour with uv != required and matches Safari. If it happens with uv == required, that would be a bug, but you can test with https://webauthntest.identitystandards.io/ to see that it doesn't.

[Firstyear]

@CyberCtzn We have already noted this issue in kanidm/webauthn-rs#281 and have had to move to uv=required everywhere to work around this. It affects safari as well as chrome.

The issue is that any correctly and securely implemented RP that uses uv=preferred and follows https://w3c.github.io/webauthn/#reg-ceremony-store-credential-record and https://w3c.github.io/webauthn/#abstract-opdef-credential-record-uvinitialized can very reasonably track and enforce that UV should always be provided by the credential in question. This behaviour of safari and chrome undermines that, and means that UV is trivially by-passable - especially bad as some RP's don't track and correctly enforce UV across ceremonies.

A user very reasonably would expect that touch id is required here, and the fact it goes away really is surprising.

Generally today the only secure uv setting is UV=required, and to always register with credProtect if possible.

[MasterKale]

This is indeed the "preferred" user verification option behaving as expected. Preferring user verification allows RP's to optimize the authentication user experience by signaling that browsers and passkeys providers can avoid situations in which a user might get prompted for a password.

Case in point: a typical user on a Mac Mini, without any kind of biometric sensor available, might wonder why they're constantly being prompted for their local login password when using a passkey for "passwordless auth". This stands to hurt passkey adoption as the use of a password, even a local-only one, can be confusing.

I'd also suggest that with the authentication bar being raised so much higher with passkeys, maybe it's okay for user verification to sometimes be false. The ceremony still benefits from the phishing-resistant aspects of WebAuthn auth, and the majority of platforms and roaming authenticators will actually perform UV. Couldn't RP's factor in the additional MFA barriers that platform authenticator passkey providers have implemented to be okay with sometimes getting uv:false from ceremonies they participate in? 🤔

That said the power is in the RP's hands to avoid the ambiguity of a "preferred" ceremony if the RP doesn't like it. Mark UV "required" in options and check the auth data uv flag in the response - you'll more reliably get back uv:true as desired.

[Firstyear]

This is indeed the "preferred" user verification option behaving as expected. Preferring user verification allows RP's to optimize the authentication user experience by signaling that browsers and passkeys providers can avoid situations in which a user might get prompted for a password.

Practically it almost never works like this. Yubikeys always request a PIN. Windows hello will always ask for a PIN. So why is touchid special here? Why is it allowed to just ditch UV because it feels like it?

If you have your macbook pro, and it always asks for touch id, then one day you sit at your desk and it stops, that confuses the user. It makes them think "wait, hang on, this always needed my fingerprint before, why can I just click continue now?". You know what real humans have said about this in my work surveying people? They quite broadly responded that it means they no longer trust that the credential needs UV at all and they lose trust in it.

This undermines faith in the security of a system.

What preferred actually causes is that during device registration it means "we accept devices that will always do UV, or we accept devices that can't do UV". This lets the RP make choices about the device as a whole, and it's properties it should consistently and always have going forward. This way you make policy choices about the authenticator and all future ceremonies that authenticator will be a part of.

The whole "UV is part of the ceremony" line is quite silly and we need to stop it.

Case in point: a typical user on a Mac Mini, without any kind of biometric sensor available, might wonder why they're constantly being prompted for their local login password when using a passkey for "passwordless auth". This stands to hurt passkey adoption as the use of a password, even a local-only one, can be confusing.

I'd also suggest that with the authentication bar being raised so much higher with passkeys, maybe it's okay for user verification to sometimes be false. The ceremony still benefits from the phishing-resistant aspects of WebAuthn auth, and the majority of platforms and roaming authenticators will actually perform UV. Couldn't RP's factor in the additional MFA barriers that platform authenticator passkey providers have implemented to be okay with sometimes getting uv:false from ceremonies they participate in? 🤔

It's a shame that UV=discouraged here just means that you inconsistently sometimes get a PIN and sometimes don't, rather than being "never get a PIN at all, just accept UP". But that ship has well and truly sailed too.

That said the power is in the RP's hands to avoid the ambiguity of a "preferred" ceremony if the RP doesn't like it. Mark UV "required" in options and check the auth data uv flag in the response - you'll more reliably get back uv:true as desired.

Maybe the specification should reflect RP intents around device expectations having UV properties associated to the device, for the lifetime of the device.

And maybe browsers shouldn't undermine user security expectations by "sometimes wanting UV and sometimes not".

But at this point I think that ship has also sailed, and now every RP has to realistically set UV=required to ensure consistent user experience - even if that user has to type in their platform password for a passwordless credential.

It's getting harder and harder for an RP to navigate this spec and how to make it usable, consistent and secure for users.

[timcappalli]

When you create an issue in this repo, there is a list of options including the four below, which take you to the appropriate place. As this is a deployment question, and more specifically a behavior question, please either post to FIDO-DEV or report a bug using the appropriate channel.