I was talking with a friend about HeartBleed, and he mentioned that he had 2-factor authentication enabled on all the sites that supported it, so even with his username and passwords, nobody would be able to login without his phone too.

I told him to change his passwords anyway.

But I'm interested to know; was he right about 2-factor authentication protecting him from the worst of it?



  • If he had recently logged in, the 2FA secret could still be present in the server's memory when an attack occurred, allowing an attacker to generate his own tokens. Commented Apr 10, 2014 at 1:51
  • 1
    It probably wouldn't help too much.
    – KnightOfNi
    Commented Apr 10, 2014 at 1:57
  • Somewhat on a tangent, what Facebook and Google does with strange logins is interesting too. If you log on from a different country or far away, it locks down the account if you have something like a secondary email or phone number to verify.
    – Muz
    Commented Apr 10, 2014 at 3:32
  • 2
    In many 2FA implementations, the token is tied to the browser that you are logging in from. On Facebook and Google for example, I need to establish a 2FA token for each computer that I log in from. The token is only good one time. I can't even use the token in two different browsers on the same computer. This would mean that 2FA would protect against Heartbleed. Am I wrong? Commented Apr 10, 2014 at 16:11
  • @StefanLasiewski you're not wrong! 2FA does protect against heartbleed on the condition that the process that generates the OTPs is not running openssl and using TLS in some way that makes it exploitable.
    – Wes
    Commented Apr 12, 2014 at 18:20

2 Answers 2


I disagree with Mark. A main goal of SSL/TLS is the protection of the long term key (i.e. the private certificate). If an attacker can obtain the key, the implementation must be considered broken.

It does not matter if you use two-factor authentication or not. If I know the server's secret key, I can decrypt your traffic either directly (without PFS) or via MITM (with PFS). I can steal your session cookies or whatever and do everything without your token. I can even steal your TCP sessions.

  • 2
    We were talking in the concept of grabbing account info and using it to log in...If I'm understanding this correctly, two-factor authentication would protect from someone logging in as you. Right?
    – evamvid
    Commented Apr 10, 2014 at 21:03
  • It depends on how the second-factor is calculated. I assume that this is most often not exploitable. However, if the secret from which a token is calculated resides within the 65k the attacker can read, the token is compromised.
    – fr00tyl00p
    Commented Apr 10, 2014 at 22:45
  • @fr00tyl00p it's 64k, and also there is no reason for the code generating the OTP to be in the same process as openssl.
    – Wes
    Commented Apr 12, 2014 at 18:21
  • It's 16k actually.
    – fr00tyl00p
    Commented Apr 13, 2014 at 21:37
  • Main vulnerability is that the attacker can sniff out the shared secret between the client and server used for generating one-time passwords. If its loaded into RAM on the server, Heartbleed can leak the shared OTP secret, rendering 2FA ineffective. Commented May 13, 2014 at 17:00

Proper two-factor authentication (authentication with both a password and a single-use token sent via an external channel) provides protection against the Heartbleed attack. An attacker can get both the password and the token, but with a proper implementation, the token is worthless for actually attempting a login of their own: it's single-use, and it doesn't give any clue as to what the next token will be.

The "wish-it-was-two-factor" authentication used by entirely too many sites (username, password, trivia question about you) provides absolutely no protection.

  • Are well-known implementations truly single-use? In other words, could a fast (scripted) login use the current token before it expires? Commented Apr 10, 2014 at 6:28
  • I don't know about SecurID and other time-based systems, but demand-based systems such as sending a token via SMS should invalidate the token the first time it's used.
    – Mark
    Commented Apr 10, 2014 at 8:18
  • 1
    If the two-factor token generator's seed was exposed by Heartbleed then two-factor is entirely worthless. If you're using two-factor, whatever app you are using you should generate a new seed immediately if you haven't done so since the public disclosure of Heartbleed. Commented Apr 14, 2014 at 18:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .