User verification in WebAuthn can either be required, preferred, or discouraged. The last two are a hint to the authenticator that may be ignored. I see how they could be used to prevent client-side user verification if the server has already asked for a password in a previous step.

Required does sound like a requirement, not a hint. But it could easily be ignored/faked by a malicious authenticator. There is no way for the relying party to know. How is this different from "preferred"? Or is this just meant to be a stronger hint?

In other words: What guarantees does the relying party get? Do I understand correctly that it cannot be sure that user verification has really happened?


1 Answer 1


Just to be sure - are you asking if the User Verification (UV) parameter allows bypassing the webauthn verification if the user has already provided a password? If so, that's not the point - your application can decide that (e.g. if a user tries to log in in rapid succession, or for the first time with that IP, etc.) then you do the 2nd factor.

If you send a webauthn challenge, you only have to wait for the response and validate it. The UV is just a flag you'll get in the response that says whether the user verification was done or not (e.g. if a PIN was entered or fingerprint scan was done). But the security device will have to respond to the challenge (or timeout), it's not optional.

With a mobile phone, the UV is the fingerprint/face scan.

I've got a bunch of cheap 10$ security keys I use for testing. Those just have a big flashing button I press, no user verification is possible. So anyone who steals those from me would get full access. Also, those keys fail to register with my application if UV is Required. I think that's the proper behavior.

If you've got a public web app, it's not on you to check whether the authenticator is compromised or not. It just has to respond properly (the challenge signature is valid). If we're talking about an enterprise or government setting, all keys provided to employees must be provided by the employer anyway. I worked for governments and we used Entrust Tokens, nothing else was allowed in prod.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .