Multiple YubiKeys raise "Unrecognized name" error during WebAuthn authentication ceremony, but only in production

[Matthew Miller]

A user of one of my WebAuthn libraries raised an issue (https://github.com/MasterKale/SimpleWebAuthn/issues/345) about a couple of their YubiKey 5's raising "NotAllowedError: Unrecognized name" errors during authentication attempts. The security keys can be registered just fine, it's only authentication ceremonies that error out in this way.

What's weird is that both security keys work fine for both registration and authentication during development, when the RP ID is "localhost". They only experience this in their production instance, where the RP ID is "dashboard.file.glass" for both registration and authentication. Additionally, platform authenticators work just fine for during development and in production. It's only when authenticating with security keys that they experience this issue.

I tried searching around about this error in the context of WebAuthn, but found almost nothing about it. Noteworthy to me was the fact that including "Unrecognized name" in my search yielded many results related to SSL issues, of all things. Might there be something going on with the production site's SSL certificate that is tripping up the browser during auth? I dunno, just putting that out there because at this point I have no idea what the issue might be.

Thank you for any insights you all might have,

-Matthew Miller

[Matthew Miller]

I neglected to mention that they tried this on "Arc (Chromium) & Safari on macOS + Firefox on Windows. Same issue unfortunately. 🙁"

[John Bradley]

The RPID is placed in clientData, and a hash of client data is passed over CTAP2 to the key.  So that any security key would error directly based on the RPID.

In the case of a discoverable credential, the RPID is passed as a string but as this is on Authenticate that seems unlikely to be the problem.

My guess is that it is some sort of TLS validation issue related to what is going in client data.

Can they use the same authenticator with Chrome to authenticate at the RP if make credential works?

I don’t know what level your library is at.  If it is talking HID to the key then perhaps something is happening and it is loosing state and there is a HID error.   However that would not likely be dependent on RPID.   Those are the two places that I can think of some sort of name error happening.

John B.

-- 
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/d8843428-9c16-4abf-981f-e10c04b10d9fn%40fidoalliance.org.

[Matthew Miller]

@John: Thank you for jumping in to help! I'm happy to report that the issue has been resolved, and it had nothing to do with their security keys. It was an issue with earlier versions of NodeJS being unable to import Ed25519 keys during WebAuthn authentication response verification.

For future-me and others: I ended up adding a section to my library's docs with the solution, which is to omit `-8` from the list of supported credential public key algorithms during authenticator registration:

https://simplewebauthn.dev/docs/packages/server/#unrecognized-name-error-during-authentication

[Shahin Mahmud Khan]

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/a6a400c2-f774-451d-b775-db3f66e397a5n%40fidoalliance.org.

[John Bradley]

Yes asking for an alg you don’t support could cause issues:). 

The other thing to do is put ED25519 as a lower preference in the request. 

I am guessing that you had that as the most prefers not realizing that it would be a problem with older versions of node. 

Our CTAP2.1 keys also support P384.   You may also want to enable that as an option for future deployments. 

John B. 

Sent from my iPhone

On Feb 16, 2023, at 10:43 AM, Matthew Miller <maste...@gmail.com> wrote: