-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect handling of 'preferred' user verification. #162
Comments
See my comment here: #148 (comment) IMO the spec isn't completely clear as to the correct behavior, but the behavior we have implemented is (I believe) in line with what the major platforms are doing. |
I agree that the spec could be more clear as to the correct behavior here. However I disagree that the current behavior is sensible, preferred should use UV if it is readily available, and still work regardless. So, I did a little digging. And the current behavior is definitely not how either Firefox or Chrome behave. I did some quick hunting for a for Webauthn demos that allow you to specify the user verification setting, and found: https://webauthn.singularkey.com/ This works on both Chrome and Firefox. With User Verification set to Unspecified, Discouraged, or Preferred, my Yubikey 5 with no PIN set is accepted by both Firefox and Chrome. With User Verification set to Required, Firefox simply ignores the Yubikey as not being a qualified device, while Chrome prompts for me to setup a PIN. |
@zelch Thanks - you may be right, but the CTAP2 spec is currently underspecified in regards to this. Some background: We had misremembered the WebAuthn spec saying this about the
...and that that is how Chrome behaves. However, that is only true for
and Chrome indeed does not prompt the user to set a PIN if one is not currently configured. So yes, from a WebAuthn Relying Party perspective, the ceremony should indeed proceed without requiring the user to set up a PIN. However... The There is support for this interpretation in the CTAP2 spec you linked, too. If the RP has set However... There is a logical inconsistency in the CTAP2 spec. Step 1.1. reads:
and step 1.2., which should be its logical complement, reads:
But these two statements are not logically complementary - for that, the latter should rather read "[...] AND the Relying Party [...]". Perhaps the I'll raise an issue in the CTAP spec about clarifying this. But for now, I don't think we can conclude that the current implementation in What do you think? |
Specifically, it is handling 'preferred' as 'required'.
By my reading of the Webauthn spec, the handling of 'preferred' depends of the definition of 'Protected by some form of User Verification'.
Per the spec, this requires that the support be both supported and enabled.
In 6.1.1, the text at the beginning describes the case where user verification is 'required' and not present.
It then describes the process flow, I draw some attention to 6.1.1, 1.1 where things start to go wrong in the described flow, though I will definitely note that the text at the beginning says 'In other words, this is only a brief sketch of plausible platform behavior.'
In 6.1.1, 1.1.2.2 we get to the point where the code is following the described flow... But the described flow simply does not handle this case.
The request says that user verification is 'preferred', the device has support for clientpin, however clientpin is not configured on the device.
This is currently handled in fido2/client.py, class _Ctap2ClientBackend, function _should_use_uv, on line 470.
In this code, it looks at both if uv is supported, and if uv is configured.
If user verification is REQUIRED, or if user verification is preferred and supported, or if 'alwaysUv' is set by the device, then it fails if uv is not configured for the device.
I propose that the uv_supported check be removed entirely, and in the if statement we replace:
with
This would, I believe, be both compliant to the spec, and would work for the fairly common case where user verification is preferred, but not required, and a user with a Yubikey 5 has not configured a PIN.
The text was updated successfully, but these errors were encountered: