I understand that passwordless auth is better UX. But it seems like a step backwards in security from two factor authentication. Why are all these major players pushing passwordless auth but not allowing a password in conjunction with a FIDO2 token? I feel like I’m missing some important detail.
The missing important details: for reasons I do not completely understand, FIDO uses very non-obvious definitions of the words password and PIN. To them a password is a text string provided to an online service for authentication purposes and a PIN is a text string provided to a physically near hardware device to authenticate to that hardware device, after which that hardware device can sign challenges that can be used to authenticate to an online service. When they talk about passwordless they are not precluding the use of a PIN. The PIN gets you your second factor without being stored on a bunch of different services, and with hardware assisted protection from exfiltration and brute force cracking.
Relying parties (aka online services using FIDO protocols) have a lot of freedom to define exactly how restrictive they want to be by making choices about which devices they accept. Through choosing which devices they accept they can choose to require any combination of token, PIN, biometric, and password.
>Relying parties (aka online services using FIDO protocols) have a lot of freedom to define exactly how restrictive they want to be by making choices about which devices they accept.
For anything consumer facing (vs employee/contractor facing), the expectation is that a relying party site accepts everything, or supports a set with a clear industry-defined set of limitations (e.g. must have gone through certification and achieved a certain level such that they meet our security regulations).
The set of limitations which you can set during an authentication request are pretty minimal, on purpose - so you will typically have more prompts and more user errors if you decide to try and limit consumer choice.
Other than that, the expectation is that you do not block end users if they e.g. are using one vendor or the other. You may still ask them to perform additional authentication steps, but the goal is that people do not get conflicting requirements across relying parties that leads them to have to carry a key ring of different vendor USB authenticators in order to be able to do their business.
Then don't provide the attestation. No sites I've used (Facebook, GitHub, login.gov, Google, and so on) require attestation. It's unfortunate that the WebAuthn standard requires it be possible for them to ask, but you can just say "No" and I do.
Once you use them as the gatekeeper for auth ans identity, it becomes that much harder to delete that Facebook or switch phone brands. Not to mention much deeper insight into your activity everywhere.
So does this system not require that I set a password for my account?
Everything I have read about this approach seems to imply that passwords are still used, only perhaps not as often.
For instance, there's this quote from the article:
"Bellovin and others say one potentially tricky scenario in this new passwordless authentication scheme is what happens when someone loses their mobile device, or their phone breaks and they can’t recall their iCloud password."
Yes, of course this protocol can't somehow prevent sites from having a password (as a last ditch backup, or for any other reason) but it's intended to be used without passwords and, if you choose and have a more capable device, even without usernames.
Well, I hope you're right that passwords are essentially remnants of previous authentication schemes and not something implicitly required by this new scheme.
I could see us ending up in a world where we need a password to access the device on which the key is stored and more passwords for account recovery and access to key backups.
