Hacker News Reader

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.

The threat models here are often very similar to existing Password Manager threat models. If an attacker gets access to your Password Manager they get access to every password you have stored there and can do what they like with that information. The same applies to your Passkey Manager, which in many cases (including for your own peace of mind) is/should be the same app/vault as your Password Manager for other types of passwords.

A lot of the same Password Manager requirements and best practices apply to Passkey Management such as using strong master passwords or biometric unlocks or device PINs. Using Password Managers that support device bound hardware security enclaves, etc.

But even more so than average Password Management, because Passkeys are public key infrastructure the benefits you get out of the box exceed those of ordinary passwords. One of the factors in most Passkey implementations here is that sites (defined by hostname) all get different public keys. (Users are suggested to use different passwords for every site, but are not required to. Passkeys do that technically and are generally enforced in that effort by browsers and Operating Systems.) Leaking those public keys is no longer an issue (they truly are public keys), and leaked public keys aren't generally useful to other sites and apps. (Passwords that leak and even sometimes salted and hashed passwords that leak are liabilities and can be useful for rainbow table attacks or social engineering attacks or password reuse attacks.)

There are certainly edge cases to Passkey Management but in general the threat models follow Password Management threats: does someone have physical access to your device? Do they have access to your biometrics or device PINs?

But also the blast radius is reduced compared to usual Password Management threats: a single leaked private key generally only impacts a single website/app. Being able to sign a Passkey challenge once doesn't mean unlimited access (a password can be used forever after finding it), because challenges have timestamps and random entropy and generally don't support replay at all.

Passkeys also open up other use cases like using a mobile device or hardware security token to log into sites from public computers, which, while not risk-free (targeted malware could still hijack your session while you're logged in), is still significantly safer than giving the public computer a password.

This is roughly analogous to the difference between swiped/card not present and chip/NFC credit card payments. While a hacked chip/NFC credit card terminal could display a different amount than actually charged, it can't subsequently make additional charges after the card or device is withdrawn.

Though obnoxiously, the public computer login method doesn’t rely solely on the QR code it shows, but also uses Bluetooth. So if you want to log in on a VM or computer without Bluetooth, or a physically distant computer being accessed remotely, you have no choice but to install your password manager on that computer. Which is a lot less secure than copying a single password and one-time code.

VMs and remote access can implement passthrough for passkeys, just as passthrough has been implemented for smart cards (CCID).

I am less interested in the threat models than the accidental denial of service models. I've avoided passkeys because of that. It seems like there are real problems if you use multiple devices not somehow symced.

I have started using Passkeys everywhere that I can. One of my "requirements" is "do they support multiple key enrollment". Most do, it's sort of required by the spec and semi-required in practice by the giant number of consumers in the US with iOS or Android phones and Windows PCs. The open source libraries certainly push you in the direction of implementing it properly multi-key per user. (I've also implemented Passkey-Only website login.)

I generally add keys from two very different Password Managers to every site/app I use Passkeys with. Both Password Managers also sync between multiple devices I own.

Redundancy is already an option. Choice in Password Managers to use for your Passkeys is an option.

I understand that accidental denial of service fear, but the tools exist technically to deal with that fear if you wanted to try to deal with it.

The risks from using passkeys are a subset of the risks from using passwords. There aren’t zero risks, just fewer than for passwords.

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?

Backup codes, sms backup, trusted user backup. Most of these are quite insecure but better than loosing access to your digital life.

Most Passkey implementations by default are syncable/copyable/backupable. The iOS default is iCloud Password Manager and keys get backed up to iCloud and restored on device restore when replacing a phone (just like the rest of the users passwords they choose to store). Android has similar defaults with the Chrome Password Manager.

How would you get back into your email account if you lost your password or password manager? It is the exact same situation.

This is site-specific, but typically by using the same mechanisms used to reset forgotten passwords.

Also, sites can and often do support multiple passkeys, which opens up the possibility of allowing for reliable account recovery using one or more backup devices (one or more YubiKeys, for instance) that is still siginificantly more secure than reset flows using SMS or email.

I think the point is I can make a physical copy of my backup email and password. How do I print a passkey for safekeeping?

In other words, my email can be signed in from anywhere on purpose. It's a feature. The chances of me forgetting my password is zero, because I can back it up 7 way to Sunday.

A passkey seems to miss these basic accessibility issues. For a random website, that's fine, but for the service all of websites use to auth me, access is more important than locking it down to one device.

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.

Most Passkeys use PQ PKI algorithms. From statistics I've seen most are Elliptic Curve on currently recommended PQ curves.

For better and worse, Webauthn is one of the "choose your own adventure" PKI systems where the keys themselves suggest which PKI algorithm/details they use. This is partly because Webauthn has been around a long time and has had to backwards compatibly support a wide variety of physical security keys over the ages.

Most good open source libraries for implementing passkeys will do a good job of limiting passkeys to known good algorithm choices, including any PQ requirements/suggestions. The Passkey standard itself also sets a "higher water" baseline above Webauthn's supported algorithm list.

I don’t follow? What is a “currently recommended PQ curve”? As far as I understand, the entire point is that all ECC is broken by quantum computers, hence the hype to move to something else by 2029. Anyone that can see your public key can compute your private key.

My understanding is that some of the curves are still considered high enough entropy that the number of qubits needed is "unreasonable". The important point remains though that passkeys don't have a fixed encryption suite and can be updated over time.

Passkeys aren’t permanent, you can change or revoke them. If the algorithm used suddenly becomes vulnerable, you would need to rotate all your passkeys.

Sure. You’re assuming every site will revoke your passkey when that happens though. It also feels like a great time to trick people into registering an attacker passkey instead.

You would revoke it yourself, I am saying.

Also, the same risk applies, but to an even greater degree, with a password.

No, it absolutely doesn’t apply the same way to password. In a PQ world anyone that has your public key also has your private key. That’s not the case with a password and stolen hash.

In a PQ world if they have the stolen hash, they have the password. How is that different than the passkey world?

What? No? That’s not how hashing works. Thank you for confirming that you have no idea what you’re talking about.

Yeah, you are right. I don't know what I was thinking when I said that.

Little harsh to say I have NO idea what I am talking about, though.

I still don't agree that companies won't revoke their passkeys if we are in a PQ world.

If they don't, you are still in a better place than passwords. Each public/private key pair is unique for every domain, so a compromise in one place is not a compromise in others. Many people re-use passwords (even if you don't).

Authentication is safer than encryption, because harvest-now-decrypt-later is not available. Currently PQ is not standardized for passkeys, and at least Firefox fails if the authenticator advertises unknown algorithms.