Comment by bonzog

It's ironic that passkeys are most usable in conjunction with a password manager that syncs them across all of a user's devices, but this is also the scenario where they have the least security benefit over traditional passwords.

I do appreciate that passkey adoption has led to wider support for hardware security tokens for sites where I actually care about increased security over password managers, however.

> no one can attest with certainty that I won’t wake up in a painful situation because I decided to adopt passkeys

Seems that way. Better luck next year, passkey standards(?) people. Hope it’ll be ironed out at some point.

From my experience, passkeys work great in the Apple ecosystem. Adding a passkey for a new site on my Mac results in that passkey syncing automatically on my iPhone and iPad via iCloud.

"But what if I lose all of my Apple devices in a freak boating accident?" people often ask or something like it. Apple has a procedure for this [1].

You can contact your "recovery contact" (a trusted friend or family member) that can help authenticate you to regain access to your account, especially if you're locked out or forgot your password.

On a new device, you login to your Apple account, make sure iCloud Keychain is enabled, and all of your credentials, including your passkeys, sync to your device.

I get it—not everyone wants or uses iCloud. Apparently, you can use 3rd party password managers like 1Password, Bitwarden, etc. to backup and recover your passkeys to use elsewhere.

Here's a video of an export from 1Password to the Passwords app on an iPhone [2].

[1]: https://support.apple.com/guide/iphone/passwords-devices-iph...

[2]: https://youtube.com/shorts/gJ8BzT73JzY?si=zSY8vp_v297IfCro

This sounds like an iOS problem. Bitwarden + Firefox on Linux, or Bitwarden + Android, has never been anything but smooth for me when it comes to saving or using Passkeys.

I’ve never seen an implementation where passkeys deleted my password or could lead to a situation where it was locked out. They usually just bypass the password+2fa dance when functioning, and otherwise just don’t matter if they don’t function. (Well perhaps except home depot, where it gets mad at me every time I use a password and tries to install a new copy of the same broken passkey as last time, for my convience)

On XMoney I can't access the app on my desktop because it forced me to use an iOS device to set up the account, and I guess, but don't remember it mentioning, that it created a passkey on there. There is no alternate way to log in. You're just permanently locked out. I spoke to the devs, they say that's intentional.

LastPass has a tutorial video that shows you how to only use them for autofill: https://www.lastpass.com/features/autofill/iphone

Other password managers do, too: https://bitwarden.com/help/auto-fill-ios/#keyboard-autofill

> figuring out how to get the flow to set up a LastPass key by default seems unusually difficult

Disable iOS passwords and set lastpass as your only password autofill source. It’s far from difficult. In settings under autofill passwords

That sounds terrible. Passkeys work great for me with bitwarden.

[flagged]

> Yep, any time you're asked to set up a passkey it feels like Russian Roulette with future access to that account.

