Passkeys and Modern Authentication

Unfortunately the tech community is full of people who pride themselves on being aware of and advocating for the latest standard put out by whatever company. That's how we end up with lots of complicated nonsense like most of what is sent in HTTP headers, or the contents of a TLS certificate.

On the topic of authentication, it's solved. SSH nailed it, any further complexity is strictly worse. Signing up is uploading a public key. Signing in is cryptographically signing a commitment to the current ephemeral tunnel.

Unfortunately the tech community is full of people who pride themselves on speaking for everyone and telling everyone to stop having fun with new tech because their solution is the best. And the one only truth.

All developers pass this magpie phase [1] and as you get older you start to see new things more critically.

I guess a desirable trait of seniority is to balance the urge to play with new toys vs the feeling that sometimes we are running in circles, repeating the same mistakes with different tech.

[1]: https://blog.codinghorror.com/the-magpie-developer/

ssh is terribly insecure with no way of checking server certificate fingerprint automatically. Web solved it decades ago with CA.

> Signing in is cryptographically signing a commitment to the current ephemeral tunnel.

I can see how SSH could be used for authentication on the web. And I have no doubt that it would be sound out-of-the-box. But I am not sure what you mean by your last sentence. Do you mean that authentication targets are gated and only reachable by establishing a tunnel via some kind of forwarding?

Aside from the wonderful possibilities that are offered by using port forwarding of some kind, you could also simply use OpenSSH's ForceCommand to let users authenticate via SSH and then return a short-lived token that can then be used to log into an application (or even a SSO service).

I guess no one uses SSH for authentication in this way because it is non-standard and kind of shuts out non-technical people.

This is incorrect. SSH certificates work just like x509 certificates in that regard. Also, with PubkeyAuthentication, there exist all kinds of ways to collect host keys before connecting to them for the first time and thus avoiding the trust-on-first-use problem. Especially in private networks where you control all the nodes.

> 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 simplicity of SSH's public key authentication comes with a significant privacy downside: https://www.agwa.name/blog/post/whoarethey https://words.filippo.io/whoami-updated/

This isn't such a big deal in the SSH ecosystem, but it would be a disaster on the Web where there is an enormous incentive to track users. Part of WebAuthn's complexity comes from addressing that.

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

> authentication targets are gated and only reachable by establishing a tunnel via some kind of forwarding?

No, it's just how you authenticate with signing keys. Given that a secure channel has been set up with ephemeral keys, you can sign a commitment to the channel (like the hash of the shared secret key) to prove who you are to the other party.

> let users authenticate via SSH and then return a short-lived token that can then be used to log into an application (or even a SSO service)

This is exactly what I recommend. If everyone did this, then eventually then the browsers or 1password could support it.

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.

The complexity is unwarranted. The only thing that needs standardizing is how to hand over public keys (SSH format works fine), and what to sign to prove identity.

Everything else about managing which public keys are for what does not need to be decided in a standard. The users can choose whatever key management solution works best for them. What those links get at is a problem of key management. A single set of keys, where you send all of them to every server all the time, is a bad strategy.

Not just non-technical people, but a lot of Windows developers I've worked with over the years can't seem to grasp the asymmetric key concept enough to use it for git (and then complain about git over over https).

Being in charge of the strength and security of your private key is something most people don't want to do, so we get multiple identities made "easy" by walled gardens getting popular in passkeys.

> 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.

I’ll add that eventually it’s less about what I want and more about what would work for other people I know. Many of them aren’t very technical.

What do you need to do to keep family from (a) not getting locked out and (b) not getting phished?

@alphazard, what are your thoughts on using self-signed X.509 certs, since 95% of the infrastructure is already there?

I'm opposed to using certs where public keys will do. Certificates especially X.509 are more complicated than the public keys that they reference. They include things like domain names, serial numbers, version numbers, etc.

The complexity of X.509 belongs in the domain name system. If a bunch of large corporations want to come up with complicated formats so they can decide who gets to call themselves what on the internet, let them do that, but don't let them complicate basic security for the rest of us.

The experience to beat is swapping SSH keys. 95% of developers have setup access to a new machine using SSH. That should be the default experience for authenticating on the internet, and anything more complicated should be strictly opt-in.

Yes, I agree much of the added complexity isn't necessary, but since TLS is a common and widely used protocol for just about everything other than SSH, it seems like it would be easier to plug in.

Edit: or put another way, why should I have to load another library for PKA when I already have one that works just fine?

> On the topic of authentication, it's solved. SSH nailed it, any further complexity is strictly worse.

Ever tried to SSH with a security key... through FIDO2? Or would you say that having your private key as a file on your computer is strictly better than having it in a security key? :-)

Are you trying to say that security keys are not a good thing? I love security keys, that's my one example of a good technology.

"Solved" doesn't mean anything unless you have implementation/adoption.

The thing is, if you want to use SSH with a secure element, suddenly you're using FIDO2, right? OpenSSH already supports it.

And WebAuthn is using FIDO2, it's not that different, it's just that WebAuthn adds some stuff like a relying party.

