Friday, April 11, 2014

Heartbleed and Two-Factor Authentication - Does it help

Along with all the hype about the heartbleed bug, I've been reading a lot of posts and articles that recommend (amongst other things) to enable Two-Factor Authentication (2FA) to all services that support it.

In general, having 2FA greatly increases your security, since you credentials are not bound to just a username/password pair (something you know), but also rely on something you have (a phone to receive text messages or a device/application that generates one-time tokens).

Is this the panacea and the solution to the heartbleed problem?

Unfortunately, the answer is "it depends".

It provides a solution in the case where an attacker has leveraged the bug, gained access to your credentials and tries to log-in as you. In that case, they don't have your secret key (in case you are using an authentication token device or application) or your telephone, in case the service sends you one-time tokens via text messages. So, they cannot gain access to your account.

But, the very nature of the bug makes 2FA just a very small problem for an attacker that mounts a Man-In-The-Middle (MITM) attack; in this case, the attacker will simply forward the token the user inputs back to the server, impersonating the user. This holds no matter what the 2FA method used is (text message, token etc). Since the user needs to transmit a token to the server, the only thing that could possibly protect the action was an encrypted communication tunnel; the same tunnel that is now compromised.

So, for a determined attacker, this bug is god-sent. Apart from patching the bug, getting the service certificate reissued and revoking the old certificate (unfortunately assuming that the end user's browser or application checks Certificate Revocation Lists) this is not an issue that will go away anytime soon.

The only real mitigation is informing users that the service was affected by the bug, and the service should instigate additional measures to thwart MITM attacks (such as checking the IP address etc). In the end, it is up to the end user to monitor their account. And we all know how many users are able to do so.

UPDATE:
Steve Gibson (@SGGrc) has created a page where you can check if your browser checks CRLs. If you can see the page, your browser does not. You can go here to check: https://revoked.grc.com/ 

No comments: