PASSKEYS have been in the news recently and with good reason–the big tech companies are seriously ramping up efforts to move all their users to this newfangled tech.
But there's a fly in the ointment: certain influential tech people really dislike them. According to DHH:
if you sign up for a service on Windows, and you then want to access it on iPhone, you're going to be stuck (unless you're so forward thinking as to add a second passkey, somehow, from the iPhone will on the Windows computer!)...A decent alternative to passkeys, if you need the extra layer of security, is to lean on email for the first login from a new device. Treating email as a second factor, but only on the first login from that device. Everyone has email, everyone understands email. (Just don't force us all to go through magic links exclusively, as that's a pain too for those who've actually adopted a password manager!).
DHH is very close to the ideal UX for passkeys for ordinary non-technical folks, but can't quite put it together. Here's what I recommend:
Initial user sign-up
- Don't make the user set up a password!
- Send a magic link to their email
- Once they click and enter the webapp, they are in a logged-in state. Prominently show a passkey setup CTA and ask the user to set up a passkey on the device.
Subsequent logins on the same device
- Use Conditional UI to allow selecting the passkey directly from the Email input autocomplete. Browsers support this now!
- If JavaScript disabled: instead of Conditional UI and passkey login, send a magic link
Subsequent logins on a new device
- Send a magic link to the user's email address
- Once they click and enter the webapp, they are in a logged-in state. Prominently show a passkey setup CTA and ask the user to set up a passkey on the device.
Notice how this is almost exactly the same as the initial user sign up process? It's so simple and low-ceremony, it should hardly take the user out of their flow.
It doesn't need to be a whole song-and-dance about having to 'recover' the account on the new device! There's nothing to recover. The user can just log in with a magic link and set up a passkey so that the next login is even easier. That's all!
Obviously, for this UX to work, the app must support being able to store multiple passkeys per account. This is non-negotiable! Passkeys are cheap and easy to store. There's no reason to be overly restrictive here. Once this is supported, you never have to worry about password leaks again. And your users never have to worry about getting phished (in the sense of accidentally entering their credentials into third-party sites).
Prominent security experts agree - passkeys and magic links basically solve the password problem for regular users. We can effectively retire passwords now.
Top comments (14)
Wow I had the exact same ideas with you (apart from the Conditional UI which I didn't know about - thanks!) and I made magicentry.rs!
An OIDC targeted for self-hosters which has only 2 ways to log in: magic links and passkeys. that's it.
It uses a static YAML config for everything and uses a tiny integrated DB to keep track of sessions. It has "good enough" k8s integration though I want to expand it a bit. It's written in Rust and I use it daily!
It's important to consider the workflow of a user wanting to sign in on a device using which they cannot access their email. For instance, if I'm using my work computer to do something and want to sign in there, but I'm not allowed to access my (personal?) email from my work computer, I cannot click a magic link. A fancier workflow I've seen is that clicking on the magic link enables the requested session to proceed, no matter on what device it was requested.
Most likely, the remedy here is on the user: use a password manager that makes passkeys portable.
This is an extremely bad idea. All a scammer has to do is to convince you to click on the magic link and they can remotely gain access to your account. We absolutely do not want to expose users to this risk. Even technically-minded users can be tricked by putting the right pressure on them.
Forward the magic link from your personal email to your work email, then click on it there.
That still doesn't solve the issue of logging in to your e-reader or smart TV that don't have email access (and shouldn't have email access).
Obviously, auth methods are not suitable for every device and form factor. I recognize that some devices shouldn't have email access. These devices will need to use other methods, like QR codes or tokens. And they are doing this successfully now.
If you look at the vast majority of auth scenarios now, it's logging in to webapps, which can be handled just fine by passkeys with a magic link email fallback.
No, those devices need other methods, like passwords. And they are doing this successfully now and they have been doing so for decades.
If by 'successfully' you mean 'The amount of phishing today is higher than it has ever been'.
By successful, I mean signing people in without any fuss or nonsense.
Phishing is not a password problem. It is a "Google, Microsoft and other Big Tech companies can no longer be bothered to protect people from phishing."-problem
This is not just wrong, it's on a completely different level of wrong. These big service providers are highly incentivized to protect their users from phishing. Do you think they like having to support users who constantly get phished and locked out of their accounts? That they are not trying their utmost to prevent it? That they are pushing for new phishing-resistant auth methods like passkeys exactly because of this problem?
You realize you are talking out of both sides of your mouth, right? First you accuse them of not doing anything to protect their users from phishing, then you accuse them of doing too much by asking people to use passkeys instead of passwords?
No. Password managers should not be hijacked to deal with passkeys. If passkeys need to be portable, then the people who are promoting them need to build their own passkey managers.
So now you suddenly have to enable e-readers and smartwatches and all other sorts of tech to read email just to be able to log in instead of just allowing the user to set a password and not overcomplicating the devices themselves.
When will developers finally stop promoting passkeys and just get on with it and just offer users the passwords they need? All those articles pushing passkeys are getting old fast and if I had wanted to use passkeys, I would have done so already. Fact is, they are not suitable for purpose and I will not use them until that issue is resolved and the standards are no longer controlled by FIDO or any of its members.
I am fairly sure you know that passwords and OTPs are super easy to phish. There are nowadays easy to use AiTM toolkits that set up reverse proxies with legitimate-looking fake login pages to collect credentials. Passwords and OTPs have essentially failed as an auth mechanism. Phishing account takeovers are worse now than they have ever been. Passkeys offer a solution to this problem. This is why they will have broader uptake, in many cases encouraged by government regulations as well.
In this setup, why do users need to deal with Passkeys at all? Isn't this an implementation detail?
Users need to deal with passkeys in this setup because the backend needs signatures that the frontend can provide only by unlocking the passkey. And the passkey can only be unlocked by the user's passkey manager.
But even in this scenario the user may not even need to do anything special. If the user's passkey manager decides that the user has already been securely verified, it can optionally just unlock the passkey without having to force the user to do verification yet again. For the user, it may end up being as simple as 'select my account from the Email input dropdown and I am immediately logged in'.