It seems there are a few things floating around, a few misconceptions and misunderstanding about the problem. First of all, when you access – a banking site for example, you usually use TLS (“Transport Layer Security”) or the older version SSL (“Secure Socket Layer”). This means that your data from and to your bank is encrypted in transit. The server where your banking site sits on is decrypting your data first, processes your request, but before the data is sent back out, it is encrypted again. Your browser is doing something similar. Received data gets decrypted first, displayed and when your requests are sent off, before they leave your computer, they are encrypted. This is called transport encryption – there is another way of encryption, but we come back to that later.
This encryption method works that each side has two types of digital keys – one is publicly known, the other is secret, and only the endpoints (ie. the “browser” and the “banking server”) know it, this key does not leave the system. With specifically crafted mathematical algorithms it is possible that one side can encrypt data with the public key of the other side, but only the secret key of the other side can decrypt it again – and vice versa. This is also called “Assymetric Cryptography” or also “Public-Key Cryptography”. If you are interested in this, you can find more on that here.
OpenSSL is providing functions to encrypt and decrypt data and is used mostly on the Linux/Unix side. So this Heartbleed Bug is a particular feature of this protocol, what has been added in the last two years. Unfortuntaly they discovered, that it has a major weakness, in that when you craft a specific request, it gives you back that secret key we spoke about before, so its “heart is bleeding”.
What does this mean?
If a server is vulnerable to this, an adversary can use this to get the secret key. That secret key your data in transit is encrypted with. This is the official statement, but there is a little but more to that, and it is a bit tricky to do anything with those secret keys as well.
That somebody can seriously misuse that hey would need to sit between your browser and your banking site, so that they can gather all the traffic. As they have the secret key of the server and all the encrypted traffic they are in a position to decrypt your data what you sent to the banking site. But the internet was not build in one day, neither encryption and there is a feature within SSL which generates a session-key for each session which encrypts the data even further. The design of this is built on the assumption, that you have an adversary on the wire/you have somebody listening in or generally it doesn’t trust the means of transport (ie. copper or fibre). This feature is called Forward-Secrecy. So to summarize, when the server has implemented and enabled this particular feature within its SSL stack and an adversary having the secret key, they still cannot decrypt your data. Unfortunately we do not live in an ideal world. And also unfortunately this feature Forward-Secrecy is not enabled on all the servers on the internet.
So what needs doing are
- All websites/servers need to fix this weakness by patching their systems, applying software upgrades.
- They also need to generate a new set of secret and public keys on their server.
What about my password now? Do I need to change it?
Everytime you login to a site, your password travels across this encrypted tunnel. The server receives it, has it in “plain text”, ie. the way you typed it, it should ideally hash it and check it with your stored credentials, which are also hashed. A “hash” is a different representation of your password, what cannot be undone, ie. “converted back”, ie. it is a “one-way function”. Encryption on the other side is both-ways, it can be decrypted again. There is only “brute-force” for converting a hash back to its original form. So a fairly common password hash is unfortunately “286755fad04869ca523320acce0dc6a4″ – please use the search engine of your choice and you can find out which plain-text password that would be. SSL is not involved in storing your password or generally when “data are at rest”.
To bring this to an end, changing your passwords is pointless unless your website has not done due diligency yet, ie. patched the weakness and regenerated a new set of keys.If they also have done their due diligence and used Forward-Secrecy, but are vulnerable there is no need to panic still.
Yes, you should do change your password, but don’t use the same password everywhere. Better to be safe than sorry. Use a local password manager like KeePass or Password Safe, do not use your browser to store passwords and/or websites like LastPass (if you use this, all your passwords could be out there, that’s why it is important to have a local password manager, and not on the internet as a website).