Open Bug 1886569 Opened 1 month ago Updated 23 days ago

FIDO Credential Overwritten during Authentication

Categories

(Core :: DOM: Web Authentication, defect)

Firefox 123
defect

Tracking

()

UNCONFIRMED

People

(Reporter: will.smart, Unassigned, NeedInfo)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36

Steps to reproduce:

Firefox 123 on MacOS 14.4 seems to overwrite an existing credential on a FIDO2 security key during an authentication ceremony under certain circumstances. This generally presents itself when a credential is registered, the key is unplugged, and then the key is plugged in again to authenticate. This is also reproduced similarly with Safari.

While the exact symptoms vary between security keys from different manufacturers, this issue doesn't seem to be limited to a single manufacturer. Steps below completed with a YubiKey 5 with Firmware 5.4.3.

Steps to reproduce:

  1. Reset a security key so that it is in the default state.
  2. Navigate to any website that uses WebAuthn, like webauthn.io.
  3. Insert a security key.
  4. Register a credential, it seems most reliable to repro by only changing attachments=cross-platform
  5. Next authenticate with the security key, note that authentication is successful.
  6. Remove the security key.
  7. Go to another device to prove that the credential exists on the security key.
    a. Example: go to a Windows device to webauthn.io and authenticate with the security key
    b. Success
  8. Go back to webauthn.io using Firefox on macOS and authenticate.
  9. Plug in the security key, the key may act unresponsive and instead of blinking will stay lit up for 15 seconds.
  10. Cancel the webauthn request.
  11. Authenticate again.
  12. The user will see the error message “No Credentials Found”
  13. Go back to Windows device to webauthn.io and authenticate with the security key.
    The user sees “The security doesn’t look familiar. Please try a different one”

These steps are not reproducible if the security.webauthn.enable_macos_passkeys preference is set to false.

There is an extremely similar issue presenting on Safari 17.4: https://bugs.webkit.org/show_bug.cgi?id=271329 leading me to believe this may be a bug in an OS component shared by both Firefox and Safari.

Actual results:

The credential on the security key is destroyed (overwritten?) during step 8.

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Web Authentication' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → DOM: Web Authentication
Product: Firefox → Core

When the preference is set to true (the default) we are using a macOS API for passkeys, and the OS is deciding whether the user wants to store them in the keychain or use a USB security token. If you set it to false then Firefox will communicate directly to the USB device, but can't use the keychain storage.

This sounds like something we will have to wait for Apple to fix.

The severity field is not set for this bug.
:jschanck, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(jschanck)

Was this resolved with the release of Safari 17.4.1?

Flags: needinfo?(jschanck) → needinfo?(will.smart)
You need to log in before you can comment on or make changes to this bug.