No longer working on Firefox

[jimmiedave]

Stopped working this week. Same key, same site working on Chrome, Safari, Brave all for macOS.

Firefox 130.0.1

Upon inserting and touching the key, I get ‘No credentials were found for “{my site}” on this security key. Try again with a different security key’.

I have two keys registered, and neither work here. They do work on the above-mentioned browsers.

I’ve tried turning U2F on and off in the Two-Factor Auth plugin – no difference. Cannot turn off WebAuthn in that spot. Both keys are registered in both U2F and WebAuthn.

[zaneselvans]

I'm experiencing the same issue.

[sjinks]

@jimmiedave @zaneselvans does 2.4.1 work for you?

I suspect that #874 could break things :-(

[sjinks]

Also, what are the steps to reproduce?

This is what I have tried:

1. Logged in from Chrome, created a new key
2. Logged out
3. I logged in from Firefox, and it worked for me.

I guess I am missing something?

[jimmiedave]

2.4.1 works (just reinstalled it manually) saying "Touch your security key to continue with {my site}" - using the Firefox dialog, not the OS passkey dialog.

Steps to repro with 2.5.0:

Wordpress (always latest) installed on my own VPS (not shared hosting, no WP hacks from Bluehost or anybody).

Go to login page (mine, not a "log into WordPress.com" page)
Enter username (an admin, though I've got 2FA on admin account and on user account - haven't tested same when entering user account)
Enter password
OS Passkey dialog appears: "Choose how you'd like to sign in to {my site}"
See options: •iPhone, iPad or Android device, •Security Key
Choose "Security Key"
Click "Continue"
Dialog changes to "Use Security Key":"To continue with {my site}, insert and activate one of your security keys"
Touch Yubikey activation area. Nothing happens (yes, tested this repeatedly)
Touch Yubikey activation area again.
Get error: 'No credentials for "{my site}" were found on this security key. Try again with a different security key'.

I'm on Sonoma 14.5. I should note that I have never activated iCloud keychain, but this hasn't affected any other apps, including the OS passkey dialog on other browsers.

[zaneselvans]

Not sure if it's easy to re-install a non-current version, but the Yubikey login was working great until recently.

It would also be nice if there was some way to avoid having to select the Yubikey and not the passkey with every single login.

[jimmiedave]

Noting that this is an OS dialog, I just updated Sonoma to the latest 14.7, with no noted change to behavior.

I'll also state that I didn't create a new key from Chrome first - I used my current Yubikey (one of 2 registered, tried both with no difference), and touched a key that stays plugged into a hub all the time (i.e. not plugged in when dialog pops up. Tried both already-plugged, and plug-in-when-prompted with no difference in bug).

[jimmiedave]

Not sure if it's easy to re-install a non-current version, but the Yubikey login was working great until recently.

It would also be nice if there was some way to avoid having to select the Yubikey and not the passkey with every single login.

Installing an old version: uninstall 2.5.0 on your server, copy the 2.4.1 .zip file to your server in the {public_html}/wp-content/plugins/ directory and unzip it, use chown -R {web owner:web group} to give the unzipped directory the same owner and group as the other plugins. (may have to use sudo chown -R {web owner:web group} or maybe be root depending on your setup and logged-in user)

re: not having to choose security key: Yes, this would be nice, but it's an OS dialog, and not something this plugin will control. Tim Cook, get your butt down here and fix it!

[jimmiedave]

Also the "Having Problems?" "Use your security key" link from the "Retry" page changes the dialog to (I guess) the plugin dialog: "Now insert (and tap) your Security Key." and when I tap the key, nothing happens.

[jimmiedave]

If I "revoke" a key, can I re-add it? Wondering if your "added a new key in Chrome" has some effect.

[sjinks]

cc @dd32

