alt Hacker News> Seems like vendor lock-in was the goal from the start.
Exactly. The passkey vendors state that the goal was to make phishing not just difficult but impossible. This means plaintext access to your credentials is forbidden forever, regardless of your level of expertise, and regardless of the complexity of the process to export/import them. The purpose of the so-called "secure credential exchange" is once again to prevent you from directly accessing your credentials. You can go from one passkey vendor to another, but you're always locked in to one passkey vendor or another.
Any credential system that makes it impossible to write something down on a piece of paper, take it to a new computer, and login to a website is just a gateway to vendor lock-in. You can manually manage your own ssh keys but for some reason not your passkeys.
As an Apple Mac user, what annoys me the most is that the use of passkeys in Safari requires iCloud Keychain, which of course requires iCloud and an Apple Account. [EDIT: Obviously I'm talking about built-in support. I'm well aware of third-party software, so everyone can stop replying to this now, please!] You can't do local-only passkeys, not even if you take responsibility for backing up your own Mac.
The passkey vendors took some good theoretical ideas, such as site-specific credentials and public-key cryptography, and totally mangled the implementation, making it hostile to everyone except themselves.
Replies
> passkeys in Safari requires iCloud Keychain
This is not true - browsers including Safari support passkeys managed by third-party password managers.
I'm using 1Password with browser extensions for Safari and Chrome on macOS and iOS and it works seamlessly with my passkeys, which are not stored in iCloud Keychain.
> you're always locked in to one passkey vendor or another.
This will change: https://1password.com/blog/fido-alliance-import-export-passk...
> The passkey vendors state that the goal was to make phishing not just difficult but impossible. This means plaintext access to your credentials is forbidden forever, regardless of your level of expertise, and regardless of the complexity of the process to export/import them.
Care to cite this statement?
> As an Apple Mac user, what annoys me the most is that the use of passkeys in Safari requires iCloud Keychain, which of course requires iCloud and an Apple Account. You can't do local-only passkeys, not even if you take responsibility for backing up your own Mac.
You can use any credential manager you choose. You don't have to use Apple Passwords / iCloud Keychain.
It's an open protocol, you don't need to use any of the vendors. My Yubikey is a "passkey", so is my Flipper Zero. Keepass provides passkey support.
For the general public, they already rely on either Google or Apple for pretty much all of their digital life. Nothing wrong with extending this to passkeys, it's convenient and makes sense for them.
> The purpose of the so-called "secure credential exchange" is once again to prevent you from directly accessing your credentials.
I’ll accept that the attestation parts of the protocol may have had some ulterior motives (though I’m skeptical), but not having to reveal your credential to the verifying party is the entire benefit of passkeys and hugely important to stop phishing. I think it’s disingenuous to argue that this is somehow unnecessary.
> what annoys me the most is that the use of passkeys in Safari requires iCloud Keychain
Completely untrue, Safari on both Mac and iOS supports third-party password managers for both traditional passwords and passkeys.
This is obviously kicking the can down the road, but I "solve" this problem by storing passkeys in a third-party credential manager that supports them. That way I can use them on any device that I've installed the client app or browser extension on. I have this working on Fedora, macOS, Windows, and iOS.
But again, kicking the can down the road.