1859425 - Specific FIDO2 token fails to function under CTAP2 mode

Status: UNCONFIRMED

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

Description

[[:Oneric]]

Attachment: Makefile

Steps to reproduce:

1.) Go to any webiste where an account with a FIDO(2) second factor is already registered.
2.) Enter username and password
3.) (If necessary explicitly click on “Use security key” button or similar)

Actual results:

Authentication with the security device fails — for one of my security keys. Another key, of the same model and same (newest) firmware version continues to work. Both support FIDO2/CTAP2. More specifically they advertise support for:

caps: 0x05 (wink, cbor, msg)
version strings: U2F_V2, FIDO_2_0, FIDO_2_1_PRE
extension strings: credProtect, hmac-secret

The issue starts to appear with Nightly which include code revision 7d0050f06d65d4c52c1f74bfb0c1751d2907ac70 (which sets security.webauthn.ctap2 to true; used mozregression to bisect), or for releases starting with 114.0b1 (which includes the removal of U2FHIDTokenManager in favour of always using authenticator-rs, see https://bugzilla.mozilla.org/show_bug.cgi?id=1828215 ).

Initially (and still in ESR115), Firefox still queried the device and I had to activate the usual mechanism on the key to continue with the authentication and the failure would only appear afterwards.
In the current (2023-10-16 and also 2023-10-12) nightlies however, it immediately fails before the key even prompts me to verify the process.

Setting security.webauthn.ctap2 manually back to false allows the affected device to "work" again (tested in both ESR115 and the 2023-10-16 nightly).
However, this (a) should not be necessary since the device supports CTAP2, (b) relies on fallback to CTAP1 and (c) needs manual tweaking of about:config.

In the current (2023-10-16) nightly starting with RUST_LOG=authenticator=debug shows the following for the failing

[INFO  authenticator::transport::platform::device] new device "/dev/hidraw1"
[INFO  authenticator::statemachine] Device "/dev/hidraw1" continues with the signing process
[WARN  authenticator::ctap2] error happened: Error: Error issuing command: CommandError: Unexpected code: NoCredentials (None)

and just this for the working device (which again, are the same hardware model and firmware version):

[INFO  authenticator::transport::platform::device] new device "/dev/hidraw1"
[INFO  authenticator::statemachine] Device "/dev/hidraw1" continues with the signing process

For the nightly 2023-02-02 just after the issue was introduced (and the device is still queried first) the output is:

[INFO  authenticator::transport::platform::device] new device "/dev/hidraw1"
[INFO  authenticator::statemachine] Device "/dev/hidraw1" continues with the signing process
[INFO  authenticator::statemachine] Statemachine was cancelled. Cancelling transaction now.
[INFO  authenticator::transport::platform::transaction] Transaction was cancelled.
[ERROR authenticator::ctap2_capi] Error when receiving status update: RecvError

Using the CLI tools from libfido2 (and a small patch to add a -2 flag to force FIDO2/CTAP2 mode via fido_dev_force_fido2(dev) just to make sure), I can confirm that the affected device is indeed able to create credentials and asserts for credentials under CTAP2 just fine.
See the attached Makefile, which if HID_DEV and KEY_ID are set, will go through this process using libfido2; e.g.: make HID_DEV=/dev/hidraw1 KEY_ID=AFFECTED. (Note that the Makefile does not automatically clean up files which failed to generate correctly. If you experience any errors during the creation, run make HID_DEV=/dev/hidraw1 KEY_ID=AFFECTED clean first before trying again)

Expected results:

All my FIDO2 tokens work out of the box and with security.webauthn.ctap2=true.

Let me know if you need any more details.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 2

[John Schanck [:jschanck]]

Could you try the following test scenario on https://webauthn.io. I'm curious if the final step fails immediately without prompting you to touch your security key.

Create a credential on Security Key A (the one that is not working), and note the credential ID.

1. Insert Security Key A.
2. Set the user name field to "test".
3. Click "Register".
   You should see "Success! Now try to authenticate...".
4. Click "Authenticate".
   You should be redirected to a new page with the title "You're logged in". Below that it will say "Credentials for test".
5. Take note of the credential ID listed in the blue box.
6. Click "Try it again".

Create a credential on Security Key B (the one that is working), and delete the server's record of the credential on A.

1. Insert Security Key B.
2. Set the user name field to "test".
3. Click "Register".
   You should "Success! Now try to authenticate...".
4. Click "Authenticate".
   You should be redirected to a new page with the title "You're logged in". The page should list two credentials.
5. Click "Delete" in the box for the credential on Security Key A.
6. Click "Try it again".

Try to authenticate with Security Key A.

1. Insert Security Key A.
2. Set the user name field to "test".
3. Click "Authenticate".

Please let me know if step 3 fails immediately or if you're prompted to touch the security key.

It would also be helpful to know if you have a PIN set on either of these devices.

Comment 3

[[:Oneric]]

Using nightly 2023-10-17 now and for good measure I reconfirmed key A still fails and key B still works in the usual scenario.

Please let me know if step 3 fails immediately or if you're prompted to touch the security key.

After following all steps, I am first prompted to touch security key A. Only afterwards the website shows an auth failure text in a red box.
The Rust debug output is just:

  [INFO  authenticator::transport::platform::device] new device "/dev/hidraw7"
  [INFO  authenticator::statemachine] Device "/dev/hidraw7" continues with the signing process

It would also be helpful to know if you have a PIN set on either of these devices.

I’m currently only using them as second factors which does not require a PIN.
I vaguely remember testing passwordless auth once and a prompt to set up a PIN coming up, but cannot recall if I set a PIN or cancelled the test. (But if I had set up a PIN, I would no longer remember it and don't have any other records of it.)

Attempting some actions with fido2-token which require PIN verification, results in a FIDO_ERR_PIN_NOT_SET error for both. A wrong pin should result in FIDO_ERR_PIN_INVALID instead, so I’m guessing I never set a PIN on either device. If you know a more direct way to check if a PIN was set I can check this way as well.

$ fido2-token -L -b /dev/hidraw7
Enter PIN for /dev/hidraw7:
fido2-token: fido_credman_get_dev_rp: FIDO_ERR_PIN_NOT_SET

$ fido2-token -L -b /dev/hidraw8
Enter PIN for /dev/hidraw8:
fido2-token: fido_credman_get_dev_rp: FIDO_ERR_PIN_NOT_SET

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit BugBot documentation.

Comment 5

[John Schanck [:jschanck]]

Could you also try creating a credential with security.webauthn.ctap2 = false and then asserting that credential with security.webauthn.ctap2 = true?

It would also help to know the model and firmware version of the affected security key.

Comment 6

[[:Oneric]]

Now using Firefox Nightly: 121.0a1 (2023-11-01) (64-bit) x86_64

First I reconfirmed device A is still affected and fails before prompting for authentication and device B still unaffected (ctap2=true).

It would also help to know the model and firmware version of the affected security key.

For both the affected and the unaffected device:

• Model: NitroKey FIDO2
• Firmware: 2.4.1 (the latest release currently; official builds this is not the dev version of the hardware)

creating a credential with security.webauthn.ctap2 = false and then asserting that credential with security.webauthn.ctap2 = true?

Steps on https://webauthn.io/:

1. Insert Device
2. Set/Ensure security.webauthn.ctap2 = false
3. username=test; click “Register”
   --> Should say “Success! Now try to authenticate...”
4. Set/Ensure security.webauthn.ctap2 = true (and reload webauthn page)
5. username=test; click “Authenticate”
6. If successful, delete all credentials

Both device A and B succeed and the RUST_LOG=authenticator=debug output on authentication is

[INFO  authenticator::transport::platform::device] new device "/dev/hidraw7"
[INFO  authenticator::statemachine] Device "/dev/hidraw7" continues with the signing process

The credential info for both devices shows Transports: ["usb"] and Description: device-bound non-discoverable credential.

---

Note: At first I accidentally started a registration with ctap2 for one of the keys but may have aborted the process.
This resulted in (eventually) three credentials showing up on webauthn.io (even though I only inserted those two keys and did not knowingly install any software keys) and either device failing on step 5 before prompting for interaction. The RUST_LOG=authenticator=debug for both devices was

[INFO  authenticator::transport::platform::device] new device "/dev/hidraw7"
[INFO  authenticator::statemachine] Device "/dev/hidraw7" continues with the signing process
[WARN  authenticator::ctap2] error happened: Error: Error issuing command: CommandError: Unexpected code: NoCredentials (None)

The third credential had Description: device-bound passkey and Transports: ["internal"].
I then authenticated with ctap2=false, deleted all three keys and was unable to reproduce this result since (while authentication for my actual accounts on different pages remains as broken/working as before).