Importantly, if you switch platforms you lose all your auth tokens and have to reauth everywhere. It ultimately is yet another way to do vendor lockin, except it has the FIDO alliance's blessing this time.
The competition, password managers like 1password and bitwarden, do not have any sort of vendor lockin. You can freely export your passwords from one manager and into another.
Plus, password managers have fantastic backwards compatibility even on old, crufty sites that will never be updated.
We really should be working to allow better, standardized integration with password managers (communicating password length and alphabet requirements, well-known URIs to do zero-touch credential rotation, etc.) rather than trying to do "Log in with BIGCORP" in another way.
If you can extract tokens from a device, then they're basically passwords, not tokens — i.e. anyone who can hack your device can get them. Tokens only add multi-factor security insofar as they have distinct exfiltration requirements from passwords.
Services that properly support MFA should simply support accounts having multiple bound authenticator devices, each with their own private key/seed. In such setups, the proper way to rotate out an authenticator device is to add a new device first, and then remove the old device; and the proper way to protect against a lost device, is to keep an extra bound device in safe cold storage somewhere (e.g. a safe deposit box.)
Basically, look at how the crypto people handle the "hardware wallets" (really, smart cards) they use for multisig transactions. 2-of-3 confirmations, two hot smart cards held independently by company officers, one cold smart card held by e.g. the company's law firm.
Your first paragraph, restated, is that passwords are superior to tokens.
Your "proper way" is absurd and nonsensical for the vast majority of users. The first time they get burned by this is the last time they'd rely on anything but the one memorized password they reuse everywhere.
MFA itself is absurd and nonsensical for the vast majority of users. It's security theatre unless you do it right, and if you're doing it right, it's — as you've said — too hard for most people to bother. Properly implemented, MFA is an Enterprise feature, not a personal feature. Like SAML SSO, or having audit-log APIs.
The point of setting up MFA is to secure things that really need to be secure, where the person with the data is aware of real attacker threat-profiles that have real interest in their data. It's a thing that companies that hire CISOs care about.
Any implementation of MFA you see in the wild is either part of a product that has an enterprise tier that has customers like that, where the product devs decided to "trickle down" the feature [in a less-secure, but possibly optionally secure, form] to lower plan tiers; or it's a cargo-cult reimplementation where a company "saw other companies doing it and it seemed like a good idea" — but they exchanged actual security for convenience.
(You can usually distinguish one from the other, because the companies "actually doing MFA" will almost always support smart-card authenticators — and have for decades, back since doing so required a Java applet. Because "issuing each employee a smart card" is what companies that actually care about cybersecurity
— e.g. defense contractors, investment banks, etc. — do as a matter of course.)
The goal of all this is to make auth tokens be single-factor, not one factor in MFA. If you read the Ars article linked elsewhere in the thread the people behind it are pretty clear about their desire to get rid of passwords.
The security of these tokens is still MFA as an end-to-end security model, insofar as you need a something-you-know [password, passcode] to unlock the device that serves as your something-you-have. So someone who just steals the device, can't use it to authenticate as you. (See also: smart cards having PINs.)
And, once again, companies doing MFA properly, enforce MDM policies on such devices, such that they either don't allow you to use the convenience biometric unlock features, or they limit them to ~1 minute before you must unlock with a something-you-know factor again.
(I worked for IBM for a year-or-so a while back; they required this even for phones not serving as MFA authenticators, because they had a threat model that included attackers cloning your fingerprint just to snoop company secrets out of the emails on your phone.)
As far as I understand, the story is: casual users don’t choose unique passwords. MFA, even in its weakest forms like SMS, defends against credential stuffing. Indiscriminate credential stuffing attacks based on database dumps, etc. are common enough that this is worthwhile. FIDO/WebAuthn add protection against phishing (because the token is bound to the domain name). Phishing is also a common indiscriminate attack against casual users.
In a world where people used password managers correctly and all the time, this might be redundant, but we don’t live in that world.
Isn't this already mostly covered by browsers (like Safari!) doing strong non-memorable password autogeneration + password sync, such that the password in the password field is already essentially acting like a token for these people?
As a long-time Safari user who uses keychain heavily in lieu of 1Password or other managers, I probably will migrate to using Passkey because it sounds pretty seamless.
But the lock-in point seems like a founded critique. Does anyone disagree with this claim?
I'm not sure this is any more locked in then the parent post is locked into 1password. Moving auth tools is a pain.
Anyone implementing FIDO should allow you to enrol multiple devices. As long as the auth consumers allow multiple keys, there's no lock-in. You just need to setup your new device before ditching apple.
Looking at how various places do 2FA, it's likely that at least some websites will not support multiple keys even if they ought to.
Also, I imagine that many people do not have the luxury of multiple devices. So if you lose your phone, you'll need to buy or at least borrow another iOS device to recover it from iCloud before you could switch to Android.
How common would it be for someone who has just lost their phone to want to immediately switch platforms? Isn't it much more likely that they'd want a new device on the same platform as the one they just lost?
If they were already planning to switch platforms, the loss or destruction of their old device provides a natural moment to make the switch, where buying a new device feels like it's locking yourself in for another couple of years.
I think they must know they need to have some sort of migration/export strategy. Maybe its just to early for that to be implemented yet. I mean I'm not even aware of any websites that support Passkeys as the sole auth method.
The competition, password managers like 1password and bitwarden, do not have any sort of vendor lockin. You can freely export your passwords from one manager and into another.