2

As I understand, modern phishing is kind of like a man-in-the-middle attack. Let's say, for example that User u has an account in Domain d where he has an SMS based 2FA enabled. This is what the phishing mechanism is like:

  1. Attacker presents a login page on a domain d' which looks similar to the login page of the domain d.
  2. User u does not recognize this and he enters his credentials to this page on d'.
  3. Attacker turns around and uses these credentials to login into Domain d.
  4. Domain d sends u an OTP on his phone.
  5. Attacker presents u an OTP verification page on domain d'.
  6. User u enters this OTP on d'.
  7. Attacker turns around and uses this OTP to authenticate himself on Domain d.

Now, if the user u had a hardware key, the last few steps would be very similar.

  1. Domain d sends attacker a challenge.
  2. Attacker reelays the challenge to the fake page on domain d'.
  3. User uses his hardware key to sign the challenge.
  4. Attacker turns around and submits the signed challenge to domain d, pretending to be u.

So, in what way is a hardware based authentication mechanism like yubikey better than SMS based OTP, or TOTP codes?

3 Answers3

2

Let me start with a basic summary of some types of protection:

  1. SMS. Sent via text message to mobile phone. Vulnerable to interception/spoofing, since SMS is not a secure channel.
  2. TOTP Generated via TOTP device (smart phone app, key fob, etc.). TOTP codes are generated offline, so no vulnerability to interception/spoofing of the TOTP code itself. Provides no protection against phishing.
  3. Security key (e.g., U2F). Generated via key fob and similar. Protects against phishing, since the challenge-response step uses a signed challenge; the phishing site won't have the key, so the response step will fail. According to google, security keys are highly effective at thwarting phishing attacks, including targeted phishing attacks.

Note that Yubikey sells both TOTP and U2F devices.

What U2F hardware accomplishes:

Where a U2F hardware beats out TOTP is when someone tries to perform a phishing attack during steps 4-7 from OP. The U2F key is bound to the origin's domain (and the authentication requires TLS), so a phishing domain cannot receive the key. SMS and TOTP are vulnerable to phishing via look-a-like domains (or inattentive users), whereas U2F will only send the response if the challenge is from the right domain.

U2F does fail if the attacker is able to acquire a valid certificate for the origin's domain. However, at that point the attacker can man-in-the-middle the post-authenticated connection and steal the user's authentication cookie, so protecting the authentication channel from such attacks provides little value regardless.

Obligatory pedantic note: Technically, U2F can use token binding to block authentication even if the attacker has a valid certificate for the origin. However, the browsers have explicitly decided it's not worth bothering to support that, probably because protecting the authentication step itself is kind of useless if the communication channel itself is compromised.

Brian
  • 932
  • 5
  • 17
  • 2
    "U2F will only send the response if the challenge is from the right domain." Can you provide some details as to how this is accomplished? As far as I can tell, my hardware key only functions as a USB keyboard, i.e, inputs text into a text field. I am not sure it can make HTTP requests by itself – Agnishom Chattopadhyay Apr 20 '22 at 18:12
  • 2
    @AgnishomChattopadhyay: An output-only fob isn't going to be able to implement U2F, though it could definitely implement TOTP. The U2F protocol (and related protocols) are typically implemented via the WebAuthn spec. High level, a website prompts for a second factor, then the browser connects to it. E.g., if you click the login button on the demo at https://webauthn.io/ in chrome, the browser pops up a dialog box (screenshot: https://i.stack.imgur.com/rLHi1.png ). If you select, "external security key," the browser can enter bidirectional communication with an appropriate USB key. – Brian Apr 20 '22 at 20:10
  • @AgnishomChattopadhyay: Specifically, the relying party's ID must be scoped to the current domain. E.g., a U2F token used to authenticate on `security.stackexchange.com` can only send/receive credentials stored under id `security.stackexchange.com` or `stackexchange.com` . – Brian Apr 20 '22 at 20:22
  • 1
    who checks that the domain in the challenge and the domain the challenge is being received from is the same? The browser? – Agnishom Chattopadhyay Apr 21 '22 at 20:59
  • 2
    @AgnishomChattopadhyay: Yes, a spec-compliant browser will ensure that the domain matches. Specifically, the [Relying Party Identifier](https://w3c.github.io/webauthn/#relying-party-identifier) must be equal to the origin's effective domain (or a suffix of the domain). – Brian Apr 22 '22 at 13:25
1

Your described phishing mechanism is a very specific workflow; phishing attempts are not limited to it, alone! If you think outside of this single scenario, you will be able to recognize the benefits.

With software based TOPT 2FA, the secret is not protected by a hardware layer. This means the user has (or at least had) access to the seed, making it easy to copy the entire authentication factor. In addition to malware based attacks, someone could phish this information or, e.g., take a picture of a QR code used to deliver it, as the QR code is not disposable, but has all the information required to generate the TOPT codes forever.

Example TOPT QR code

This QR code simply has the URL otpauth://totp/example?secret=correcthorsebatterystaple&algorithm=SHA512&digits=6&period=30

For example, Google Authenticator allows Transferring codes to new phone by revealing the secrets via QR codes. An unsuspecting user may be enticed to use this feature and pass on the QR codes.

With a hardware based TOPT the secret is stored separately, so no malware can access it directly. Also, because users do not have access to the seed, they could only give away the current TOPT code, narrowing the time window an attacker has.

Esa Jokinen
  • 16,100
  • 5
  • 50
  • 55
0

With regard to phishing the exploited weak link is the user so very little difference in the kind of MFA used.

But there are plenty of scenarios where a user password is compromised through no fault of his/her own, and then there is a big difference between e.g. a SMS based OTP that is vulnerable to SIM swapping, and a YubiKey/SecureID that actually needs to be stolen.

Bruno Rohée
  • 5,221
  • 28
  • 39