5 ms·

>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.
- upofadown 3y ago
  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.
  - acdha 3y ago
    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.
    - upofadown 3y ago
      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.

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.

upofadown 3y ago
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.
- acdha 3y ago
  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.
  - upofadown 3y ago
    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.