They solve three things:

1. You prove you have control of a key without telling the service the content of the key (like SSH keys, and any other PK setup) so: you cannot lose your password. The private part probably never leaves your device (probably - if you use Apple or Google's implementation there's magic/low security sync, you might also manually backup the private keys to a file)

2. A new keypair is generated per service. Don't reuse your password is baked in the spec, and by using individual keypairs the service can't profile you by the public key (privacy).

3. And possibly the most important. WebAuthn (of which Passkey is a popular marketing term) includes the asking identity during the registration/signup and login/proof stages, it doesn't rely on the user inspecting the url/webpage look/auth domain. Ie. You cannot be phished by examp1e.com when connecting to example.com (much like SSH's TOFU, but sorely missing from most web interactions).

It's amazing that this is the best explanation of passkey that exists on the web.

TIL about 3)! That's fantastic to hear. Password managers sort of do this already, though.

So if you're a competent password manager user, only 1) matters. Passkeys really do seem like a bigger deal to your average user, since 2) and 3) implicitly incorporate password best practices.

This seems to be the description of SSH keys capabilities except the user does not control them. Why did they not just use SSH keys? They are much more familiar, and all major bugs are already squashed for years.

The general idea behind passkeys (and WebAuthn in general) is fantastic. They're phishing resistant (not totally phishing-proof, but way better than existing auth methods). They eliminate entire categories of phishing attacks around site identity. The UX flow provides users who would not be making secure passwords with strong-by-default security, making password reuse almost impossible. Even the cross-device authentication stuff, while not sufficient on its own for things like backup is still an improvement over copying and pasting keys.

Being able to authenticate a device and log in without ever transferring your authentication credentials to that device is cool. That enables some security setups that would otherwise be very difficult to build.

Some of the benefits are oversold (the privacy benefits seem overblown, there is nothing about passkeys that guarantees that your accounts won't still require email addresses, and there's nothing about passwords that forces sites to ask for email addresses, so nothing on that front is likely to change) -- but in general, the core idea is wonderful and passkeys would be a massive improvement over passwords if they were implemented well.

The problem is the implementation and the development process for the spec.

- People reusing passwords

- Weak passwords

- Phishing

Passkeys are intended to protect the tech-incompetent masses against trivial attacks. They provide zero or negative value to the HN crowd who's already using a password manager and 2FA.

> Passkeys are intended to protect the tech-incompetent masses against trivial attacks.

I suspected as much. Thanks for saying so, maybe I'm not that out of touch yet.