Re: [webauthn] How can we trust authenticator data flags in fmt:none response from `.create()`? (#1698)

The short answer is that indeed, you "cannot" trust the authenticator data flags without a trusted attestation (this applies equally to self attestation, as the public key can be replaced along with the signature), but the longer answer is that it depends on your threat model, what you mean by "trust", and whose trust you're talking about. Let's consider a few scenarios:

## 1. UV on the user's initiative

In this scenario, the RP doesn't really care what authenticator is being used, it only wants to _enable users_ to customize their authentication experience. For example, some users may choose an authenticator that always requires UV, even if the RP doesn't care about UV. As long as that user trusts their chosen authenticator, they can be assured that UV is required to access their account if they don't have any other sign-in option set up.

So in this case the RP "trusts" the user to choose what's best for them, and the user "trusts" their own choice of authenticator. Attestation is not necessary, because the RP only cares about getting a signature from an already-registered public key.

## 2. UV as a "best effort"

In this scenario, the RP may require UV for some interactions, for example as an alternative to a traditional password, but isn't really worried about the flag's authenticity. If the user happens to be using an honest authenticator and browser, which most users probably will, then this gives a reasonable assurance that UV was _probably_ actually performed. There's still the possibility that some users might use a homegrown software authenticator that lies about the flags for user convenience, but if so, that's the user's responsibility. Perhaps a bigger issue is if the user is using a public computer infected with malware, but the malware can only tamper with the flags during the initial registration ceremony, not any subsequent authentication ceremonies if the registration was done securely. And if there's malware on the client, it can just take over the account after a successful login anyway.

So in this case the RP is nudging the user towards higher security, and for most users most of the time, that nudge will be enough. The RP might request and store attestation statements for future reference - for example to warn users if an authenticator model is discovered to be insecure - but it's not strictly necessary since much like the previous scenario, the RP largely "trusts" the user to not do anything stupid. Especially if the RP also factors in other signals like geolocation data, this might be the best balance of security, usability and customizability.

## 3. UV strictly required

In this scenario, the RP _requires_ UV and _requires_ that the flag be verifiably authentic. For example, the RP may be subject to legal regulations that require certain security properties. In this case the RP simply must require attestation and only allow explicitly trusted authenticators, because there's no other way to know that the user, authenticator and/or browser isn't lying. It doesn't matter if the user wants something else, because the RP is compelled by law to forbid anything not _known_ to be secure and trustworthy.

---

So depending on the situation, your answer to "how can we trust [...]" will vary greatly since "trust" might mean different things. But yeah, strictly speaking the RP has no _guarantee_ that the flags are authentic with "none" or "self" attestation.

-- 
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1698#issuecomment-1035215931 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 10 February 2022 17:37:09 UTC