And it's just not true: ever wondered what those fingerprints are that nobody cares about and blindly goes for "yes" in SSH? The vast majority of SSH users would have no idea if they got MitM-ed.

WebAuthn helps prevent just that.

SSH does have certificates, but in practice most people using SSH don't use SSH certificates and don't check the fingerprints.

Not sure if we can say it's solved if nobody wants to use it by choice (certificates are probably mostly used in enterprise setups, but in my experience it's not even that common there).

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).

OpenSSH supports DNSSEC-published host key fingerprints.

Leaving off everything else I think about DNSSEC, this is a baffling feature. DNS solves the problem of introducing unrelated counterparties, which is not the SSH host key problem --- people generally don't SSH into hosts they're not somehow affiliated with. This is what CA-based PKIs are made for, and OpenSSH has a good (non-X.509) certificate system already; lots of people use it to get e.g. SSO login for SSH.

Tying authenticity to a global, remote set of authorities is a tradeoff we make for anonymous introductions to random web servers whenever we need them. SSH doesn't have that problem, so the tradeoff gets you... nothing?

If you have a small, stable number of hosts, an SSH PKI doesn't make a lot of sense. With a large fleet, and/or if you want to tie your fleet into an OIDC IdP, certificates are pretty common; the most common way of solving this problem, I think?

> people generally don't SSH into hosts they're not somehow affiliated with

git remote add ... git+ssh://user@github.com/... comes to mind as a counterexample, although I admit there aren't many of these examples and GitHub also supports authenticated https:// with git. GitHub don't publish SSHFP DNS records either it seems, but the feature is there in the client.

DNS for key management is nonviable due to the lack of uptake of DNSSEC. Though it's an interesting hypothetical question whether that would still have been the case without X.509.

I think it's the case in big companies. But most companies are not big :-), which means that a lot of people are using SSH without ever checking the fingerprint. That would be my intuition.

SSH has always relied on key continuity for this problem; you're exposed when you're first introduced to a host (on a particular client) but then fine from that point on.

This of course breaks down with cattle fleets where ~most logins are to hosts you've never hit before, which is why cattle fleets tend to use SSH PKI.

WebAuthn won't help you if you are signing-up on a phishing site.

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.

When I connect to github using ssh, I must google github page with ssh fingerprint and verify it by hand. Imagine how many people actually do that, instead of blindly accepting the key.

If github can't make it right, nobody can.

Over the years I have seen - repeatedly - colleagues just removing ~/.ssh/known_hosts when SSH showed the warning that says something like "YOU MAY HAVE BEEN HACKED!!!".

I think passkeys resolve that, even though it's more of a human issue than a technical issue :-).

Well if you sign up on a phishing site, they won't be able to access the legit site with your credentials...

Use a different public key for every site, specify which one in your .ssh/config. Only offer keys for the site(s) they correspond to. Done. This is already best practice, but could easily be improved by simple tools to manage it. You do not also need things like attestation and restriction of backups.

It's the stuff it adds that most people object to.

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.

Niеther an ssh MITM can use your private key on a legit server. A middleman doesn't need it in most cases, however. My point was that the situation with ssh is basically the same as with webauthn.

> Niеther an ssh MITM can use your private key on a legit server

Of course they can: that's precisely the meaning of MITM.

They don't get direct access to your private key (because they wouldn't need to stay in the middle anymore at that point), but they will ask you to sign the challenge sent by the legit server, which you will happily do if you don't realise that you are not talking to the legit server.

WebAuthn prevents that MitM part.

It feels more like people object for the sake of objecting. I often have this feeling: people first don't care (about security, about renewable energy, ...), and the moment they start caring, there is a high risk that they will just object to everything, sometimes without good reasons.

Sure, we are being abused by TooBigTech and surveillance capitalism. It doesn't mean that all security is bad. Security is a compromise. Yet many people go "this added security comes from a governement/TooBigTech so it proves that it is a lie". Which is wrong: it doesn't prove it. Sometimes there are good things coming from governments/TooBigTech.

The world is more nuanced than people seem to realise.

I use this very setup, it works great. Yubikey has supported resident keys for a while.

I guess you're saying that a challenge is tightly packed with a server ID and processed by the webauthn client lib, so a middleman cannot separate and forward the same challenge from its own server. I don't know the exact details of the ssh protocol, but I see no reason why ssh can't do the same.

If we are simply talking about ssh users ignoring fingerprint warnings then I don't see how this is an ssh weakness. A fingerprint change warning is basically saying "you're connecting to a phishing site" as I see it.

> If we are simply talking about ssh users ignoring fingerprint warnings then I don't see how this is an ssh weakness.

I didn't say it was an SSH weakness. I said that it was not "solved" problem in that most users I have seen completely ignore those warnings from SSH. So the problem persists even though SSH does it right.

With WebAuthn, the problem disappears. So that's an improvement for the users.

Don't get me wrong: I love SSH. I just think it's wrong to say that WebAuthn doesn't bring any kind of security to users.