Inconsistent Passkey Authentication in Google Chrome

[CyberCitizen]

Please note: This issue has been reported directly to Google Chrome. They did not acknowledge it as a bug and referred us to W3C Issues. From W3C Issues (Issue #1993 )  we were referred to here.

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.

Questions

Is this an intended behavior?
Is this behavior posing a vulnerability that could effectively weaken the overall security of the passkey authentication?

[Shane Weeden]

I would say “No”.

The RP is responsible to check uv is set to required in authData and reject assertion if that is their policy. 

It would be a bug if Chrome was returning uv=true when uv was not actually performed but that is not what you say is happening. 

Sent from my iPhone

On 9 Nov 2023, at 6:46 pm, CyberCitizen <cyberci...@gmail.com> wrote:



--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/6bf674e7-70e6-47c1-9c66-d573a96fbaeen%40fidoalliance.org.