3 ms·

And yet. I am shocked to see that all the "two-factor authentication" approaches don't bother to mention the action that is being authenticated. People often

by EGreg 4y ago

And yet. I am shocked to see that all the "two-factor authentication" approaches don't bother to mention the action that is being authenticated. People often are conditioned to simply enter their passwords and their two-factor authentication into a window just because they think they are dealing with an official representative. If you think you're immune, think of how many times you've entered your information into Plaid, which was displayed as a mere iframe on a website! How did you know it was Plaid? Because you trusted the enclosing website? And for that matter, why do you trust Plaid? People get phished all the time by having a "bank rep" call them on their phone and have them read back these numbers, claiming that a different action is about to take place than the one being confirmed. All that could be EASILY stopped by the banks if they just added the action that's about to be confirmed. But somehow this hasn't happened in any of the incarnations. PS: I think some places in Europe do mandate it but not USA at all!

mirashii 4y ago
Webauthn does cover the scenario described by associating the credentials in the hardware token with the domain name, so that you're not entering credentials into a random site or iframe; the browser and token are verifying that the URL requesting a challenge is the same as the one that generated the credentials in the first place. Showing the action as part of the dialog doesn't really solve the threat posed here, because if you're not validating where you're answering a challenge from, then you also don't really have a way to know they're not lying about the action presented.
tialaramex 4y ago
All that the second factor mode of WebAuthn does is "This still me". Who? Me. That's all. The token intentionally has no idea who "me" is, nothing is preserved from one such interaction to another - it only knows that it's still the same token as it was before. This makes the technology privacy preserving yet is ideal for the specific scenario we care about - proving I'm still me. I just typed my username or email or whatever into a web site, so the web site already knows who I claim to be on that web site, they're just checking that in fact "this is still me" whoever that is. You can leverage this technology to do more, including your "action that is being authenticated" stuff, but this adds complexity we mostly don't need. It turns out we can get a really long way with just absolute certainty that "This is still me".
kadoban 4y ago
To really do this right, the yubikeys would need to have some kind of display to see what action you're confirming. Slightly better than nothing, the OS/browser UI could show it. Something like Plaid is unfixable though, that's just a garbage heap of insecure patterns. I refuse to use it.
- g_p 4y ago
  Something I was disappointed (but not surprised) to never see take off outside a few niche areas and closed systems like payment card terminals was personal smartcard readers. Even reasonably affordable ones commonly have a 16x2 or 16x4 LCD screen. While today's protocols and drivers don't inherently tie together the data being signed with a string shown on the screen, appropriate design of protocols could enable this - then you'd have a hardware reader with PIN pad, where your PIN isn't seen by the computer, and with a screen showing you exactly what domain you are logging into, or which action you're approving. You can implement webauthn on a smartcard just fine as well (there are open source applets for it I believe) - just a shame that hardware readers with trusted displays never really took off on desktop PC! Then again for "just login" like in webauthn, really the domain is the only thing seen. A rogue local browser app can prompt you to authenticate for an arbitrary domain, but it's challenge/response based so the attack needs to happen in real-time.
kurupt213 4y ago
this wouldn't have been caught by the authenticator app either, would it?

by EGreg 4y ago

mirashii 4y ago

Webauthn does cover the scenario described by associating the credentials in the hardware token with the domain name, so that you're not entering credentials into a random site or iframe; the browser and token are verifying that the URL requesting a challenge is the same as the one that generated the credentials in the first place. Showing the action as part of the dialog doesn't really solve the threat posed here, because if you're not validating where you're answering a challenge from, then you also don't really have a way to know they're not lying about the action presented.

tialaramex 4y ago

All that the second factor mode of WebAuthn does is "This still me". Who? Me. That's all. The token intentionally has no idea who "me" is, nothing is preserved from one such interaction to another - it only knows that it's still the same token as it was before. This makes the technology privacy preserving yet is ideal for the specific scenario we care about - proving I'm still me. I just typed my username or email or whatever into a web site, so the web site already knows who I claim to be on that web site, they're just checking that in fact "this is still me" whoever that is. You can leverage this technology to do more, including your "action that is being authenticated" stuff, but this adds complexity we mostly don't need. It turns out we can get a really long way with just absolute certainty that "This is still me".

kadoban 4y ago

To really do this right, the yubikeys would need to have some kind of display to see what action you're confirming. Slightly better than nothing, the OS/browser UI could show it. Something like Plaid is unfixable though, that's just a garbage heap of insecure patterns. I refuse to use it.

g_p 4y ago
Something I was disappointed (but not surprised) to never see take off outside a few niche areas and closed systems like payment card terminals was personal smartcard readers. Even reasonably affordable ones commonly have a 16x2 or 16x4 LCD screen. While today's protocols and drivers don't inherently tie together the data being signed with a string shown on the screen, appropriate design of protocols could enable this - then you'd have a hardware reader with PIN pad, where your PIN isn't seen by the computer, and with a screen showing you exactly what domain you are logging into, or which action you're approving. You can implement webauthn on a smartcard just fine as well (there are open source applets for it I believe) - just a shame that hardware readers with trusted displays never really took off on desktop PC! Then again for "just login" like in webauthn, really the domain is the only thing seen. A rogue local browser app can prompt you to authenticate for an arbitrary domain, but it's challenge/response based so the attack needs to happen in real-time.

kurupt213 4y ago

this wouldn't have been caught by the authenticator app either, would it?