Difference behavior between Windows and MacOS during registration

282 views
Skip to first unread message

Andrew Jun

unread,
Dec 19, 2024, 2:02:55 AM12/19/24
to FIDO Dev (fido-dev)
Hi everyone,

I'm encountering an issue where the behavior of AuthenticatorGetAssertion differs between Windows and macOS when registering the fido2 biometric key. Here's a summary of the problem:

macOS: The pinUvAuthParam field is correctly populated, and the process_get_assertion() function works as expected.
Windows: The pinUvAuthParam field is blank, causing the pin_uv_auth_precheck() function to fail.

Here is the relevant portion of the code in pin_uv_auth_precheck():

if auth_param.is_empty() {
    check_user_presence(env, channel)?;
    if storage::pin_hash(env)?.is_none() {
        return Err(Ctap2StatusCode::CTAP2_ERR_PIN_NOT_SET);
    } else {
        return Err(Ctap2StatusCode::CTAP2_ERR_PIN_INVALID);
    }
}

According to Section 6.2.2 of the CTAP specification:

If pinUvAuthParam is zero-length, the authenticator should:
Request evidence of user interaction.
Return CTAP2_ERR_OPERATION_DENIED if the user declines.
Return either CTAP2_ERR_PIN_NOT_SET (if no PIN is set) or CTAP2_ERR_PIN_INVALID (if a PIN is set but invalid).
On Windows, the blank pinUvAuthParam causes the function to fail with CTAP2_ERR_PIN_INVALID, while macOS does not exhibit this issue.

It’s worth noting that the same GetPinUvAuthTokenUsingUvWithPermissions command response is sent to both hosts. My suspicion is that during the registration it might be sending a blank pinUvAuthParam based on the authenticator's response, but the behavior diverges between platforms.

Questions:
Has anyone encountered a similar issue with Windows handling pinUvAuthParam in WebAuthn workflows?
Could this be related to differences in how Windows processes the GetPinUvAuthTokenUsingUvWithPermissions response compared to macOS?
Is this a potential bug in registration, or could the authenticator's implementation be at fault here?
Any guidance on why this discrepancy occurs and how to resolve it would be greatly appreciated. Let me know if additional logs or details are needed for context.

Thank you!
Andrew Jun
The Veridian, Inc.

Claus Steuer

unread,
Feb 27, 2025, 5:05:30 PMFeb 27
to FIDO Dev (fido-dev), Andrew Jun

Hi Andrew,

I encountered the same problem today on Windows when trying to enroll a FIDO security key with the Keeper Password Manager Desktop application. Windows sends a makeCredential with an empty pinUvAuthParam to which the security key responds with CTAP2_ERR_PIN_INVALID after user presence has been confirmed.

I assume that this is a bug in Windows Hello. Probably Windows looks at the getInfo response first, and when clientPin=true and makeCredUvNotRqd=true, it sends a zero-length pinUvAuthParam. When no PIN is set (clientPin=false), it works, as Windows does not send a pinUvAuthParam in the makeCredential request. If a PIN is set but makeCredUvNotRqd=false, it works as well, as Windows first asks for the PIN and then sends a valid pinUvAuthParam.

Using an authenticator with CTAP 2.0 or CTAP 2.1 Pre also works, as those do not have the makeCredUvNotRqd option.


Greetings
Claus

My1

unread,
Mar 3, 2025, 12:30:25 AMMar 3
to Claus Steuer, FIDO Dev (fido-dev), Andrew Jun
so basically they tried making it compatible with the 2.1 addition of not needing a pin for a non-resident registration, but forgot a section that checks the pinUvAuthParam and therefore kinda shoots itself.

considering that (as far as I remember) that new option only applies to resident credentials (or if credprotect hasnt been set higher), so either having credprotect on a higher level or registering resident credentials should bring up the authentication section properly.

--
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 [email protected].
To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/6157125e-1843-46c7-8233-ee98ddea134cn%40fidoalliance.org.
Reply all
Reply to author
Forward
0 new messages