The Heartbleed bug was one of the worst online security vulnerabilities in recent memory, allowing an attacker to read chunks of a server’s memory that might contain private keys, authentication credentials, and other sensitive data. In the wake of Heartbleed, it’s a good time for WordPress site owners to audit their security procedures and implement mechanisms for keeping their site and its users safe. Two-factor authentication is one easy-to-implement security strategy that makes life more difficult for hackers.
The normal username / password combination can be thought of as one-factor authentication. There is one secret token that will grant access to the site. Two-factor authentication adds another token, which can be generated in various ways: most commonly by using an application to provide a one-time password, a physical token like a Yubikey, or a biometric factor like a fingerprint.
The most easily implemented TFA mechanism uses an app on a mobile device to generate a time-limited password that must be used in concert with the user’s standard password to gain access. This works because both the mobile device and the service have access to a shared secret. Apps like Google Authenticator carry out a calculation using the time and the shared secret to generate a code that’s only valid for a few seconds. Because both the service and the app know the shared secret and the time, they generate the same one-time password or code. Without having access to the device (or knowing the shared secret) a hacker can’t log in.
It’s worth taking some time to think about whether TFA would have helped users of services that were vulnerable to Heartbleed. It’s a complex subject, and the answer is “maybe”, depending on the specific implementation the TFA provider used and the information the hacker obtained.
Heartbleed provided access to a 64KB chunk of memory being used by OpenSSL. If the hacker obtained username/password combinations from that memory segment, but not the shared secret used to generate the one-time second factor, the user would be safe. If the TFA implementation lead to the shared secret being present in that part of the server’s memory, then the advantages of TFA would be nullified. If the hacker stole the private key used to encrypt SSL connections to the server, they’d have to perform a fairly complex man-in-the-middle attack rather than a simple login, but they would be able to see all communication between the server and browsers, including username/password combinations. They would not be able to see the shared secret, though, making their knowledge of the other login credentials useless.
In a nutshell, depending on the specific implementation, TFA made life more difficult for individuals who attempted to leverage the Heartbleed vulnerability, but it didn’t completely negate the risk.
Implementing Two-Factor Authentication On WordPress
There are several services that provide plugins for implementing two-factor authentication on WordPress. I’m going to highlight a couple of them here.
Authy is a two-factor authentication service for WordPress that works much like Google’s Authenticator (at least outwardly; it’s not identical under the hood). After installing the plugin and the mobile app, which is available for iOS and Android, WordPress users have to provide their usual authentication details plus a token provided by the app when logging in.
You can read about Authy’s response to Heartbleed on their blog.
Duo Two-Factor Authentication
Duo offer a similar service to Authy, providing a WordPress plugin and mobile app that enables the generation of one-time passwords for WordPress logins. They also have a Heartbleed post-mortem that details the potential vulnerabilities in their service and how they protect against malicious third-parties gaining access to API keys and shared secrets.
While TFA won’t necessarily make your WordPress site invulnerable to Heartbleed-type issues should they arise in the future, it will make it significantly less vulnerable to most of the common security risks that it faces and is definitely worth implementing, in spite of the slight inconvenience it may cause to users.