Hacker News Reader

I think as Ricky wrote last week [1], they should augment Magic Links or other auth methods. There are some positives about Magic Links for sure (though I don't know if making your email an even stronger attack vector is necessarily one of them), but for people who use a password manager, for example, they are a definite friction point that I think passkeys most certainly could alleviate.

There are definite UX problems around passkeys that could be improved and I think exporting will make syncing across systems a lot better (one of the reasons I use 1Password as my primary password and passkey system is so I can use my passkeys across devices; of course it helps that my employer uses 1Password as our system so I am logged into my personal and enterprise accounts and can auth then from personal or work devices, provided additional auth or enrollment isn't needed) -- but if the problem as 404 defines it is that they don't want to be responsible or even have to worry about storing your passwords/auth controls, I think passkeys is at least better for a subset of users than Magic Links.

But again, like Ricky, I don't think it should be viewed as either or. It should be both.

[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/

Thank you for the link! I saw your other comment and actually edited mine to point to that, because it's definitely the answer to my question!

> though I don't know if making your email an even stronger attack vector is necessarily one of them

I'm unconvinced that magic links do make your email an even stronger attack vector. Essentially every service that would be inclined to use magic links would already have a way to reset your password entirely once the email is compromised. All magic links do is make this the primary way to interact with the auth flow.

The bad guys already know that your email is the best target. Magic links just make that very explicit.

>The bad guys already know that your email is the best target. Magic links just make that very explicit.

That's a good point. I guess my rationale is that it being explicit makes me feel less comfortable for my parents/non tech-savvy friends, who already may not follow best-practices for email hygiene (and may not use email providers that enforce stricter hygiene like 2FA or other methods of protection) and thus, systems like this, make their email even more explicitly the ultimate place to go for access to stuff.

>feel less comfortable for my parents/non tech-savvy friends, who already may not follow best-practices for email hygiene

making people feel less comfortable is probably a good thing.

i've managed to convince my dad to start taking his email security more seriously by reminding him a few times that if somebody gets access to his email, they can reset his password on every site where he uses that email address. it's good to remind people of why email security matters, and that it's not just about the personal messages from friends.

> Essentially every service that would be inclined to use magic links would already have a way to reset your password entirely once the email is compromised

Well, don't do that.

Do you have an alternative proposal for letting users back into their accounts when they inevitably lose their passkey? Because if you don't, this isn't a serious answer.

Password, not passkey. Recovery codes should be setup on account creation, but recovery of the password manager itself is what is required, and that usually has its own recovery mechanism.

Social key recovery is an underutilized solution as well.

How do you do account recovery when you lose a password or MFA token?

Of course, any website's auth system is as weak (or strong) as their recovery process. Different sites will implement this differently.

Typically by email, which OP says "don't do".

> There are some positives about Magic Links for sure

Like what? I'm failing to come up with a single benefit (for the user).

Not needing to remember passwords or use a password manager.

Password managers are now built into every operating system / browser, with trusted encrypted sync capabilities. The UX of using the built-in password manager is better than that of a magic link.

Passkeys are in a transition period right now. There is no reason you have to have an alternative login method if you are using Passkeys, but no service has switched over to being Passkey only yet. Some users on older OSs / Linux might not be able to generate and store Passkeys yet, many users are not using a cross platform credential manager so if you've created passkeys with iCloud Passwords, there isn't a way to log in via linux right now.

Give it a few more years and I suspect we will start to see services start with creating a passkey and never collecting a password. The passkey portability specs will be implemented, and hopefully Gnome/KDE implement passkey support.

What does the final end state of passkeys look like? What happens if I lose the device I created the passkey on, if it gets bricked, or if I get banned by the platform that was supposed to be syncing my passkeys?

Passkeys are essentially an API for logging into websites that requires a password manager to use. The end state is that we become completely dependent on our password managers. To avoid a single point of failure, hopefully you own multiple password managers, and they’re on independent devices, and there is a way to sync them.

I'd think it's exactly the same as using a password manager. Yes in theory you could memorize 500 unique passwords or write them down, but no one is doing that.

There are a few things unique to passkeys though. You can register multiple passkeys for the same account so you could in theory have a physical USB key and cloud synced passkeys. Not many people would do this I would think though it would be easier than memorizing every password. There are also data portability specs in progress right now that let you export/import passkeys between services.

But at the end of the day I would suggest that it should be straight up illegal for a company to freeze your account without letting you export your data. It probably actually is by the GDPR. This problem also already exists for email too. If Google bans you, you'll find a lot of your accounts become unusable. Anything with email OTPs wont work, and some services like Discord won't allow updating your email without access to the existing one.

It can't be the same as my password manager if email password reset flows disappear. If I lose access to my password manager but not my email, then I can go through and systematically reset all of the accounts that I remember exist. What you're describing with passkeys, though, would not allow me to do that.

> But at the end of the day I would suggest that it should be straight up illegal for a company to freeze your account without letting you export your data.

This would be great but it only addresses the least likely failure mode out of the ones that I brought up.

And note that in many cases we're currently better off under the existing system if Gmail does ban you than we would be in your proposed world: only services that send OTPs on every login would be immediately inaccessibile, so you'll have time for most services to log in and switch to a new email address.

I think for most services you'd still be able to email reset your passkeys unless it's a particularly sensitive service, the kind which don't allow email resets of your 2FA tokens today.

A password/passkey reset flow is semantically equivalent to an alternative login method and if done via email is semantically equivalent to a magic link.

Which means that any service that claims to be passkey-only but supports email resets should just acknowledge that they support both magic links and passkeys as options—they're kidding themselves and their users if they pretend otherwise.

Passkeys are at least more convenient than magic links as they do not require opening an email or pulling your phone out for an SMS code. You're right though that they Passkeys + email reset is no more secure than email magic links, but I'd say email magic links are perfectly secure for most use cases. There really is no reason to continue using passwords these days and every website should switch to either magic links, Email OTP, or passkeys.

For more sensitive accounts like bank accounts and government services. You'd probably have to go through some other reset process involving real ID and possibly an in person visit to a support location.

If your passkey manager account gets frozen the clients on all your devices should still have local copies of the passkey database that you could continue to use until you have a chance to export and migrate to another passkey manager.

> hopefully Gnome/KDE implement passkey support

sigh TBH, I hope not. Maybe optionally, but for now the friction might keep companies from going passkey only, which (I think) would be a total nightmare from a security and usability perspective.

The first thing I thought when I read this is how can the author make the specific criticisms of links/otp codes and then suggest passkeys, which have pretty much the same issues x10. Like if using a OTP from your phone or copying a link from your phone when using a work PC to visit a website is a pain, how much easier/better/same is it to try and have your work computer work with your personal passkey from a laptop or something?

> how much easier/better/same is it to try and have your work computer work with your personal passkey from a laptop or something?

Passkeys support authentication via a secondary device over Bluetooth (and this is supported in every major browser on every major platform). So you can login to a site on a machine that’s completely disconnected from your personal passkey store by scanning a QR code with your personal phone.

The login flow basically goes “request login with passkey” -> “browser recognises it doesn’t have the needed passkey, and offers a QR code to scan” -> “scan QR code with phone” -> “phone and browser handshake via Bluetooth” -> “passkey handshake happens between website and phone” -> “login completes”.

I’ve personally used this flow with my work laptop and my personal iPhone many times. iOS has built in support for the Passkey QR codes, so you can scan the code with the standard camera app. Additionally iOS supports allowing 3rd party passwords managers to take over the Passkey flow once you’ve scanned the QR code. So in my case I complete the flow with 1Password.

End-to-end the flow is pretty damn seamless, I’ve never personally had it fail, and take 30seconds to complete. The most annoying part is trying to remember where my phone is.

What if the target device is a workstation or library desktop with no Bluetooth?

Then obviously you can’t use a personal passkey with it. But so what? Passkeys don’t need to address every niche scenario to be useful.

Even if we assume that you're ok with connecting discrete and disparate devices together (and you always have your personal tracking device near you all the time), Bluetooth is basically comprised of a giant bag of vulnerabilities and weaknesses.

> take 30 seconds to complete

also, ouch.

> Even if we assume that you're ok with connecting discrete and disparate devices together (and you always have your personal tracking device near you all the time)

This is a solution for the masses. If you're not comfortable with it, nobody is forcing you to use it, and it certainly doesn’t diminish the value passkeys provide over traditional passwords and OTPs for the vast majority of people.

> Bluetooth is basically comprised of a giant bag of vulnerabilities and weaknesses.

That doesn’t really matter. The whole point of passkeys is their cryptographic primitives make snooping on the handshake pointless. Everything is E2E between the passkey provider, and the site you’re authenticating against. There’s no dependency on Bluetooths security to ensure that the actual passkey handshake is secure.

> > take 30 seconds to complete

> also, ouch.

That includes the time taken to fish my phone out of my pocket.