Technology in terms you understand. Sign up for the Confident Computing newsletter for weekly solutions to make your life easier. Click here and get The Ask Leo! Guide to Staying Safe on the Internet — FREE Edition as my thank you for subscribing!

Why Do I Need to Change Passwords After HeartBleed?

You may have noticed that I didn’t jump on the HeartBleed bandwagon last week. I’m not a particularly reactive person, I’m not prone to panicking, and I felt that there was simply too much that wasn’t known about the ramifications of the security issue.

Now that things have settled down a little, it’s time to take a calmer look at what happened, to learn what you need to do, and to answer the most common question about HeartBleed: why?

But first things first: it’s not on your machine. In fact, it doesn’t affect your machine at all. This is all about the servers that you access on the internet.

Become a Patron of Ask Leo! and go ad-free!

Heartbeats and SSL

The web comic XKCD did a near perfect job of expressing HeartBleed in a simple and clear way.

Even so, it makes some assumptions, so I’ll try and walk through what’s happening.

The SSL (Secure Sockets Layer) protocol that we rely on for https and other forms of encrypted communication on the internet includes a feature called a heartbeat. When one computer is connected to another using SSL, the first can ask the second “Are you still there?” every so often. This is useful if data isn’t actively being transmitted to confirm that the connection is still working.

From what I understand, the heartbeat feature isn’t used very often, but because it’s part of the definition of the SSL protocol, it must be implemented by all SSL servers in case it’s needed.

The format of that “Are you still there?” request is actually kind of strange. Rather than just asking a yes/no question, the question is more of the form:

If you’re still there, respond with the word “HELLO” which is 5 characters long.

The server responds:


Now, “HELLO” in my example can be anything at all. The key is that server A sends it, and its length, and server B echoes it back to confirm that the connection is still alive and kicking.

HeartBleedHeartBleed in a nutshell

Exploiting HeartBleed is extremely simple. The requesting machine asks:

If you’re still there, respond with the word “HELLO” which is 500 characters long.

“HELLO” is not 500 characters long. The request is actually malformed – either the string “HELLO” should be replaced with something that actually is 500 characters long, or the length should be accurate: five characters. (And a reminder: the text “HELLO” can be anything, and the 500 can be any number – they’re just my examples.)

So, what’s an SSL server to do?

The bug is that in response to this malformed request, the server responds with 500 characters of … stuff:

  • The five characters that it was presented with.
  • 495 characters of whatever else happened to be in the server’s RAM memory at the time.

And that’s where it gets interesting.

Bleeding sensitive data

AJAX progress indicator
The excess data that’s returned by the server, the data that happened to be in memory, could be just about anything.

It has apparently been known to contain the “secret key” used by SSL encryption.

That’s bad. That’s really bad. And that’s why the internet world was all aflutter1 last week.

You see, the key is secret for a reason. Every https and SSL secure site has one that’s used to decrypt the data that you send to it. If you could get your hands on the secret key used for, say, then you could decrypt all of the encrypted traffic being sent to it. (Replace “” with your bank, your email service, your online medical records – anything that uses https to secure the connection.)

You could decrypt all of the usernames and passwords as people login.

The HeartBleed bug made this possible, at least on those servers that were affected by it.

You could be logging in to your bank thinking that you were completely secure because the connection was https, not knowing that someone was listening in and capturing your username and password.

The fix on the server

Fixing HeartBleed itself was actually very simple. Getting it out to all the affected servers took a little time. And an interesting ramification made it take a little longer yet.

The bug had already been fixed in later versions of the OpenSSL software being used.

Servers simply had to update their copy of OpenSSL (or that portion of it that contained the bug).

But that wasn’t enough.

AJAX progress indicator
As the HeartBleed bug had been “in the wild” for two years, no affected server could assume that it hadn’t been compromised. In other words, they had to assume that their secret key was no longer secret. That means that they had to generate a new SSL certificate with a new secret key and update that on the server as well. As SSL certificates go through a verification process, that added a little time.

