The AppID extension is not responding to FIDO2/CTAP2 security keys in Firefox 122+
Categories
(Core :: DOM: Web Authentication, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox124 | --- | fixed |
People
(Reporter: drew.dani, Assigned: jschanck)
References
Details
Attachments
(1 file)
+++ This bug was initially created as a clone of Bug #1814722 +++
This broken again in Firefox 122 unfortunately.
Firefox 122 is accepting the FIDO2 PIN using the old webauthn popup mentioned here, and then falling to send the request to the authenticator. Removing the AppID extension makes FIDO2 on-token PIN auth work with the new WebAuthn popup. I see a few major changes: to how the preflights in CTAP2 logic and a Rework support for AppId extension which appears to be where the bug was introduced.
The problem is when an AppId extension is provided for a FIDO2 security key, the user can enter the FIDO2 PIN, but then nothing happens after a user enters a PIN and clicks submit - the browser no longer talks to the authenticator. This is only a problem starting with the 122 release. It appears that starting Firefox 122, the default popup is the Apple/Safari one, however, when an AppId extension is provided, the old popup occurs and nothing happens after entering a PIN.
Code ref:
https://github.com/mozilla/authenticator-rs/commit/32f8e144eac287ec9ecb7b54c707e7c5bb32fbb0
https://github.com/mozilla/authenticator-rs/commit/d512ad9b5deb88edce20eca002659e469e4f8341
There are a couple of issues to report in the latest
The FIDO AppID extension allows a relying party to request an assertion from a credential that was created using the legacy U2F javascript API. We seem to support this correctly in U2FHIDTokenManager
but not in CTAPHIDTokenManager
, i.e. not when security.webauthn.ctap2
is true.
Users can work around this by re-registering their security keys.
This bug has been fixed in Firefox 114, but persists again in 115 and up. Can you please review the fix? The app id extension is no longer supported.
Assignee | ||
Comment 1•9 months ago
|
||
The work-around in Bug 1867847 fails to forward the PIN callback to authenticator-rs.
A temporary workaround is to set security.webauthn.enable_macos_passkeys
to false
if you need to assert an AppID credential.
Assignee | ||
Comment 2•9 months ago
|
||
Comment 4•9 months ago
|
||
Assignee | ||
Updated•9 months ago
|
Comment 6•9 months ago
|
||
bugherder |
Confirming that the issue is fixed in 124.0a1. Thank you all!
Can this be backported to FF123.x?
Description
•