We rolled out passkeys a couple of years ago (I work for an auth/CIAM provider). This was before most passkeys were synced (which gives me the heebie jeebies--that's a valuable set of private keys to be shipping around).

We built passkeys to be an alternate login method, not a primary one, for that exact reason.

> Supporting multiple passkeys should be a minimum requirement for every Passkey implementation.

To go a step further, "multiple minimum" should be like... 5+. Enough to cover several devices (Laptop, Phone, Desktop) then at least one for backup/disaster-recovery purposes, and some wiggle-room for when replacing an old device with a new one.

Passkey-over-Ethernet-over-USB C!

[dead]

This is a fantastic explanation and analogy. Thank you!

I will poke at this a bit:

> As for getting locked out of your account, losing your passkey would be the same as losing a password. You would need to follow the site’s password reset flow, and if you can recover from a lost password, you can recover from a lost passkey.

Do you think this is one of those scenarios that sounds reasonable at first, but can get torn apart by unknowns, edge cases etc? To use an analogy from a recent HN thread that is stretched a bit, is this like saying "If you use a crypto hardware wallet, you're safe", then reading about compromised hardware wallets due to something outside the assumption set.

If you own only one device—a mobile phone, like the majority of people in the world—and you lose it, how do you get back into your passkey-protected email account?

That is my understanding as well but I like to point out: The private ssh key lives on the hardware it was created on. It never leaves the system. Even root cannot "copy paste" that sucker around and chuck it into a password manager app or even "better" on a cloud service so you can use it on any device you log into.

I liked the idea that passkeys work the same way but now for logging into services like amazon or google etc.

Imagine my face when I learned that that so many interpretations of passkeys exist that actually create that private part in a passwordmanager or chuck it into iCloud or equivalents.

I wondered if the inventor of the private/public keyexchange still lives or if he would spin in his grave hearing what happened...

I would have been on board if the passkeys only existed on your hardware period. I would have accepted that I would need to set up access from devices of my choosing and therefore cannot log into these services from any old "cyber cafe" on a whim.

But I would, as an emergency BCM measure, expect a sort of breakglass phrase that I could obtain and keep safe like at a bank deposit box or similar in case all hardware with keys to said service would die at the same time.

I understand though, that for most all this would look like way to inconvenient and using the cloud instead is so much more convenient which is why they decided to hollow out the concept of the passkey.

What’s PQ story with passkeys? Considering all the hype that everything needs to be pq safe by 2029 (or whatever), wouldn’t it make sense to delay adoption? Otherwise a db leak would compromise every single account in a pq world.

You don’t have to use a password manager that relies on an account. Personally I use Strongbox on iOS and macOS, which stores everything (including passkeys) in a .kdbx file. I then sync the .kdbx file over iCloud, but if I lost access to iCloud then there would still be copies of the file on all my devices. Overall this is not as secure as the more centralized alternatives, but it does leave me in control.

Great news! If you use a cloud-sync password manager, passkeys are way more convenient than TOTP.

Because password managers allow you to use a password and 2fa even if the url doesn't match. And sites often legitimately change domain or have multiple domains which trains users that sometimes it doesn't work and you have to override the automatic matching.

Passkeys physically don't allow you to send them to the wrong sites so the sites have to make sure they keep working.

"Weird, my password manager isn't submitting my password properly. Well, that happens sometimes. I'll just copy and paste it" [or manually select a password to autofill]

If the password database of the website is hacked the attacker knows your password for that very website. With passkeys he knows your public key.

The overwhelming evidence is that this isn't true for the majority of users.

[dead]

>They have to be transmitted.

Everyone knows to hash passwords now and browsers basically enforce SSL. This is not a practical differentiator.

>Passkeys can’t be entered on the wrong site, the sites they work on is an inherent property of the key.

They are still susceptible to malicious enrollment. If a user is convinced a fake site is real, to the point that they are opening their password manager to copy the password to it, you should assume they will do the equivalent with a passkey (re-enroll attacker's key or register attacker's passkey).

>If your entire database is stolen, it’s useless.

As are databases containing strong randomly generated password hashes. What is your threat model here, they somehow forgot to hash their passwords yet they are still hashing session tokens, storing customer data in completely separate databases, safely storing private keys, etc.? It requires quite the strawman scenario to apply.

You're arguing theory and not practice. In theory they're better of course. The problem is the implementation. And implementation is a mess because everyone is trying to lock you into their own little ecosystem.

> There is nothing to prevent you from entering your super secure u quiet password on the wrong site if you get phished.

You replied to someone talking about password managers, which objectively do exactly that.

> Unique strong passwords, TOTP, 2FA, one time sign in emails, none of those offer this stuff.

And Passkeys don't offer portability, user choice, or user control.

Cryptography may be a solution, passkeys are one technical implementation that at is core is designed around smartphone-first, vendor-first, brand-loyality-first thinking.

You lose a device or the local DB that keeps your passkey and you are screwed.

You need to migrate from one login domain to another (rebranding, change of login providers...) and none of your customer credentials will carry over.

Your password might not be stored anywhere except in your head.

Your local storage gets compromised and your passkeys are there for the taking (password in your head isn't).

"Cloud" password managers who hold your passkey private key part is exactly like them having your password and are worse than websites having proper cryptographic hash of your password: they might not be e2e encrypting it (you were comparing with sites doing password hashing wrong too), so a breach exposes all your passkeys just the same.

My point is that there is no panacea. Passkeys are like SSH keys for the web. I still put a passphrase on my SSH keys. Do you?

Passkeys can be, and have been, stolen and hijacked. They make it more difficult for scammers and hackers to get into your accounts, but not impossible. How many phishing emails have you personally fallen for that this is your #1 concern over the fragility and complexity of passkeys?

Nothing of this explains anything, at best it increases the confusion. If anything, all this mumbo jumbo pushes me further away from using passkeys than before.

> There is nothing to prevent you from entering your super secure u quiet password on the wrong site if you get phished.

Replying only to this part, using a password manager with autofill solves this problem. The password manager (I use Bitwarden, but there are others) can check the site you're trying to log in to, and only autofill passwords that are for that site. I don't have to do any work to differentiate example.com from thisisexample.com, because Bitwarden will only show me the example.com password.

> They have to be transmitted.

What do you image happens with passkeys?

> They (or their hash) have to be stored.

What do you image happens with passkeys?

> If your entire database is stolen, it’s useless. No one else can login with your credentials because they don’t have the private key.

From the consumer, do you imagine a hacker has my key to unlock my password database?

From a service provider, do you imagine they are not using encryption at rest?

> Cryptography is the solution in passkeys are the implementation.

Do you imagine cryptography is not used with passwords?

> Bull. People need to stop repeating this.

Wow, you sound like you know what you're talking about.

> They have to be transmitted. They (or their hash) have to be stored. And so so many get that wrong.

Ok, you've stopped sounding like you know what you're talking about.

Passwords have to be transmitted or stored. They don't have to be transmitted and stored. As you note, we usually opt for transmission but not storage. You could do it the other way around.

> There is nothing to prevent you from entering your super secure unique password on the wrong site if you get phished.

> Passkeys can’t be entered on the wrong site, the sites they work on is an inherent property of the key.

They can still be entered. Not working isn't the same thing as not being sent. A cryptographic exchange should hopefully fail before anyone who's pretending to be the counterparty you want learns enough to impersonate you. But you can enter anything anywhere.

> Unique strong passwords, TOTP, 2FA, one time sign in emails, none of those offer this stuff.

Unique strong passwords offer the following:

1(a). They are never transmitted (well, once), and provide phishing resistance; or

1(b). They are never stored, and provide leak resistance.

2. In the event of compromise, no other credentials of yours are simultaneously compromised.

It's true that it would be nice to enjoy phishing resistance and leak resistance.

Here are some other things unique strong passwords offer:

3. You are free to establish any relationship you like, with anyone you like. You don't need permission from Yubico to create an account somewhere.

4. Yubico can't pretend to be you.

You might notice that passkeys don't offer any of those. Your comment appears to enthusiastically endorse the idea that passkeys are a trap.

> Passwords are fundamentally broken. They cannot be fixed.

This is the "PGP is fundamentally broken" argument again. It will never be valid.

If you ask any followup questions, the reason that "PGP is fundamentally broken" is that people use Outlook plugins, and those plugins mean that they're constantly sending email in plaintext when they should have sent it encrypted. There's a very, very simple solution to this.

Don't use Outlook plugins. Run PGP yourself.

Before you send your email, check whether it looks more like "OK, everyone's ready for the kidnapping on Thursday" or "Eb+h+Q1iDEYUgJlO5GTtmcibC+D1E9oJWvZeoy9I2tpqxe9j/iokAx0R". You will be able to tell the difference. Nobody has ever failed at telling these apart.

If you were about to send the email, but it's still in plaintext, don't send it.

Passwords are no more fundamentally broken than PGP is.

What are you talking about? Whenever I've written authentication, passwords are hashed on the client side and never transmitted in the clear.

The way passkeys are being pushed is so clearly an attempt to add friction to leaving walled gardens. Stop talking in absolutes in a world of greys.

Phishing is even easier. Instead of "open your password manager, copy your password and paste it here" it becomes "your passkey is out of date, click here to enroll a new passkey. As part of this process a reset link will be sent to your email and code to your phone. Do not share the code with anyone."

The less sophisticated users can use their passkeys then, and the rest of us who know what we’re doing and have been for 25 years can continue to not support vendor and platform lock-in and forced device attestation. The amount of marketing and push behind passkeys does not feel entirely genuine to me.

Same with password managers inside web browsers: they'll only present the filled-in password for the original domain, not a phishing domain.

Keepassxc and strongbox passkey integrations seem pretty good on all of the OSes and browsers I've used.

I think passkeys make a messy credential situation even messier, but make a tidy credential situation even tidier.

On iOS devices you can import/export Passkeys between supporting password manager apps (including Apple Passwords).

In my experience, migrating between Apple Passwords and Bitwarden worked without issues, in both directions.

If that's the argument, it's bull. If you use Apple hardware, you're not locked in and required to use Apple's default Passwords manager.

Microsoft Authenticator, Bitwarden, 1Password, etc. all support storing passkeys and support multiple hardware platforms.

It's no different than making your own decision on which password manager you want to use.

brother I locked myself in long before the passkey showed up

[dead]

The fact that the password manager someone might use on another system is a complete piece of crap does not mean passkeys are an Apple lock-in attempt.

There are an open standard. You just have terrible software.

I think Firefox had system integration with the password/passkey provider framework since 122.

If you do not have access to your personal Apple account on your work laptop, you would need to find some other passkey provider with native integration.

Under Settings > Privacy and Security, look to see that Firefox is listed and has access under "Passkeys access for Web Browsers". Unlike a native app which only needs passkeys for its own services, Firefox needs access for every potential service you might hit over the internet.

Then under General -> Autofill and Passwords, you'll see any apps which are registered as system password managers. Unfortunately this is a subset of the ones which register on iOS and I'm not familiar who has done integration yet in their Mac release - Chrome (with GPM) for instance is not listed even though it is available on iOS.

Same here. My only nitpick is that I have to carefully go through the various machines and browsers, etc, and ensure that only 1Password is ever consulted for password storage.

This describes most non-techy people I know who are 20~ years older than me (unless they're 40+ years older than me and only using a laptop to check their email).

Step away from HN, and there are probably a lot of people who only use their phone to access the Internet. Smartphone brand loyalty seems to be strong, too.

> But you can’t simply switch to Android without recreating every single passkey. Sounds like vendor lock-in to me

Not so fast. Migrating passkeys from iOS to Android is possible now; migrating from Android to iOS is still being worked on.

Ricky Mondello's team at Apple created the Passwords app which brought passkeys to iOS, macOS, etc.

The entire presentation is worth watching if you’re interested in passkeys; the the clip below starts at 24:00 mark where they talk about migrating between platforms.

    Starting with iOS 26.5, you can choose to move passkeys and passwords
    from Apple Passwords to Google Password Manager. However, Android still
    needed "a future update" to receive them. That same update is meant to
    add transfers from Android back to iPhone [1].

The FIDO Alliance created a specification in 2024 called Credential Exchange Format [2] for moving credentials including passkeys, between passkey managers on the same device and across platforms.

In other words, being able to move passkeys between devices and platforms has always been part of the plan.

[1]: https://youtu.be/yVadD-Lfrfk?t=1454

[2]: https://fidoalliance.org/specs/cx/cxf-v1.0-ps-errata-2026030...

Well designed platforms and auth frameworks allow adding multiple passkeys. The problem is this requirement was never coded into the passkey standard.

Yes you can. You can export your passkeys and then import them into whatever android password manager, or 1Password.

You can back up the TOTP secrets to add another layer of protection. I haven't needed to restore from backup yet, but I'm pretty confident that failure mode won't be a problem outside the immediate timeframe my phone happens to die.

If you lose your domain, you have bigger problems than just passkeys. If you just used passwords, users would still have to somehow locate your new site and trust it with the password previously associated with your old site. Password managers won't input passwords from one domain onto a new domain.

As someone else said, you'd have to do an email blast and hope users trust the email blast as authentic to trust your new domain, and just someone phishing.

Loss of a domain is so catastrophic for trust that passkeys don't make it much worse.

Allow email resets in the case of a lost domain. You could disable them in normal operation but in this case, any users with passkeys from the old domain can enroll a new one via email.

Except that in almost all implementations passkeys can't be extracted or copied, unlike ssh keys. Great for enterprise, terrible for home use.

You only do it if you want to. You can put your passkey in keepassxc or 1password or bitwarden or google's password vault or any other cross-platform passkey platform.

It's only a problem if you pick a platform that locks you out, even then there's workarounds. It's not a replacement for logging in every day, it's more a replacement for typing over the 64 character random password from your phone's password manager on the library computer.

In theory, I guess, but dragging a desktop to my laptop to log in is a bit much. We need a better solution for that.

The CTAP2 protocol has better alternatives, https://github.com/fmeum/WearAuthn is possible because we already can do better. I just hope it'll be implemented at some point (though, realistically, the future is phone-first, despite how much I dislike the implications that carries).

A few examples here to illustrate... The way ebay and Amazon handle this are great. Multiple passkeys allow login of multiple device ecosystems and/or hardware tokens so that users can mange their own level of risk and really any level of implementation is helps the average person.

Meta's implementation by contrast is bad, in my opinion. You are only allowed one passkey (so one login ecosystem/hardware key allowed) and it completely bypasses 2fa and security tokens. So, someone looking for more security must avoid passkeys "altogeher" and use password + U2f security key and the passkey only being allowed in a single ecosystem means that password/phishing lanes must remain open. All you're doing is disabling 2fa on a key that is likely sync'd to all of your devices. All that said...it may still be a security improvement for most users in the real world in practice, I just find it a very annoying and confusing set of security decisions.

The primary reason 2FA exists is because passwords are phishable. If you remove passwords, the need for 2FA largely disappears.

Obviously any new feature in a password manager is a new attack surface. That doesn't mean we should never add new features to password managers.

If we don't add decent sharing to passkeys then people will continue to use passwords, which is worse for security than adding a properly designed sharing feature for passkeys.

Outside of a corporate Microsoft Entra login policy, I'm not aware of Bitwarden passkeys being widely denied in practice.

Maybe, but ultimately a website/service wants active users, and making it too hard to log in from different platforms or reset your auth and get back in is not going to get them more users or better user retention.

> The obvious way to satisfy people is to remove support for remote attestation from the spec.

If you presume bad faith on the part of basically the entire WebAuthn implementer community, how does this help?

The consumer passkey authenticator implementations of today do not provide attestations, passkey relying parties do not consume them, and both would need to intentionally ship changes to enact the scenario you're worried about. If you're worried about both of these colluding to lock you out of your accounts, it seems naive to think that changes to an (intentionally malleable, extensible) spec will protect you.

All the rest of this argument just misses me. Whatever the non-phishable authentication you want to use is, that's fine by me. But TOTP is phishable, eminently so, so you're not going to see security people back down from deprecating it.

Most people don't have time for the level of complexity of a password manager in general and just use one hunter3 level password for everything.