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.
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.
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.
I believe some password managers also look at the regex attribute to understand required or disallowed characters.
For resetting passwords there‘s at least a way to deep link to the right page: https://web.dev/change-password-url/
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 "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.
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.
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.)
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?
But the lock-in point seems like a founded critique. Does anyone disagree with this claim?
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.
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 are these handled in Chrome/FF/Windows/etc.