When signing up on a Windows machine with Firefox it doesn't let me use Yubikey but prompts for a Windows Hello PIN instead. Canceling the dialog doesn't go to the next available method (like it normally does) but just retries once again, after a second cancellation it just gives up. I'd say this makes this whole thing completely unusable, because under no circumstances would I ever want to use a machine-bound authenticator (unless that's the only option I physically have). I really cannot think of any reason, it won't give me any extra security and it will make things needlessly complicated in event of device loss.
To make it worse, when I'm trying to sign in, it prompts me for my Yubikey PIN, and not Windows Hello PIN. Basically, multiple token support is badly messed up.
Using a physical key in Windows now requires you to enter the pin to unlock your Yubikey (or set a pin) before you can use it to register.
This is an issue we've run into a lot at $work where users will forget their FIDO2 pin cause its only used during registration, and never after that, and when they reset the pin it destroys all their previous known 2FA (which is expected).
I'm aware about this requirement, and it makes sense. Obviously, I want the authenticator device protected, so I must know the device PIN or password to unlock it.
It's exactly the same for Windows Hello built-in authenticator, they require a PIN (or face, or whatever other means you have configured) for the computer itself. Same for iPhones, you need a PIN or password to unlock it. It's merely a matter of frequency (phones and laptops are unlocked daily, Yubikeys - depends on the individual), and if use of hardware tokens is prohibited (or even discouraged) from the very beginning they'll never have a chance and the world would go the path of least resistance once again.
I'm curious if resetting a PIN or password on Windows or macOS or iPhone OS would retain the Passkey identities. I suspect it would...
> 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.
> I'm curious if resetting a PIN or password on Windows or macOS or iPhone OS would retain the Passkey identities. I suspect it would...
Depends on the process for changing the PIN/password. The desktops may have an option to log in with the cloud account, which can have separate recovery processes.
If I lose my PIN to my iPhone though, pretty much my only option is a device reset. The difference with Passkeys is that they are bound to an iCloud account, not the hardware - so I get them back on device restore.
Some of the security key enterprise and government customers also don't necessarily want credential backup/restore. Handling the account recovery and key registration process in their environment has more quantifiable risk than having it as an external process.
To make it worse, when I'm trying to sign in, it prompts me for my Yubikey PIN, and not Windows Hello PIN. Basically, multiple token support is badly messed up.