How to protect yourself in Heartbleed's aftershocks

How to protect yourself in Heartbleed's aftershocks

Summary: The companies know what to do about Heartbleed now. Here's what you, as an individual, need to do now.


Businesses should not only know about Heartbleed, they should have already implemented Heartbleed fixes by now.  If your bank, favorite online merchant, or software provider hasn't yet, close your accounts and find new ones. That's my first bit of advice on how users should handle Heartbleed.


Heartbleed really is that bad. Your user-ids, your passwords, your credit-card numbers, everything you place online is potentially in play for hackers. You can not fool around with this.

So, as I said earlier, get ready to change all your passwords. Yes, every last damn one of them. Were your favorite sites vulnerable? You can check specific sites with the Heartbleed test, LastPass Heartbleed checker, or the Qualys SSL Labs test. The first two just check on Heartbleed while the last checks for other possible Secure-Socket Layer/Transport Layer Security (SSL/TLS) and awards sites a grade from A (the best) to F (failure).

ZDNet's sister site, CNet, also has a constantly updating list, Heartbleed bug: Check which sites have been patched, for the 100 most popular Web sites. I'm annoyed to say that some popular sites, as of early Thursday evening, April 10th, may still not be safe. These include sites you might expect to be behind the times — like some porn websites — but also such major household-name sites as CNN, the Huffington Post, and

Once you know your site has the bug fixed then you should change your password right? Wrong.

Ask the company if they really have patched their software AND installed new SSL certificates from their Certificate Authority (CA). Only once they've done both those things should you change your password. And let me remind you again, for pity's sake change it to a good password. This xkcd cartoon I cite in an earlier story on passwords actually gives great advice.

Next, if your favorite sites or services, such as Google, GitHub, or Microsoft support two-factor authentication, use it. Yes two-factor is usually a lot more trouble to set up than a simple password. So what? In an increasingly insecure world, you'll need it.

Done yet? Nope.

You should also clear out all your Web browsers' cache, cookies, and history. That's never a bad idea anyway. You don't want old memorized passwords walking into trouble at an untrustworthy site. To do this with the most popular browsers, follow these steps:


  • In the browser bar, enter: chrome://settings/clearBrowserData
  • Select the items you want to clear. For example, Clear browsing history, Clear download history, Empty the cache, Delete cookies and other site and plug-in data.


  • From the Tools or History menu, select Clear Recent History.
  • From the Time range to clear: On the drop-down menu, select the desired range; to clear your entire cache, select Everything.
  • Click the down arrow next to "Details" to choose which elements of the history to clear. Click Clear Now.

Internet Explorer 9 and higher:

  • Go to Tools (via the Gear Icon) > Safety > Delete browsing history....
  • Once there, choose to delete Preserve Favorites website data, temporary Internet files, and cookies.

I know this is a lot of trouble. Take the time to do it.

You're going to see all kinds of e-mails soon about magic solutions to all your Heartbleed problems. Yeah, right. They'll all be spam either bearing malware or pointing you to sites that contain malware. There's no quick fix for Heartbleed.

Finally, start checking your bank and credit-card statements very, very carefully. If you've been compromised, chances are all too good that you'll find out by finding bogus charges on your credit cards.

Good luck. We're all going to need it.

Related Stories:

