What is the point of required user verification in WebAuthn?

Question

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?

Answer 1

Preferred tells the client "I want you to do this, if you can". "Required" tells the client "if you can't do this, abort". While you're entirely correct that the server can't count on the client to enforce this, in practice these types of requirements are common ways for servers to restrict what authenticators are used, or how they're used.

For example, Yubikeys have an optional password requirement when using them. Specifying "Required" is a way to tell a Yubikey-using client "if your key doesn't have a password and you won't add one, abort; if your key does and you don't get it right, abort". That's a reasonable thing for a site to want, especially when webauthn is used for single-factor authentication (the typical "passkey" scenario). Sure, the user could instead have an authenticator that just lies to the server, but most of the time, that just makes the user's account less secure.

I suppose from a savvy user's perspective, the ideal behavior is "user decides whether or not verification is required for a given app/server; always report to the server that whatever it wants was met". This might even already exist, in software form, somewhere (I'd be somewhat surprised, though not shocked, if it exists in hardware too). But a company like Yubikey (or Google, or Microsoft, or Apple) isn't going to do that; if word got out that their authenticators (either hardware tokens or platform authenticators) let lazy users bypass the servers' security controls, that would be bad for business. Most people are not, in fact, good at risk evaluation, and even if they are (or at least, are better than the app/server), the expected model is that the developer chooses what forms of credentials their app/server accepts.

To look at this another way, there's nothing a server can do to stop you from putting your password on a sticky note and attaching it to your monitor (for traditional password auth, rather than webauthn). The site can tell you not to, you can ignore it, your boss can fire you for doing so in violation of company policy or just exhibiting terrible judgement. Similarly for webauthn (or FIDO2 in general), the server can tell the client to require user verification, the authenticator can ignore this requirement, and companies who purchase authenticators by the truckload can cancel all their contracts with the maker of the authenticator.

Answer 2

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.