Passkeys and Modern Authentication

> Signing up is uploading a public key. Signing in is cryptographically signing a commitment to the current ephemeral tunnel.

How do I sign in from multiple computers?

A service that lets you sign up by uploading a SSH public key could just as well let you upload multiple public keys in your profile to be able to connect from other devices.

There are multiple solutions to this, with tradeoffs. Doesn't change the fact that the service should only want a public key, and you should only give the service a public key. That's where this new complexity is being forced on users and developers. You need to be able to sign in, or let your users sign in, but you can choose how complicated of a key management strategy to have.

You can either have 1 key pair per service and sync them with something like 1password. Or you can have 1 key per service per device. Keys that never leave the device is usually considered more secure (and I agree for what I consider my threat model to be).

Important services like primary email, your bank, or cloud platform should probably do 1 key per device. Everything else benefits from the simplicity of 1 key per service with the keys synced.

Amazing, just like passkeys!

The sarcasm is duly noted. But I simply answered the question. I don't have any strong opinion regarding passkeys.

You are describing passkeys. All of this applies to the passkey scheme.

Actually, a benefit of passkeys is the standardization of client-side cross-device authz operations via caBLE and similar; your secret keys never leave your primary device, but are usable from other devices over a variety of transports.

> All of this applies to the passkey scheme.

It also applies to SSH keys. I never said that passkeys couldn't do everything SSH keys can do. My criticism is that they are more complicated to do the same thing.

This is exactly what not valuing simplicity looks like.

A passkey uses FIDO2, which asks you to sign a challenge. If you use OpenSSH with a security key, it will... use FIDO2. If you use OpenSSH with a private key on your computer, you also sign a challenge, right? So it's not less complicated.

WebAuthn just adds a few things like the relying party and a counter (that nobody seems to use). And the relying party helps preventing phishing, which SSH doesn't do really well in practice (most people don't use SSH certificates and don't check the server fingerprints).

So it's just not true that passkeys are more complicated to do the same thing.

Biggest difference is that SSH keys allow you to store and submit the public key without the private key being present.

With passkeys, the private key must be present and usable (at least with current implementations) at the time of enrolment.

This raises a major problem: with SSH keys you can keep an backup key in a secure location (bank vault, etc) and still be able to register it. With passkeys your backup key must be present and connected when registering it, so you can’t keep it in a secure location as you always need it when registering. This exposes both keys to risks such as hardware failure (let’s say faulty USB port that spikes anything plugged in with 12V… you connect your main key, it doesn’t work, now you connect your backup key and same thing happens… by the time you realize both your primary and backup keys are toast).

With SSH, "registering" your key on a server means having out-of-band access to copy your public key. There is no such facility if you're registering a never-before-seen user with a new key, so it makes a whole heap of sense to ensure that the credential you're registering has a working private key that exists.

Except that passkeys also add other things, like attestation, relying parties, and restrictions on how keys are synced, and so on. I don't think anyone disagrees that the basic idea of "we should be using site-specific public/private keypairs for logins" is good.