Passkeys are just SSH keys in how they work. We've been doing this since the 90's. The only people that use SSH keys are the Linux savvy users and those who are forced to via an enterprise solution for vaulting.

The average person doesn't know anything about this stuff nor do they care. I also have yet to see a Passkey solution that didn't also have a password on it and a nice little box letting people choose to use the password instead of the passkey. They just added a new layer on top of all the old ones and created confusion. Now people use password and passkey interchangably in conversations and no one knows what they are talking about.

▲

cpburns2009 2 days ago | parent | next [-]

I can find my ssh keys in `~/.ssh`. No such place exists for passkeys.

▲

kingstnap 2 days ago | parent | next [-]

Thats because the people behind passkeys are paternalistic and don't trust users. I had an argument with one of them a few months ago.

https://github.com/keepassxreboot/keepassxc/issues/10407

https://news.ycombinator.com/item?id=47189749#47193048

My read on it all is that FIDO is stuck in some sort of groupthink. They don't feel the boots on the ground confusion around passkeys being opaque. They only care about phishing and being called "insecure" and don't care about anything else. Hence why WebAuthn has additional weird anti features like AAGUID for provider authentication.

Another one of those ridiculous threads is saying you gotta have support for nonsense like user presence verification.

https://github.com/keepassxreboot/keepassxc/issues/10406

▲

throw0101d 2 days ago | parent [-]

> Thats because the people behind passkeys are paternalistic and don't trust users.

To be fair, trusting users with passwords/credentials is how we got into the mess of phishing et al in the first place.

▲

kingstnap 2 days ago | parent [-]

The phishing resistance on fake websites is largely a function of the fact its an ssh key and you can't man in the middle those after first setup because you have known_hosts, which in the case of passkeys gets replaced with the website certificate technology.

The baking in "which authenticator is storing this passkey" and "require user to provide biometrics/pin to verify presence for this passkey" and "don't make it easy or possible to export passkeys" behaviour is more just control.

I guess it sort of helps if the threat model is complete remote code execution inside the victims brain because you got them to export their keys to you, but it seems more useful for websites and governments whitelisting what hardware and software they deem acceptable.

	▲	joshuamorton 2 days ago \| parent [-]
		> I guess it sort of helps if the threat model is complete remote code execution inside the victims brain because you got them to export their keys to you, but it seems more useful for websites and governments whitelisting what hardware and software they deem acceptable. Reminder that Facebook has warnings and prevention mechanisms to avoid users pasting malicious JavaScript into the console on Facebook.com (which would exfiltrate session cookies). Preventing users from accessing these keys directly makes sense!

▲

microflash 2 days ago | parent | prev | next [-]

It depends on the app you’re using to save passkeys. Use Keepass and it saves the passkeys into kdbx file (similar to SSH keys).

▲

cpburns2009 2 days ago | parent [-]

Aren't they effectively locked in the database of whatever password manager is used? I know you can export them, sort of, but that feature may blacklist your password manager and make it useless. Are they portable? I thought passkeys are locked to the device.

	▲	Telaneo 2 days ago \| parent \| next [-]
		> Aren't they effectively locked in the database of whatever password manager is used? Not in the case of Keepass, since you can export them. > I know you can export them, sort of, but that feature may blacklist your password manager and make it useless. Yes, and this is why passkeys are flawed. > Are they portable? I thought passkeys are locked to the device. There's nothing preventing you from syncing your passkeys and using them on different devices. This even seems to be the happy path in the locked down eco systems (You can create a passkey on an iPhone, which is then synced to iCloud, and now you can use that same passkey on a Mac).
	▲	microflash 2 days ago \| parent \| prev [-]
		I was answering to the storage part. Blacklisting is the attestation part which is definitely a concern. Again, you can use passkeys as a yet another way to login. You can still use passwords. It doesn’t have to be one or other.

▲

datakan 2 days ago | parent | prev [-]

I can pull up all my passkeys in 1Password or Bitwarden without issue.

	▲	cpburns2009 2 days ago \| parent [-]
		I thought your "with issue" typo was quite pertinent to the whole discussion lol

▲

juancn 2 days ago | parent | prev | next [-]

I would feel a lot better using SSH keys rather than passkeys. At least those are understandable.

▲

izacus 2 days ago | parent [-]

They're literally the same thing, what are you on about?

	▲	AlexandrB 2 days ago \| parent \| next [-]
		They might be the same thing cryptographically, but passkeys remove your ability to manage, move, or back them up at will. I can trivially move any single SSH key I want between my Mac, my iPhone, my PC, my Raspberry Pi, and my backup media. Can I do that with passkeys? It seems to depend on which storage mechanism I choose, and even then it's often a matter of dumping the entire password database to plaintext first. Edit: Oh yeah, I can also share SSH keys with friends and co-workers. I can freely choose which SSH key to use when authenticating and I can have an arbitrary number of SSH keys for a given server on each machine. Some of this stuff is esoteric, but some is not. Most of the stuff I can do with SSH keys I can also do with passwords but not with passkeys (or at least not always). Finally, as many others have mentioned, the attestation stuff is really ugly and takes control away from the user entirely.
	▲	pjc50 2 days ago \| parent \| prev [-]
		Apparently not: https://news.ycombinator.com/item?id=49007750

▲

account42 2 days ago | parent | prev | next [-]

SMS 2FA was also optional everywhere until it wasn't.

▲

NetMageSCW 2 days ago | parent [-]

It is still optional most places.

	▲	rustcleaner 2 days ago \| parent [-]
		Not for Chase, not for Schwab, not for my DOCSIS provider, not for my cellular provider, etc. They don't offer TOTP either, just SMS for 2FA. It's going to require a law: if you require 2FA, then TOTP or HOTP must be offered as an option.

▲

aPoCoMiLogin 2 days ago | parent | prev [-]

this is false equivalency. in poland we have similar to passkey implementation in government issued application - mobywatel [0] that allows to login to government websites. in 2022 according to published data it had almost 9m installations [1] and a lot of them are old ppl, so its not like only neckbeards would know this ancient technology

sure there are some issues sometimes (outages and others), but most of the time they work like charm and solve a lot of issues with login+password issues.

- [0] https://play.google.com/store/apps/details?id=pl.nask.mobywa...

- [1] https://dane.gov.pl/en/dataset/2919/resource/43845,mobywatel...