With the bug fixed and a new certificate and secret key in place, the server’s secure once again.

The ramifications to you and me

For the last two years, it was possible that hackers have been snooping in on your https connections to the servers affected by HeartBleed. That means that they could have seen and recorded your username and passwords.

That is why you need to change your password.

But wait!

If you change your password before the server has installed a new secret key, the hackers could be watching you change your password!

That means that:

  1. You need to avoid using any servers that were affected until they have fixed the bug and updated their SSL certificate and secret key
  2. You should change your password after the server has fixed the bug and updated its SSL certificate and secret key.

Anything you do before the certificate is updated could still be captured by hackers, so there’s simply no point in doing anything until after the certificate is updated. And there’s nothing that you should or could do until then.

How do I know if a server has been affected?

Not every server was affected, and it’s important to know when affected servers have been fixed.

Start with the LastPass HeartBleed checker. Enter the server that you want to check. It’ll tell you:

  • If the server was ever vulnerable to HeartBleed.
  • If it’s currently vulnerable to HeartBleed.
  • When the server’s certificate (and thus secret key) was created.

It also includes advice on whether you need to change your password.

Lastpass’ information appears to be cached, so it might be a little out of date at times. If a site reports currently vulnerable, however, keep checking until it’s not or check directly with that service’s customer service for information. is a real time check of a server’s HeartBleed vulnerability, but it doesn’t include information about certificate updates.

How big a deal is this really?

The real question a lot of people have been asking is just how big an issue has this really been?

The potential for abuse is unquestionably enormous. Had this gone unfixed for a long time while being public knowledge, the potential for hackers to easily and continually hack sites considered “secure” was truly frightening.

But that didn’t seem to happen.

The information went public, the fix was deployed, and the impact appears to have been minimal. Yes, there have been a couple of specific confirmed cases of hacks due to HeartBleed, but nothing that seems to be in proportion to the bug having been in place for two years.

And to be clear: that the bug was in place for two years does not mean that anyone knew about it for two years. We don’t really know when the first person discovered it. There were early reports that the NSA knew and exploited the vulnerability for nearly the entire time, but of course, they have denied that. It’s quite possible that the bug’s very existence was discovered only recently.

So … we don’t know.

But because of the enormity of the possibility, the safe thing to do is change your password on any system that’s been affected, after it has been fixed.

Two other things you can do

First, there are browser extensions for FireFox and Chrome that will tell you if the site you’re accessing is vulnerable to the HeartBleed issue.

Now, several people have asked if the developers of these extensions are trustworthy. That’s a very good question with no simple answer. I do trust that should anything underhanded become known, the uproar would be significant. For the record, I’m running ChromeBleed.

Second, there’s a concept called “certificate revocation” that is designed to handle the situation where a certificate becomes compromised. In essence, each time a browser uses a certificate, there’s a mechanism to check whether or not the certificate has been revoked.

The bad news is that browsers may or may not check for revocation by default because it will potentially slow down your initial connection to a site. It’s a setting that you’ll need to change.

  • In Google Chrome: Settings, Show advanced settings…, HTTPS/SSL, Check for certificate revocation.
  • In Firefox: Tools, Options, Advanced, Certificates, Validation: make sure that both “Use OCSP” and “Treat as invalid” are checked.
  • In Internet Explorer: Internet Options, Advanced, Security. Make sure that both Check for publisher’s certificate revocation and Check for server certificate revocation are checked.

Revocation is important because if the SSL certificates for sites that you visit were in fact stolen during a server’s HeartBleed vulnerability, hackers could potentially install those certificates on bogus sites and pretend to be those sites. Revocation marks those previously good certificates as invalid.

Two factor would have helped (you)

Google was affected, yet I didn’t panic.

Besides there being no indication that they were ever compromised, I have two-factor authentication enabled on my Google accounts. That means that it’s not enough to know my password to login. Even if hackers had somehow sniffed my password while the Google servers were vulnerable, they still would not have been able to compromise my accounts.

