Prevent username enumeration by returning things even if the username isn't found?

[sixcorners]

Currently it looks like this returns an error if the username isn't found. This can make it easy to test to see if a user is registered. It's possible to make the response look like the response when there is a found user to make it harder to determine if one exists. It's talked about here: https://www.w3.org/TR/webauthn-2/#sctn-username-enumeration

[emlun]

Yes, that is a potential problem, but it should be up to the parent application to decide how to handle it. If we were to introduce this capability it would be an explicit opt-in feature, not a default behaviour.

And although I did help write that section and the suggested countermeasures, it's actually not that obvious how to go about generating fake values in practice. For starters, how many fake credential IDs should you return? Say that most of your real users have 0, 1 or 2 credentials, but a small minority have as many as 4 or 8. You wouldn't want the fake generator to output a constant number of credentials, as that number would be fairly easy to detect by probing it with a large number of definitely-bogus usernames (freshly generated UUIDs, for example). So what random distribution of number of credentials? You'd want it to mimic the actual distribution as closely as possible, so that for example a list of 8 credentials isn't clearly a fake nor clearly real. There's no obvious choice of a "default" distribution we could hard-code into the library. Alternatively you could append fake credentials even to existing accounts so that all accounts appear to have, say, 10 credentials - but in that case, a list with 11 or more credentials would again stand out as clearly real. So again there's no obvious upper limit to set without knowledge of the distribution for that particular application.

Next, many authenticators create credential IDs of one or a few consistent lengths, so the length of a credential ID is a fairly strong indicator of what kind of authenticator created it. The fake generator would need to imitate the credential ID lengths of real authenticators, in plausible proportions of market share, in order for them to not stand out as fake.

It's also possible - though I haven't investigated this - that some authenticators might produce credential IDs with some consistent, detectable structure. If such credential IDs appear in a response and the attacker knows how to recognize them, that's a fairly strong indicator that the response is real rather than faked, unless the fake generator knows to include such examples. The FIDO Metadata Service (MDS) currently lists some ~170 different U2F and FIDO2 authenticators; it would be a lot of work to keep up with the particular quirks of each and every one. And the MDS isn't even an exhaustive list - WebAuthn is an open standard, anyone can create their own authenticator (in software or hardware) and use it anywhere that doesn't enforce restrictions on authenticator attestation.

All in all, it's not clear how effective this countermeasure would be even if we did implement it. Even if it doesn't have to be perfect, it would be irresponsible of us to claim any true benefit without evidence to support it. We would need to conduct some research on what the common real-world distributions are if we're to have any confidence in how good the fake generator really is, and that has so far not been a priority. I would be interested to see it if any such research exists, though.