7 ms·

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

>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: * https://security.stackexchange.com/questions/40050/best-practice-separate-ssh-key-per-host-and-user-vs-one-ssh-key-for-all-hos 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.

sowbug 3y ago
Why not just generate random passwords for each site and store those? That approach is susceptible to a man-in-the-middle attack. FIDO isn't.
- supriyo-biswas 3y ago
  If you’re using a password manager, it would fill in the password only for the target website.
  - acdha 3y ago
    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.
  - sowbug 3y ago
    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. (If you believe you personally are impervious to social engineering, imagine how many other people would respond in this situation: https://www.mercurynews.com/2023/04/27/larry-magid-how-i-nearly-fell-for-a-frightening-virtual-kidnapping-scam/ https://www.mercurynews.com/2023/04/27/larry-magid-how-i-nea....)
acdha 3y ago
> 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.
- upofadown 3y ago
  >If I can convince you that my site is the login page for something else... Wouldn't TLS prevent that?
  - acdha 3y ago
    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.

sowbug 3y ago

Why not just generate random passwords for each site and store those? That approach is susceptible to a man-in-the-middle attack. FIDO isn't.

supriyo-biswas 3y ago
If you’re using a password manager, it would fill in the password only for the target website.
- acdha 3y ago
  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.
- sowbug 3y ago
  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. (If you believe you personally are impervious to social engineering, imagine how many other people would respond in this situation: https://www.mercurynews.com/2023/04/27/larry-magid-how-i-nearly-fell-for-a-frightening-virtual-kidnapping-scam/ https://www.mercurynews.com/2023/04/27/larry-magid-how-i-nea....)

acdha 3y ago

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

upofadown 3y ago
>If I can convince you that my site is the login page for something else... Wouldn't TLS prevent that?
- acdha 3y ago
  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.