Inconsistent behaviors on Windows for admin and non-admin

[ohnowade]

Hi,

I am developing an authenticator that uses libfido2 to talk to the security tokens. However, I encountered some inconsistencies when testing on my Windows laptop (Windows 10 Version 22H2, no Windows Hello set up due to company policy, and one fido device plugged in). I have tried setting USE_WINHELLO to ON and OFF when building libfido2, running the application on and off Admin, and calling fido_assert_set_uv (with either FIDO_OPT_FALSE and FIDO_OPT_TRUE) and not, but different combinations seemed to have different behaviors:

• USE_WINHELLO is OFF, Admin, Not calling fido_assert_set_uv: one device is detected, the assertion succeeds, but there is no system UI popup during assertion.

• USE_WINHELLO is OFF, Admin, Calling fido_assert_set_uv: one device is detected, the assertion fails automatically, and there is no UI popup.

• USE_WINHELLO is OFF, Off Admin, Not calling fido_assert_set_uv: no device is detected.

• USE_WINHELLO is OFF, Off Admin, Calling fido_assert_set_uv: no device is detected.

• USE_WINHELLO is ON, Admin, Not calling fido_assert_set_uv: two devices are detected. The first device is not recognized as winhello, the assertion succeeds if I press my token, but there is no system UI popup during assertion. The second device is recognized as winhello, the assertion does not work, and there is a system UI popup saying "Can't read your security key. Please try again.".

• USE_WINHELLO is ON, Admin, Calling fido_assert_set_uv: two devices are detected. The first is not recognized as winhello, the assertion fails automatically, and there is no UI popup. The second device is recognized as winhello, the assertion succeeds, and there is a system UI popup during assertion.

• USE_WINHELLO is ON, Off Admin, Not calling fido_assert_set_uv: one device is detected, the device is recognized as winhello, the assertion succeeds, and there is a system UI popup during assertion.

• USE_WINHELLO is ON, Off Admin, Calling fido_assert_set_uv: same as above.

Therefore, I am wondering why the behaviors are not consistent, and if there is anyway to make them consistent on and off Admin? Below are my other build options for libfido2:

• BUILD_SHARED_LIBS=OFF
• USE_HIDAPI=OFF
• BUILD_TOOLS=OFF

Thank you so much!

[LDVG]

Hi,

Administrator vs. user access of authenticators

As a regular (unprivileged, non-admin) user, the only way to communicate with an authenticator on Windows is through webauthn.dll which libfido2 exposes as the windows://hello pseudo-device (if USE_WINHELLO was enabled at compile time). When you're running your application under escalated privileges, libfido2 will also be able to communicate with the device directly.

When running in an unprivileged context you will always only see one device (windows://hello) regardless of how many are actually plugged in; webauthn.dll handles authenticator selection in an opaque manner. Under escalated privileges, you'll also see every actual device listed.

windows://hello and user verification

As webauthn.dll does not expose any methods of communicating with the authenticator directly but instead offers only a high-level interface for creating credentials and getting assertions, there are some caveats as to how the windows://hello device is plugged in to the libfido2 API (which is modeled after a lower level of access).

One such example is that while libfido2 aims to offer the application the choice whether to use clientPin (by passing a PIN to functions that accept one) or ask the authenticator to perform built-in user verification (by calling fido_assert_set_uv()).

However, webauthn.dll does not have this distinction of user verification methods. It merely offers the application to ask for some form of user verification. Therefore, setting fido_assert_set_uv() may work on a windows://hello pseudo-device that is backed by an authenticator that only supports clientPin (and not built-in UV) whereas doing the same on the raw device will fail.

System UI

Using the windows://hello pseudo-device will show a system dialogue. Any other libfido2 device will not. It will be up to the application to prompt the user appropriately.

"Can't read your security key. Please try again."

I have not seen this exact error message before. Given that the authenticator was just involved in an assertion ceremony using another backend, it might just have indicated that it's still busy. Is the error consistently appearing even if you do not perform another assertion using the "first device"?

Achieving consistency

• For unprivileged access, you must use the windows://hello pseudo-device.
• For a system UI to show up, you must use the windows://hello pseudo-device.
• For consistency with user verification -- you can improve the situation slightly by not blindly calling fido_assert_set_uv(). You can query the device's capabilities through the fido_dev_{support,has}_pin() and fido_dev_{support,has}_uv() functions.¹

Happy to try and clarify any of the above if necessary.

Footnotes

1. Note that we cannot introspect the capabilities of the windows://hello pseudo-device and fido_dev_has_uv() will always return true when called on it, regardless of the actual capabilities of the plugged in authenticators. This means that the assertion may fail for authenticators that do not support any form of user verification if fido_assert_set_uv() is set. ↩

[ohnowade]

Thank you so much for the response! They are really helpful and clear most of my confusions.

The only thing is that, regarding the second error system UI when running with Admin, it is a consistent issue and occurs if I don't perform assertion with the first device.

I also tried to fetch the manufacture string from the device. When I run with unprivileged access, the string of the only recognized device is "Microsoft Corporation Windows Hello", which makes sense since we are using windows://hello pseudo-device. However, when running with Admin, the string of the first device is something like "Yubico Yubikey", while that of the second device is "Microsoft Corporation Windows Hello".

Given that the authenticator was just involved in an assertion ceremony using another backend, it might just have indicated that it's still busy

Based on the information above, I guess maybe the Admin access enabled it to recognize both the raw device and the pseudo-device. Our handling logic is that, if multiple devices are present, we give each device a 10s timeout through fido_dev_set_timeout. So when it invoked the first device, I did not do anything and let it timeout, and when it tried the second device (which essentially was the same device), the device indicated that it's still busy. But please correct me if I'm wrong, since I'm not sure if a timeout should fully close the device.

It merely offers the application to ask for some form of user verification. Therefore, setting fido_assert_set_uv() may work on a windows://hello pseudo-device that is backed by an authenticator that only supports clientPin (and not built-in UV) whereas doing the same on the raw device will fail.

Based on the information above, since all our devices only support on-token pin but not any built-in UV, if I blindly call fido_assert_set_uv() on the first device (raw device), it automatically failed, and then we tried the second device (pseudo-device). My guess is that since the first device was never invoked, the second device was not busy and succeeded, which might explain the difference in behavior between the calling and not calling fido_assert_set_uv() when running in Admin.

Please correct me if any of the above guess is incorrect. Thanks again!

[LDVG]

Based on the information above, I guess maybe the Admin access enabled it to recognize both the raw device and the pseudo-device. Our handling logic is that, if multiple devices are present, we give each device a 10s timeout through fido_dev_set_timeout. So when it invoked the first device, I did not do anything and let it timeout, and when it tried the second device (which essentially was the same device), the device indicated that it's still busy. But please correct me if I'm wrong, since I'm not sure if a timeout should fully close the device.

fido_dev_set_timeout() only stops the client processing after the specified timeout. By setting it to 10 seconds, the authenticator is probably still processing the request, likely waiting for a touch (user presence check). To cancel a pending request, see fido_dev_cancel() and our assert.c example.

Based on the information above, since all our devices only support on-token pin but not any built-in UV, if I blindly call fido_assert_set_uv() on the first device (raw device), it automatically failed, and then we tried the second device (pseudo-device). My guess is that since the first device was never invoked, the second device was not busy and succeeded, which might explain the difference in behavior between the calling and not calling fido_assert_set_uv() when running in Admin.

This sounds like a correct analysis -- the authenticator stopped processing the request early since it could not fulfill the requested options.

[ohnowade]

Got it. Thank you for your help!