3 ms·

There's a frequent misconception that hardware keys are no better than, say, a TOTP seed on a secure element of your phone. The core practical difference betwe

by vngzs 4y ago

There's a frequent misconception that hardware keys are no better than, say, a TOTP seed on a secure element of your phone. The core practical difference between a hardware key and that TOTP code on a secure element is the hardware key, when registered with a domain, is programmed with the domain name in it. Lookalike domains - or anything besides the exact domain you registered the key with - fail to 2FA because they are unregistered. This essentially prevents (spear)phishing attacks from stealing login credentials.

NovemberWhiskey 4y ago
Absolutely right - put another way: the responsibility of the user is reduced from "be absolutely certain that you're entering your credentials to the web site that you think you're authenticating at" to "provide consent to authenticate".
zozbot234 4y ago
Doesn't TOTP use current time as part of the challenge? Why couldn't a refinement of TOTP add the domain name as a further element?
- netheril96 4y ago
  You can't rely on the end users to check the domain name, because * Most users have no idea what a domain name is. * It is tedious to compare the domain name character by character. * Phishing sites have used many UI tricks historically to make their domain name look authentic (e.g lookalike Unicode characters).
- somethingAlex 4y ago
  That's pretty much what happened here. Obviously it's going to look a bit different afterwards because you have to mathematically tangle the time, key, and domain together. You can't really do that with the six digits of a traditional OTP code. And like the other reply stated, if you can't mathematically tie them together, you have to rely on the user validating the domain (which you can't).
- PeterisP 4y ago
  If a user manually enters a code from TOTP device/calculator into a website, that TOTP device/calculator has no way to know which exact website domain it is - if the user visiting notmybank.com thinks they are visiting mybank.com, they'll get the right code for mybank.com from their device and get pwned. The key part of FIDO protocol is that it prevents the user from getting the code intended from one domain and sending it to a different domain.
bedast 4y ago
But this seems like a technological solution to a very human problem. If I can trick a user into approving the login, then hardware fobs, secure elements, etc, are meaningless. The audience here is likely to assume that the security is solid. And it probably is. But this is a technology targeting your average user. It'll certainly be easier for the end user. But it seems like it introduces a human-based attack vector that may be easier to exploit.
- vngzs 4y ago
  What I mean is: with modern hardware keys you literally can't trick a user into approving a remote login, or a login to a fake domain. It's not possible unless you can control the domain that the user is logging into (say you've got code execution on their machine or compromised their network and broken TLS, attacks which are significantly more complex than phishing). Hardware keys enforce that the device can only authenticate against the real domain, not a phishing domain. The core of this is a real improvement of how 2FA works at the protocol layer, rather than simply a change to how the user interacts with the device. Hardware keys also require that the key can only authenticate a local session, so there's also no risk that your "hardware key tap" can be captured and used by a remote adversary who doesn't control the local computer.

by vngzs 4y ago

NovemberWhiskey 4y ago

Absolutely right - put another way: the responsibility of the user is reduced from "be absolutely certain that you're entering your credentials to the web site that you think you're authenticating at" to "provide consent to authenticate".

zozbot234 4y ago

Doesn't TOTP use current time as part of the challenge? Why couldn't a refinement of TOTP add the domain name as a further element?

netheril96 4y ago
You can't rely on the end users to check the domain name, because * Most users have no idea what a domain name is. * It is tedious to compare the domain name character by character. * Phishing sites have used many UI tricks historically to make their domain name look authentic (e.g lookalike Unicode characters).
somethingAlex 4y ago
That's pretty much what happened here. Obviously it's going to look a bit different afterwards because you have to mathematically tangle the time, key, and domain together. You can't really do that with the six digits of a traditional OTP code. And like the other reply stated, if you can't mathematically tie them together, you have to rely on the user validating the domain (which you can't).
PeterisP 4y ago
If a user manually enters a code from TOTP device/calculator into a website, that TOTP device/calculator has no way to know which exact website domain it is - if the user visiting notmybank.com thinks they are visiting mybank.com, they'll get the right code for mybank.com from their device and get pwned. The key part of FIDO protocol is that it prevents the user from getting the code intended from one domain and sending it to a different domain.

bedast 4y ago

But this seems like a technological solution to a very human problem. If I can trick a user into approving the login, then hardware fobs, secure elements, etc, are meaningless. The audience here is likely to assume that the security is solid. And it probably is. But this is a technology targeting your average user. It'll certainly be easier for the end user. But it seems like it introduces a human-based attack vector that may be easier to exploit.

vngzs 4y ago
What I mean is: with modern hardware keys you literally can't trick a user into approving a remote login, or a login to a fake domain. It's not possible unless you can control the domain that the user is logging into (say you've got code execution on their machine or compromised their network and broken TLS, attacks which are significantly more complex than phishing). Hardware keys enforce that the device can only authenticate against the real domain, not a phishing domain. The core of this is a real improvement of how 2FA works at the protocol layer, rather than simply a change to how the user interacts with the device. Hardware keys also require that the key can only authenticate a local session, so there's also no risk that your "hardware key tap" can be captured and used by a remote adversary who doesn't control the local computer.