Recovering from Heartbleed: a checklist
On April 7, reports from security engineers at Codenomicon and Google Security emerged that confirmed the existence of a bug in OpenSSL versions 1.0.1 through 1.0.1f that made it possible for an attacker to acquire parts of a server’s memory region, possibly exposing sensitive information like user names, e-mails, passwords, and data from “secure” server sessions. (The bug is called “Heartbleed” because the bug lies in OpenSSL’s “heartbeat” extension, which allows a server connection to be kept alive during periods of inactivity.)
On the web, when you initiate a secure session with a website
(i.e., when you visit an address starting with
see the lock icon in your web browser), the web server on the other
end is using SSL (in fact, that’s what the
for). The bug in the OpenSSL software makes connections to these
kinds of websites no longer secure.
According to the analysts at Codenomicon, the bug could be present in up to two thirds of servers on the web that use the vulnerable versions of OpenSSL. It may also be present in servers that handle e-mail, instant message, and virtual private network services. To make matters worse, this bug has been present for two years, and attackers could have been making use of it for a long time without telling the public.
Due to the long-term nature of this potential exploit and its alarmingly far-reaching implications, everyone that uses web services and e-mail should be paying attention. While it’s not likely your information has been stolen, it is short-sighted to claim that no one could have discovered this bug over the past two years and exploited it somehow for personal gain. If your information was never stolen, today still seems like a good time to change your passwords and strengthen your security measures.
Therefore, I’ve compiled a checklist of actions that the average Internet user might take, including changing passwords on popular sites (like social networking sites, e-mail, and banking sites) and setting up stronger authentication methods.
I will detail the steps I took to recover from Heartbleed and provide some comments or explanations as I go. I started where most should start: by verifying that a service has actually updated their SSL implementation so that the Heartbleed bug can no longer be exploited while that service runs. The Heartbleed test by Filippo Valsorda is a nifty site that allows you to check whether a server is no longer vulnerable by sending a malicious request, much how an attacker might have in the past.
Before changing my passwords on a site, I made sure that it passed the test above. This is because a password-change operation could have been intercepted by a Heartbleed-related attack, by which an attacker could obtain both the new and old passwords.
After checking that the major sites have eradicated the bug (it seems by today that Facebook, Google, Twitter, iCloud, and Spotify have), I started to change my passwords.
You may have heard this advice before, and it’s worth following. If you use the same password everywhere, it’s simple for an attacker to obtain your password by attacking one vulnerable service and then use that password everywhere else. It’s also possible for an attacker to obtain just the hash of your password and use it elsewhere, if they have additional information about how each service hashes your password. (A hash is what results from passing your raw password through a cryptographic algorithm that has one essential property: when a given raw password is passed through, the corresponding hash always results, but there is no way to reverse-engineer the raw password from the hash. Usually, only hashes are stored for this reason. Each time you log in, the hashing algorithm is used and the result is checked with the hash stored by the service. You are allowed access only when the just-calculated hash and the stored hash match.)
I started to come up with a memorable method of designing a password that was still secure and very difficult to guess. My advice: the weirder the password, the better. You are more likely to remember a password describing a funny or unorthodox scene.
Services like Google and Facebook offer two-factor authentication, a high-security feature that was first invented for government and other critical applications. Two-factor authentication is as it sounds: it is an authentication process that requires more than one method to verify your identity. The first factor is usually a password that only you know. The second factor is best when it is something another person cannot obtain and use to pose as you. For example, if you always have your phone with you, the second factor can be a voice call or SMS that conveys a secret code to you.
Google’s two-factor authentication features are very mature
and (thankfully) easy to use. (In fact, Google was among the
first web services to offer two-factor authentication.)
click your account photo on the top right, then click Account
under your name.
You’ll be presented with a summary of your Google services and your email & phone information. Click the Security tab at the top of the page, and click Change password. Let Google’s password strength indicator be your guide.
When you are done changing your password, enable 2-Step Verification (which is what Google calls two-factor authentication). After that set up process, you should have Google call you or send an SMS whenever you log into your Google account from a different device. Since the second factor is your phone, an attacker would need to steal your phone as well as know your password. (This goes without saying, but do not store your raw password on your phone without protecting that, too — it would be trivial for a thief to get into your Google account in this case!)
Facebook has a similar feature, but they call it login approvals. After changing your Facebook password, you can enable login approvals by verifying your phone number and elect to recieve a voice call or SMS whenever an attempt to log in from a new location has been detected.
When you do change your Facebook password, you’ll want to agree to close all other Facebook sessions by clicking Log me out of all other devices when prompted. If an attacker was already logged in, they now should not be able to access your account since they will need your new password and a login approval (which you can deny and report to Facebook).
One more note: if you use online banking, you should verify and change your passwords there. Even if you have fraud protection on your accounts, attackers could have obtained bank account numbers or other data that could leave you vulnerable to real-world theft, like forging a check or making a shady withdrawal.
My final word of advice is to try to change your password everywhere and anywhere, and remember to keep your passwords distinct. In reality, if your information has been stolen by way of the Heartbleed or other exploits, there’s no way to get that data back — but you can stop them or diminish the likelihood that you will be attacked precipitously today.