>The major difference between passkeys and ssh keys is how they are managed. You can, and should as good practice, generate separate ssh keys for each ssh service that you use, just as you should generate separate random passwords for each web service that you use.
The two cases seen entirely different to me. I think that in most cases a single SSH keypair is fine. Some discussion of the question here:
>On the other hand, passkeys are always associated with a single web service, never with multiple services, so that's an improvement in security over ssh keys and passwords.
Is it? I suppose that would be true if you didn't want the various services you use to know you were the same entity. That's more of an anonymity issue.
Then why does the passkey scheme even bother with public key cryptography? Why not just generate random passwords for each site and store those? This seems to be logically equivalent to a password manager.
> Then why does the passkey scheme even bother with public key cryptography? Why not just generate random passwords for each site and store those? This seems to be logically equivalent to a password manager.
The big reason is phishing. If I can convince you that my site is the login page for something else, I can login as you – and if I’m clever, get you logged in as well or present some temporary error page before redirecting you to the real login page so you don’t even realize I’ve done that. Weaker forms of MFA like TOTP, SMS, app push notifications, etc. are vulnerable to that since you’re expecting a prompt. Because WebAuthn uses the hostname in the setup process, there’s no way to phish someone and keeping the private key locked down also prevents someone from even trying from another device.
TLS prevents me from, say, tampering with your network traffic and pretending to be Google.com if I control the network you’re on. That’s a hard attack - not unprecedented, especially for hostile governments or unethical ISPs but uncommon for most people.
FIDO2/WebAuthn prevent the more common phishing attack where I register a different host name, get a valid HTTPS certificate, etc. for a different hostname like gooogle.com and try to convince you to enter your real Google password there. These attacks are relatively easy to run since they don’t require any successful compromises to launch and things like URL shorteners and link trackers, not to mention corporate rebranding and outsourced marketing, have trained most people to see weird links as normal.
Here’s a sample flow for that:
1. I setup gooogle.com and make it look like a real Google login page.
2. I send you a link, perhaps obscured, which takes you to my fake login page.
3. When you enter your password, my code starts a real Google login session.
4. When you’re prompted for TOTP or SMS MFA, my code submits those values to Google and now I have a valid session.
5. My code returns some kind of temporary error and sends you to the real login page. 99% of users are used to stuff breaking every so often and since your second login attempt will work just fine, almost nobody questions this.
There are various things you can do to make those attacks harder such as MFA systems warning users about where the logins are geolocated but those are unreliable and attackers can often foil them by e.g. using a botnet node or compromised cloud server in the same region. The WebAuthn protocol makes this attack completely impossible so it’s not just faster and easier but absolutely more secure.
There are two things being authenticated here. The server and the user. Passkeys authenticates the user. So there is nothing passkeys can do to prevent phishing of the type described which involves improper authentication of the server.
That’s not quite right. WebAuthn completely prevent cases where the user fails to authenticate the server, which is an extremely common attack. It does not protect against a compromise of the web PKI system, which is a rare and catastrophic scenario which no other alternative protects against but they do mitigate the damage somewhat in that using a public key rather than a shared secret prevents reuse and implementations are required to confirm user intention so I can’t spam logins to other sites or faster than you’re willing to tap a button.
What does any of this have to do with my contention that public key signatures are not really needed in the case where every connection has its own key pair? I think we are talking about two different things here.
That's the intent of password managers, but there are all sorts of attacks/bugs/footguns that could still let the wrong thing happen. You could imagine scenarios where you don't have time to investigate why your @#$(#! password manager isn't autofilling today, and you do it manually. The confused deputy problem is real. Contrast FIDO's design, in which it's actually not catastrophic to give the secret to the phishing site, because they can't do anything useful with it. There simply isn't a "hunter2" for them to obtain, even if the confused deputy wanted to give them one.
The problem is that sites are sloppy about this and many password managers allow you to fill in passwords even from other domains. WebAuthn makes that impossible even in the face of good social engineering.
The two cases seen entirely different to me. I think that in most cases a single SSH keypair is fine. Some discussion of the question here:
* https://security.stackexchange.com/questions/40050/best-prac...
>On the other hand, passkeys are always associated with a single web service, never with multiple services, so that's an improvement in security over ssh keys and passwords.
Is it? I suppose that would be true if you didn't want the various services you use to know you were the same entity. That's more of an anonymity issue.
Then why does the passkey scheme even bother with public key cryptography? Why not just generate random passwords for each site and store those? This seems to be logically equivalent to a password manager.