It looks like this is MacOS-specific, as it work on Linux :-(

[sjinks]

@jimmiedave

If I "revoke" a key, can I re-add it?

Yes

[dd32]

:/ I'm pretty sure I tested Firefox on macos with a physical yubikey, but I can test it again tomorrow.

As explored in dd32#1 the "proper" solution is to store the transports at registration time and prompt with those at login time. (The upstream library doesn't really do that, since it's not a level 2 implementation)

Unfortunately Firefox appears to differ from the other browsers in their implementation of challenges without the transport field, which is why we're here I guess.

[jimmiedave]

Just noted that my Yubikey works fine in Firefox with a brokerage. Uses OS dialog. So it can be accomplished.

[zaneselvans]

I've also found that it works as expected on Vanguard (and never asks me if I want to use a Passkey!)

[dd32]

I'm unable to duplicate with Firefox 131.0 (aarch64) on macOs Sequoia 15.0 (24A335). I've tried registering a yubikey with a previous version of the plugin and then updating, all that.

The behaviour has changed, as it no longer prompts instantly to use a security key and uses the macos system prompts

Before	Now	with a Passkey registered
oldbehaviour.mov	newbehaviour.mov	w-touchid.mov

Using a Kensington VeriMark Guard I do end up with a different login flow.
Previously it would act like the Before video above, but now it acts like the following, prompting for which credential on the key to use. Selecting either one works. Revoking and add the key doesn't change it.

kens.mov

Something I'm not seeing mentioned here is what keys are being used, brand etc.. Yubikey also has a long changelog of changes they've made to their firmwares, so no two keys are identical in behavour.. I've been testing with version 5.4.3 of the firmware

Upon inserting and touching the key, I get ‘No credentials were found for “{my site}” on this security key. Try again with a different security key’.

I'm not sure how this would actually happen in practice, I'm guessing that maybe this is an algorithm issue; Perhaps the key is registered with a alg that firefox supports but isn't supported via the macos interface? I can't imagine it's actually because of the transports being specified, rather just the different codepath that's triggering..
I'm not sure how to determine if this is the case.. but if so, revoking and re-registering the key would work..

I wonder if it's possible to have the plugin return the array with two of the same keys in the payload? see if that changes it for the affected keys ie.

[
{"type":"public-key","id":"1K1U.....AAAA","transports":["usb","nfc","ble","internal","hybrid"]},
{"type":"public-key","id":"1K1U.....AAAA","transports":[]}
]

In trying that, I triggered the kensington key above to offer 4 credentials; as it matched against both key options.. and the yubikey just worked... at first...

Index: wp-content/plugins/two-factor-provider-webauthn/vendor/madwizard/webauthn/src/Server/WebAuthnServer.php
===================================================================
             foreach ($credentialIds as $credentialId) {
                 $descriptor = new PublicKeyCredentialDescriptor($credentialId->toBuffer());
+                $requestOptions->addAllowedCredential( clone $descriptor );
                 foreach (AuthenticatorTransport::allKnownTransports() as $transport) {

Using that diff, I've successfully triggered the Yubikey to get rejected as No credentials on device, despite the Kensington key being happy with it (and just offering 4x credentials now, instead of 2x)
That suggests it's not at all the algorithm, but rather the transports that is causing the issue here.. but I'm not sure how..

By setting all transports as done in v2.5.0 I think it's against this line of the spec: (emphasis mine)
https://www.w3.org/TR/webauthn-2/#sctn-getAssertion:~:text=It%20is%20RECOMMENDED%20to%20also,find%20a%20suitable%20authenticator.

It is RECOMMENDED to also:

• Associate the credentialId with the transport hints returned by calling credential.response.getTransports(). This value SHOULD NOT be modified before or after storing it. It is RECOMMENDED to use this value to populate the transports of the allowCredentials option in future get() calls to help the client know how to find a suitable authenticator.

By setting it to all known methods we're modifying the value, which causes a spec violation, but I'm not actually sure how that's used by keys. I thought it was purely used by the client to determine the location to find the key, which seems to be how other browsers interpret it, and I'm not seeing anything else in the spec to suggest that the key should verify it's being accessed over an approved manner..

It would also be nice if there was some way to avoid having to select the Yubikey and not the passkey with every single login.

I agree. I think there's a chance that the 'proper' route mentioned in #892 (comment) would lead to that being a potential option. If the only registered keys are only ever available over USB then it might just prompt for USB straight away.

Finally... Just noting you can use https://wordpress.org/plugins/wp-rollback/ to install an older version of a plugin for testing.

[jimmiedave]

Testing here with a couple Yubikey 5 NFCs, Firmware 5.4.3.

Don't have a PIN on mine.

Same key working on Firefox with OS dialog for log in to GitHub (just tested a minute ago). Is GitHub's login code open source? Maybe have a look if so?

[jimmiedave]

OK, so I "Deleted" a Yubikey's U2F config and "Revoked" its WebAuthn config. I was able to add back a WebAuthn config, but the U2F config just runs a spinner and never completes. I realize I probably only need one 2FA method to work, but the never-completing spinner vs. a dialog that says "you can't" or "don't bother" is an unexpected result.

The surprise to me is that after re-adding the WebAuthn config, which this time used the macOS dialog, I was able to log in with the Yubikey.

Just to reiterate: I didn't have to do any of this to get Safari, Brave, Chrome to work.

[dd32]

Same key working on Firefox with OS dialog for log in to GitHub (just tested a minute ago). Is GitHub's login code open source?

I don't believe it is, however looking at the prompt in the past it stores the transports and prompts with it in the future.
The plugin is kinda stuck, as the library we're using doesn't store the transports and was never really designed to do it.

A shortcut was taken in 2.5 where we simply tell the browser "We don't know where this key was acquired from, check every possible transport" which is what is seemingly causing an issue for you here.

Testing here with a couple Yubikey 5 NFCs, Firmware 5.4.3.

Hmm.. that the exact same key as I have then.

I was able to add back a WebAuthn config, but the U2F config just runs a spinner and never completes.

The U2F stuff is from the two-factor plugin, and is not operational (for at least a year), that's why this plugin exists. You can ignore the U2F section.

The surprise to me is that after re-adding the WebAuthn config, which this time used the macOS dialog, I was able to log in with the Yubikey.

Great! I think that is making me think this is a algorithm issue; unfortunately I don't really know how to debug this though.. without being able to reproduce it.. I'm thinking maybe I need to try setting up the key with a much older version of Firefox and the plugin.. Do you have any idea as to the approximate time you would've added the key?

[dd32]

I'm thinking maybe I need to try setting up the key with a much older version of Firefox and the plugin.. Do you have any idea as to the approximate time you would've added the key?

Oh! You had it in the U2F section too? That means you setup the key prior to the webauthn plugin being installed, which yeah I'm 99% certain now that this is a algorithm issue. To duplicate this I'd need to setup a key with a much older browser that still supported U2F.

We might be able to do something like "If this key was added via U2F don't present transports; If it was setup with webauthn offer them"

[zaneselvans]

I'm also using a YubiKey 5NFC with firmware 5.4.3 that I set up before WebAuthn was available.

[jimmiedave]

Don't know that it matters here, but I've never enabled iCloud keychain - (I have no plans to do so. Apple are internet dilletantes, and I want no part. Disagree? Contact me on AppleLink. No, wait, eWorld. Sorry, no, iMessage. Oops, I mean my .mac account. Or is that mobile.me?)

Do you have any idea as to the approximate time you would've added the key?

Probably added around 11:12 AM EDT (UTC-4:00) today (local Oct 8, 24)

I haven't touched the other key (i.e. revoked, reinstalled, etc). Any idea what I might do for a test? Delete U2F config and see if that was in the way? (simply turning off U2F on Yubikey Admin doesn't do anything).