Open Bug 1830846 Opened 2 years ago Updated 1 year ago

Authentication with TrustKey device fails depending on the order of credentials in allowCredentials

Categories

(Core :: DOM: Web Authentication, defect, P2)

Product:
Core
Component:
DOM: Web Authentication
Version:
Firefox 114
Platform:
x86_64
macOS
Type:
defect

Tracking

()

Status:
ASSIGNED
Milestone:
115 Branch

People

(Reporter: pgadmin, Assigned: jschanck)

References

Details

Steps to reproduce:

With nightly 114 2023-05-01, I try to register a Yubikey without PIN.

Actual results:

This used to work some days ago with nightly; now NS_OK exception is thrown.

Expected results:

Registering Yubikey with PIN and a Trustkey with fingerprint still works fine, but Yubikey without PIN is broken mpw.

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

Component: Untriaged → DOM: Security
Product: Firefox → Core
Component: DOM: Security → DOM: Web Authentication
OS: Unspecified → macOS
Hardware: Unspecified → x86_64
Depends on: 1830944

Could you try the latest Nightly build? If it's still not working, could you try registering on https://webauthn.io with each of the "User Verification" settings listed under "Advanced Settings", and let me know which fail.

Registering of all three keys succeeds in FF114 2023-05-04 now.

Authentication results:

  • Yubikey with pin: Success with both UV settings as expected
  • Yubikey without pin: Succeeds with both UV settings, I'd expect it to fail when UV=required (Chrome says "This SK cant be used on this website"), The UV flag is signaled correctly so I can handle it.
  • Trustkey with FP fails in both UV settings with "DOMException: The operation failed for an unknown transient reason"

Checking the trustkey against webauthn.io, the key works fine, so I digged deeper, and I discovered that it depends on the order in which the keys were registered (i.e. the order in PublicKeyCredentialRequestOptions.allowCredentials):

  • Yubikey/Yubikey+PIN/Trustkey -> Trustkey won't authenticate
  • Trustkey/Yubikey/Yubikey+PIN-> All keys authenticate

Thanks! Some tokens accept a (very) limited number of credentials in the allowlist. So I suspect that's the issue here. We are working on a fix in authenticator-rs #254.

Severity: -- → S2
Priority: -- → P2
See Also: → https://github.com/mozilla/authenticator-rs/pull/254/
Target Milestone: --- → 115 Branch

It's not a token problem: Chrome will work with the same set of allowed creds just fine.

A remark about handling of multiple tokens plugged in:

Chrome is handling this much smoother. with UV discouraged, it will take use the token I touch just fine. In case UV was required, the Yubikey with PIN will ask for the PIN, and require a second touch. Yubikey without will be rejected as not suitable for the website.

IMHO this is much more user friendly than asking for token selection.

See Also: → 1832013
Summary: Nightly stopped registering security keys without PIN → authenticator-rs does not respect CTAP2 maxCredentialCountInList property
No longer depends on: 1830944
Depends on: 1833240

msirringhaus' patch (authenticator-rs #254) has landed in Nightly. Can you check whether registering two YubiKeys and then the Trustkey works now?

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED

I checked with latest Nightly (2023-05-17), the problem is still present:

Yubikey w/o PIN, Yubikey w/pin, Trustkey freshly registered, both Yubikeys will authenticate, Trustkey won't.

I repeated the test reduced:
Registered Yubikey (with or without PIN won't matter) and then Trustkey, Yubikey will work fine, Trustkey will throw DOMException unknown transient reason (both UV required and discouraged).
So apparently biometrics is working on the first key only.

Thanks, I'll re-open the bug.

Does the Trustkey collect a fingerprint before the failure? Or does the request fail immediately?

Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: FIXED → ---

The Trustkey blinks according to UV required or discouraged, FF will fail after the touch.

Problem is still present in FF116 2023-06-13: Trustkey works only if first in list of keys.

I'm self-assigning to keep this on my radar. We will have some better tools for debugging this in an upcoming release.

Summary: authenticator-rs does not respect CTAP2 maxCredentialCountInList property → Authentication with TrustKey device fails depending on the order of credentials in allowCredentials
Assignee: nobody → jschanck
Status: REOPENED → ASSIGNED
Depends on: 1850025

Can you test FF119?

With 119.0a1 (2023-08-30), the problem still persists.

No longer depends on: 1850025
Severity: S2 → S3
Depends on: 1867353

There is another potential fix in Nightly 122. Can you give that a try?

Flags: needinfo?(pgadmin)

Still not working correctly with 122.0a1 (2023-11-30) , but I do have new findings, because I checked with another key as well.
YK: Yubikey 5NFC without PIN
TK: Trustkey G310 with Fingerprint
NK: Nitrokey K51T without PIN

TK YK NK --> ok
TK NK YK -> ok
NK TK YK -> ok
YK TK NK -> not ok

So the problem is triggered when the Yubikey is registered before the Trustkey, the Nitrokey doesn't interfere.

If Yubikey is registered before Trustkey, UV isn't requested correctly (Trustkey blinks "no FP required", so no wonder this will fail with "DOMException: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission"). But even with UV not required, the Trustkey will fail with the same DOMException.

FWIW, Chrome 119 behaves even worse: UV is requested correctly, but Trustkey will fail ALWAYS, not matter if registered before or after the Yubikey.

All situations are resolved when the Yubikey is removed.

Flags: needinfo?(pgadmin)

Just checked with FF120.0: Works exactly like FF122 Nightly.

You need to log in before you can comment on or make changes to this bug.