Topics: Security, Networking, Open Source

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • heartblood checkers

    As I understand it, the lastpass checker will tell you if a site was likely vulnerable in the past, AND will tell you how new the SSL Cert is. That's a plus. The other two will only tell you if it is currently vulnerable.
    • False positives

      This goes back to the "2/3rds of the servers on the internet" statistic being widely repeated in articles about this bug. While 2/3rds of the servers on the internet may use OpenSSL, it seems like only about 1/6 of those are using a version that had this vulnerability (that's still a lot, and the fact that you can't tell what software websites are using makes it unnerving). Lots of people are still running OldStable releases and don't have much reason to upgrade.

      I just checked a RedHat 5 system running OpenSSL 0.9.8 and got back a "Likely affected - you should change your passwords, certificate is over 1 year old and may be compromised" warning, so please take these scary warning messages with a grain of salt.

      Also, the ssl labs checker will give Windows IIS servers with the default configuration an 'F' grade just because they are configured to use SSLv2 if the client doesn't support any other protocols (I'm not sure what that would be, Netscape 4 perhaps?) That seems a little harsh, and will only fan the flames of panic from the users who don't really understand what is happening.

      With the degree of panic out there right now, it seems like services who were not affected should notify users that they do not appear to have been affected, and those that were affected should let the users know what steps have been taken (updated openssl on date, installed new certificate on date) otherwise users will think you are hiding something, or if they use the lastpass checker, they may think that you are still vulnerable.

      So far, I haven't heard from any of my credit cards, utilities, etc.
  • well, not "only"

    ssl labs checks many other things, too.
  • Checking Sites

    I have tried a few and I keep getting the following:

    All good, seems fixed or unaffected!

    So, which is it? If "fixed", I should update my password but if "unaffected" should I leave it alone?
    • I agree

      It's hard to tell whether a site WAS affected, IS affected, Has been fixed. Steven, you say "If your bank, favorite online merchant, or software provider hasn't yet (been fixed), close your accounts and find new ones." How on earth are we supposed to know this? I'm seeing that Google/Gmail was vulnerable; but various test-sites I've seen give it a clean report. Really hard to know what to do at this point, though I guess your advice to change your credentials now and then later, painful as it is, probably makes sense.
  • Dumb question: Webmail vs. POP/SMTP servers

    Let's use Yahoo! as an example:

    Webmail -> (port 443)

    POP -> (port 995, SSL)

    SMTP -> (port 465, SSL, or port 587, TLS) [Note: authentication required]

    The CNet list indicates that Yahoo! was vulnerable, but has been patched. Were the Yahoo! POP and SMTP servers also vulnerable?
    Rabid Howler Monkey
    • Don't know, but...

      ...I think it's safe to assume. Looks like everything was going through SSL; but it's unclear whether heartbeat was in play.
      John L. Ries
      • It could be

        both exim (compiled wtih openssl) as Postfix were vulnerable if ssl encryption was used.
    • Were the Yahoo! POP and SMTP servers also vulnerable?

      Yes. In most cases SSL for a sites services all come from a common service leveraging the same certificate. If one is vulnerable they all are. But they all get fixed with the same fix although on a large site there will be multiple servers to update. When you roll in load balancers and other network front end equipment it gets s little more complicated. That's why the SANS Institute is recommending companies post status information on their sites although I've not seen anyone doing it.

      Short of sites actually giving a real status id like to see the CNET list expanded from 100 sites to several hundred or even a thousand of the top sites.
    • Next question: How common is it for web sites to use SSL termination?

      SSL termination appears to be a mitigating factor for any exploits using the Heartbleed vulnerability:
      "Fortunately many large consumer sites are saved by their conservative choice of SSL/TLS termination equipment and software."

      And an example of a vendor with an SSL termination solution, the F5 BIG-IP Application Delivery Controller:

      It would appear that Yahoo! and other high-profile web sites have not taken advantage of SSL termination. Why not?
      Rabid Howler Monkey
  • Article: "new SSL certificates from their Certificate Authority (CA)"

    According to the Schneier On Security Blog regarding Heartbleed, the CA's are "completely clogged" with all the requests for new certificates:

    Not to mention revoking "half a million certificates".
    Rabid Howler Monkey
    • And this bug will keep on giving and giving

      Next up: Following a HUGE number of certificate revocations, certificate revocation lists (CRLs) will grow unmanageable large.

      Google Chrome does not support CRL nor OCSP. Their own "revocation sets" does not include all revoked certs.

      Firefox supports OCSP but not CRL.

      Internet Explorer supports OCSP with CRL as fallback.
  • SSL = Stupid Sloppy Losers

    Pitiful childlike programming from complete drooling morons.
    The entire useless moronic development team should be given the bill for the cleanup of their LOSER code.

    SSL = Slovenly stupid LOSERS
    Reality Bites
    • Reality bites

      Please forward some examples/references to/of your own coding skills.

      All is a . . .

      Fools fuzz

      induced scare by "security firms" 2 make themselves useful

      Been running the patched version for some days now.

      Only issue was that compiler switches of non gcc 4.7/4.8 and up compliance was implemented by defult
      in automake -march=i486 can result in portability issues use -mtune=(some cpu) instead
      • Since I don't pretend to be a programmer your comment is off target.

        When people pretend to be competent and produce bogus products under false pretenses IE: pretending to write security software when you are really writing garbage.... they need to pay the price.
        Reality Bites
        • That would have put Microsoft out of business...

          with all the holes they have been creating..
          • "That would have put Microsoft out of business..."

            The cold hard reality is that Microsoft Secure Development Lifecycle (SDL) would have PREVENTED this bug in any Microsoft software. SDL specifies a number of C practices and functions you are *not allowed* to use - much less in a security product.

            The hard reality is that Windows is NOT AFFECTED by this stupid bug, unless you infect it with Apache.

            The hard reality is that Windows has had FEWER vulnerabilities than both Linux kernel and OS X each and every year.

            The hard reality is that because of SDL - pointed to by security researchers as THE way to do it - Microsoft software consistently has much FEWER BUGS per line of code than anyone else.

            Jesse Pollard don't know how to spin this to become some kind of problem for Microsoft. So he just tries some old myths. He is just a stupid, sorry troll.
          • Why the

            Heck are they/MS continously "updating" their perfect software ???
          • Where is the claim of "perfect software"?

            If anything, SDL reinforces the mindset that security is a *process*. It recognizes the fact humans are not infallible and that errors and mistakes can, do and will happen.

            Recognizing that, SDL consists of a wide set of best-practices, mandatory processes, tools and methodologies. The stated goal is not to guarantee zero security bugs, but to "minimize the number and severity" of security bugs.

            SDL *would have* prevented this specific bug, simply because the C runtime function memcpy is on the "banned" list and a Microsoft developer cannot get through the security review process with the compiler flagging its usage.

            Can other mistakes slip through? Sure. But use of SDL has proven to limit the number and severity.
          • Mor patches in Linux than ever in Win7

            Now that I've been using Mint 16 exclusively for the past three months, I am accurately stating that I have received more update notifications than I ever (and I mean EVER) saw in Windows in a three month window. I get patch and update notifications to the many, various libraries that are collectively a part of "Linux" than I did in Win7.

            Linux is a perfect example of what honeymonster referred to in his follow up, which is that security is a process.