I sleep a lot easier because of that.

And in today’s hack-filled world, two-factor authentication is something you might consider on any service that offers it.

You’ll sleep a lot better too.

Do this

Subscribe to Confident Computing! Less frustration and more confidence, solutions, answers, and tips in your inbox every week.

I'll see you there!

Footnotes & references

1: Sadly, we can’t say “all a’twitter” any more without implying that Twitter was the only place where the alarm was raised.

31 comments on “Why Do I Need to Change Passwords After HeartBleed?”

  1. This bug only affected OpenSSL. My bank uses Active Server from Microsoft, which doesn’t use OpenSSL, so I’m not affected.

    • Again, I’m not a big believer in conspiracy theories. The code never started “running wild” – it was not a virus, it was a simple bug.

      • I read a report that NSA has know about the bug for a while, without telling anyone, and may have used it for their own purposes.

        • Yep. I read that as well. It’s based on unverifiable reports, and of course the NSA completely denies it. No idea whether it’s true or not. Certainly there’s currently no evidence that it is.

  2. very [good] article, as we have come to expect. One question not answered: could a hacker have stolen info like credit card data from web sites? In this case, that data could still be used (and sold) for months to come even if a password to the web site is changed. Or in Google’s case (Gmail) could a hacker have gained access to an email in which a bank account number or credit card number is written?

    • Jim: The key (pun not intended) is not that heartbleed gave them bank account information but that it gave random information that was in the computer’s memory at that moment.
      If somone collected that information and was able to recognize what it ment (have you ever glanced at a program file in a text editor, it is hard), the hope (for them) would be that the passwords to unlock the information that the computer could access was in the information and recognizable to them.
      If they got those passwords, then all the banking information of everyone on that computer would be theirs.

  3. thank you Leo, nobody else out there told us anything at all about heartbleed. not not gmail not facebook or anybody. i didn`t even know google had a fix. i`m gonna send feedback to google about that. the smartest thing i ever did as far as my computer goes was to subscribe to Thank You again.

  4. Nice post. One of the best explanations of the problem I’ve read. I work with SSL Key/Certs and I know it can be a bit confusing for users to understand what it means. Keep up the good work.

  5. I haven’t even finished reading Leo’s article, but I already know it deserves my enthusiastic applause. Some major media outlets are even describing HeartBleed as a virus, but Leo quickly straightens us out about that myth; it’s a software bug/vulnerability, but as Leo emphasizes, the problem is NOT with the user’s system. Thanks, Leo, for helping to get things easier for us to figure out!

    • You know, I have to agree with someone who commented (elsewhere) something to the effect of “Wait. You find a major flaw in the underpinnings of internet security, and the first thing you do is go out and buy a domain name and design a logo?”

  6. Nice article and all other websites tell us how good this heartbleed extension is but there is no possiblility of getting it as there is no link/button/download to click on.
    The Chrome extension page which has ‘get more extensions’ shows no sign of it.

    The Chrome heartbleed site is itself frozen frozen. Any advice please.

    • I’m not sure what to tell you – the links work for me, and this is the first I’ve heard of any problems. Might try clearing the browser cache, or a using a different browser.

  7. Great article. Really good explanation and easy to understand. I can’t believe that server B would answer with the requested “word” but totally ignore the fact that the number of characters requested is several hundred greater than the “word”. Surely a simple piece of programming would spot this and refuse to communicate until the requested number of characters matched the length of the “word”. It’s hard to believe that servers carrying masses of sensitive information could be so easily fooled. Scary!!

    • As a decades long software engineer I can attest to the fact that these seemingly stupid mistakes are frighteningly easy to make or overlook. That’s not an excuse (it should have been caught, of course), just an observation on the complexity of software engineering.

  8. Not only did I do what Leo has stated as far google chrome but I also found out I have one of the very few Android phones that was acceptable to the bug which runs 4.1 jelly bean but they have a app in the playstore you download it and it will tell you if you visit a affected web site. I got my warning from the my phone manufacture Motorola

  9. Any recommended password manager that will 1) auto change all passwords or better yet those that need to be changed when site safe, 2) will work across multiple devices, 3) can put passwords on file or print hard copy for personal backup? With so many sites to check and passwords to change, seems like password manager could simply with great service. But is the password manager safe from being hacked and exposing all of a person’s passwords?

    • I’m not aware of any that do “auto change”. I wouldn’t use it if there were – too much potential for things to go wrong. LastPass pretty much meets all your other requirements, I believe.

  10. I discovered that I did not have Firefox settings correct; I had not marked “treat as invalid.” It is good to revisit these settings occasionally. But who remembers?
    THANKS, LEO. I have come to rely on you and your advice.
    Regarding how errors sneak into code: I, too, was a developer for many, many years. People make mistakes when writing code (I have), when testing code (I have), when deploying code (I have). That is why they are called errors.

  11. Your instructions to check FF browser settings: “In Firefox: Tools, Options, Advanced, Certificates, Validation: make sure that both “Use OSCP” and “Treat as invalid” are checked.” OS MS Win 7
    As I was checking my FF Browser, I read “On-Line Certificate Status Protocol”, OCSP. i’m not nit-picking but rather pointing out that 1 letter may or may not make a difference. It sure did when writing COBOL!
    Is OCSP and OSCP the same? I updated the “Treat as invalid” box & checked it also.

    Thanks for putting the HeartBleedin’ TRUTH out to your loyal readers.

  12. When the news popped up I used some 6 hours to read some articles about this issue.
    Upon which I decided it was more screaming than sense.
    And did nothing, IF some creature by chance got usernames and passwords, let them be happy with it. They’re only wasting their time.
    If you didn’t notice anything out of the ordinary during the last couple of years you’re probably safe.

    Most guys discussing such issues know a lot more than most do, but seems not to understand that for some nitwits like me it’s difficult to grasp.
    The Leo team is one of the few who realizes that. Soyez sage et simple.
    We have to give you credit for that.

  13. I changed my Chrome and Firefox settings as recommended above (In Firefox: Tools, Options, Advanced, Certificates, Validation: make sure that both “Use OCSP” and “Treat as invalid” are checked.) In the latest version of Firefox, when I try to access Yahoo and Facebook, I get an error message: “Secure Connection Failed. . . The OCSP server experienced an internal error. . .” I had to uncheck “Treat the certificates as invalid” box. So what does that mean, that Yahoo and Facebook are bad websites?

    • No, more likely something at issue with the OCSP process. I would try the same site w/ another browser, also set securely, and see what results.

      • I had made the settings in Chrome, like you had suggested, and Yahoo and Facebook work fine in Chrome. I won’t try it Internet Explorer since the US government said it’s dangerous to use. :-)

  14. According to Last Pass:

    Warning: was confirmed as vulnerable either publicly via statement or on 4/8/2014; Change your password on this site if your last password change was more than 2 months ago.
    Being caught between two major corporations is a nightmare. My ISP is Verizon, and through them I pay for a “Verizon-Yahoo” (Yahoo Mail) account. Neither company will assist with the most basic issues. Yahoo simply refuses to respond, and directs VY customers to Verizon; Verizon has no earthly idea of how to help with Yahoo Mail.

    It is so bad currently, I am unable to change my Yahoo Mail password. A phone number is given to call Verizon … at their main 800 number. Of course, they have no idea how to change a Yahoo email password.


    Shame, shame, shame on Yahoo for acknowledging its vulnerability and not advising its customers to change their passwords!


Leave a reply:

Before commenting please:

  • Read the article.
  • Comment on the article.
  • No personal information.
  • No spam.

Comments violating those rules will be removed. Comments that don't add value will be removed, including off-topic or content-free comments, or comments that look even a little bit like spam. All comments containing links and certain keywords will be moderated before publication.

I want comments to be valuable for everyone, including those who come later and take the time to read.