Way better option: emailed OTP code and passkey with Conditional Mediation UI. If the user is logging in from a device that already has a passkey, the CM UI will let them just select it and log in instantly. If they are logging in from a device which doesn't, we can make the UX such that it asks them to enter the emailed code, and after that is successfully it immediately asks the user to set up a passkey for instant sign-in.
This gets the best of both worlds: the security of passkeys on existing devices, and the passwordless setup and account recovery for new devices.
Bonus: it even avoids vendor lock-in where cloud providers have all your passkeys.
True, but pushing passkeys as the primary auth method reduces the risk to a great extent. It's a huge difference. As long as the user keeps using a relatively stable set of devices, they will 'approximately never' be exposed to MITM.
Also, when logging in from a new device, many accounts which use password-based auth today send a confirmation email and ask users to either enter the emailed code or click on the link. This is part of their existing security protocol. So we are not introducing a new unique thing here.
> As long as the user keeps using a relatively stable set of devices, they will 'approximately never' be exposed to MITM.
As long as the user keeps a relatively stable set of devices and knows to be suspicious if they get asked for an OTP on a device that they know has a passkey. If they don't know to be suspicious (which let's be real, most people won't), they'll happily follow the instructions and fork over the OTP to a phisher who can use it to complete the authentication somewhere on their end.
Magic links without an OTP fallback are more secure as the initial setup process because they can't be phished unless someone's actually MITM'ing their HTTPS traffic (at which point nothing can save you anyway). A phisher can get someone to send themselves a magic link, but it's much harder to get them to provide the link to them.
> Magic links without an OTP fallback are more secure as the initial setup process because they can't be phished...but it's much harder to get them to provide the link to them.
It's not that much harder. 'Due to security reasons, please copy and paste the entire link that we just sent you into the following input box. If you don't, your account will be compromised!'
That's way harder than just asking someone to do the exact thing that they've already done over and over on your legit site. Sure, some will still fall for it, but the bite rate will go way down.
Phishing attempts by definition create artificially urgent abnormal situations whose job it is to convince the intended victim that they're legitimate. A difference in degrees like this strikes me as not really something to haggle about. Users who fell prey to the attack aren't going to be reassured on hearing how much more unlikely it was.
This gets the best of both worlds: the security of passkeys on existing devices, and the passwordless setup and account recovery for new devices.
Bonus: it even avoids vendor lock-in where cloud providers have all your passkeys.