> I'm aware about this requirement, and it makes sense.
See, pins for yubikeys don't make much sense to me. If you have to enter a PIN and press the button on a token, that doesn't seem very different to entering a password and pressing the button a token which U2F has offered for years.
Entering a PIN is known as "user verification." The point is to prove not just that you posses the key but also that you know a secret about the key. This is better than passwords for a number of reasons. The pin doesn't need to be secure in the way that passwords need to be secure. The pin is only sent between your browser and your FIDO2 device. If you some how learned my pin you couldn't do anything with that unless you also stole my yubikey. And you can't brute force the pin. Guess the wrong pin more than 10 times on my yubikey and the key will erase itself.
Pins make a lot of sense when you start using a yubikey as your primary form of authentication (instead of as a second factor). Note that there are other ways to perform 'user verification' besides a pin. For example, biometrics are specified in the FIDO2 spec, and implemented by yubikey in their Yubikey Bio product.
The reason they are referred to as PINs rather than passwords is that they are locally set and entered, without being shared with external network systems. Since they are being used to augment the physical security properties of the hardware device, the PIN can also be far simpler than a typical password - someone has to steal your hardware before they can contemplate forcing the PIN.
This additional user verification over the physical factor is used for two purposes:
1. The site can request user verification as part of accepting this system as a one-stop replacement for their current two-factor authentication systems.
2. Enumerating what credentials are on a key is often PIN-protected, so that someone who has temporary access to your security key (such as at a border checkpoint) can't inspect which sites you have logins against without your knowledge/consent.
This second one is the more annoying of the two - I might have the system request my PIN just so it can tell whether that particular security key is a viable source of credentials for a particular site.
> 2. Enumerating what credentials are on a key is often PIN-protected, so that someone who has temporary access to your security key (such as at a border checkpoint) can't inspect which sites you have logins against without your knowledge/consent.
This part of the overall design seems problematic to me. These “resident” keys are described as “passwordless”, but they’re really username-less. And an attacker who gets the security token can not only log in but they can also enumerate all credentials. Ouch!
ISTM a much better design would have been to put the credential list on the browser side. If I log into a website that I’ve used before from the same browser, the browser’s credential manager can remember my username (and optionally key handle) and the external token can do a normal authentication. No website state is stored on the token, and the experience is almost as good — the user only ever needs to enter their username once per browser.
See, pins for yubikeys don't make much sense to me. If you have to enter a PIN and press the button on a token, that doesn't seem very different to entering a password and pressing the button a token which U2F has offered for years.