What should a website operator do about the Heartbleed OpenSSL exploit? mainly talks about what people running websites should do about Heartbleed.

What should end-users of websites be doing?

Do they need to change their passwords?

If so, should they be logging into websites and changing passwords immediately? Or should they wait until their websites have changed their sites to be more secure, and then change their passwords?

(I'm https://security.stackexchange.com/users/8335/andrew-grimm , but posting as a guest, because I'm not already logged in, wordpress openID isn't working, and I don't want to use a password just after Heartbleed has been announced)

  • 4
    Have a look at heartbleed.com and the "What is leaked secondary key material and how to recover?" section - long story short, yes end users should definitely be confirming with their service providers that things are patched up and then changing their passwords. They should also be updating software - things like web browsers and email managers - as soon as they can (I haven't been able to find a good list of affected/unaffected end user sw yet or I'd post an answer. I saw someone mention android chrome was not vulnerable, which make me wonder if desktop IS)... Apr 8, 2014 at 4:57
  • @ChrisO'Kelly Update Browsers, because of the update of the certificates that will occur now? thanks for acclarification. maybe you can phrase your comment to an answer? Apr 8, 2014 at 5:46
  • Most of it is just hearsay that I have gathered from other people's answers and comments here and on other sites, I am not really "in-the-know", so I wouldn't want to present myself as answering the question. Browsers I had been worried about but it turns out I was wrong (see, that's why it's not an answer: see here reddit.com/r/netsec/comments/22gaar/… ) - I very much doubt that CA's have been compromised so root CA lists in browsers SHOULD still be fine aswell. (Again, not an expert) Apr 8, 2014 at 6:00

2 Answers 2


End users should just wait until their sysadmins contact them with further instructions. At some point, after your sysadmins have patched vulnerable systems, you may have to:

  • Change passwords
  • Login again (because all session keys and cookies need to be invalidated)
  • Help senior management evaluate the actual content handled by the vulnerable servers that could have been leaked, and react accordingly.

I expect that the massive key/certificate changes about to occur will go un-noticed by most users, as those take place server-side. As to the client-side root CA trusted certs, I expect that the private key counterparts will reside on air-gapped systems, and so won't have been vulnerable to this exploit. Any updates to certificate stores that are necessary will probably just occur transparently in background updates.

I summarized the bullet points above from heartbleed.com (emphasis mine):

What is leaked primary key material and how to recover?

These are the crown jewels, the encryption keys themselves. Leaked secret keys allows the attacker to decrypt any past and future traffic to the protected services and to impersonate the service at will. Any protection given by the encryption and the signatures in the X.509 certificates can be bypassed. Recovery from this leak requires patching the vulnerability, revocation of the compromised keys and reissuing and redistributing new keys. Even doing all this will still leave any traffic intercepted by the attacker in the past still vulnerable to decryption. All this has to be done by the owners of the services.

What is leaked secondary key material and how to recover?

These are for example the user credentials (user names and passwords) used in the vulnerable services. Recovery from this leaks requires owners of the service first to restore trust to the service according to steps described above. After this users can start changing their passwords and possible encryption keys according to the instructions from the owners of the services that have been compromised. All session keys and session cookies should be invalided and considered compromised.

What is leaked protected content and how to recover?

This is the actual content handled by the vulnerable services. It may be personal or financial details, private communication such as emails or instant messages, documents or anything seen worth protecting by encryption. Only owners of the services will be able to estimate the likelihood what has been leaked and they should notify their users accordingly. Most important thing is to restore trust to the primary and secondary key material as described above. Only this enables safe use of the compromised services in the future.

What is leaked collateral and how to recover?

Leaked collateral are other details that have been exposed to the attacker in the leaked memory content. These may contain technical details such as memory addresses and security measures such as canaries used to protect against overflow attacks. These have only contemporary value and will lose their value to the attacker when OpenSSL has been upgraded to a fixed version.

  • 2
    One thing to note: Tor relays may have been compromised :) Apr 8, 2014 at 14:07
  • 7
    Torproject has commented. Summary: Tor Browser shouldn't be affected, since it uses libnss rather than openssl. Tor relays and bridges could maybe be made to leak their medium-term onion keys (rotated once a week), or their long-term relay identity keys. Tor hidden services might leak their long-term hidden service identity keys to their guard relays. Tor directory authorities might leak their medium-term authority signing keys. If you use Tor, read the entire blog post now! Apr 8, 2014 at 14:31
  • 2
    @scuzzy-delta - What about for general services that most people use (i.e. Google, GitHub, Steam, Dropbox, etc.)? I've just been going through and checking each site and then changing my password if it's not affected. Is this a good course of action or should I do something else?
    – Nathan2055
    Apr 8, 2014 at 19:45
  • 3
    An extra note: some distributions (e.g. Ubuntu) have not upgraded to 1.0.1g, but instead backported the fix to a previous version. Same effect, but it means that checking the local OpenSSL version is not a reliable test for presence of the vulnerability. Apr 8, 2014 at 19:48
  • 1
    Change passwords after your sysadmins have patched AND changed certificate to a new one. Patching alone is not sufficient, as the eavesdropper would still hold the private key.
    – Agent_L
    Apr 9, 2014 at 13:45

@scuzzy-delta has a great overview above, but I thought I might answer a little more preventatively.

General Security for Online Services One of the best ways to avoid harm from bugs like this is by using a password manager like KeePass (KeePassx for Mac and Linux). Password managers can generate and store completely unique passwords for all the websites you use. This avoids the numerous security risks that occur when you use the same password or a derivative of the same password for multiple services.

RE: Changing Passwords Changing passwords is good and all, but if the service or website you are using is still vulnerable to Heartbleed the new password could also be compromised. For the most part though I think services are patching the Bug or announcing they weren't affected.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .