Products & Services
I notice that F-Secure Key is still using OpenSSL libraries 1.0.1e. No one should send anything to your cloud or even log in to your service without that beeing fixed. Right?
Will be good if someone from F-Secure Key team answered here....
- I think that.. maybe version of Key with "new" version of Open SSL library comes to avalaible soon (mobile versions already updated ?!)...
- But most related... that F-Secure Key servers already fixed practically in first days (how it can to read on F-Secure webpage about current vulnerability) - and it's mean common risk about that vulnerability - fixed;
All other variants probably hard to realization or just without any variants (like if Key use just strong "known" servers and that servers are patched/fixed/safe); Also any user data strong stay on user device.
But about almost picture... need certainly known about library functions in Key. And answer from F-Secure team about your question will be nice.
And certainly need be care about websites/web-services.... which possibly to visit and which can be still vulnerable.
I've been reading a bit more about how F-Secure Key is working. It all looks very good. So good in fact that perhaps Heartbleed leaking everything you've got won't matter.
All passwords are encrypted with with a key derived from your own master password. The derived key and master password are never stored or transmitted anywhere except for local memory.
Two questions remain (that I can think of):
Is it ok to share your encypted passwords to anyone exploiting the Heartbleed bug?
Do you log in to an online service whith your password and thereby exposing it through the Heartbleed bug?
Unless I've seriously misunderstood something, it works like this:
Your Key data is locally encrypted and protected. But if you use Key to log in to an online service, Key has to decrypt the data with the help of your master password, in order to send your online service credentials in "plain text", but protected by the online service SSL certificate. So your data will be vulnerable if you log in to an online service that is not yet patched for the Heartbleed bug.
In other words: it depends on the online service you use. If this is correct, I'm surprised that F-Secure hasn't described this more clearly.
Here's a guide I followed myself to see what major online services are patched and require user action:
And if you decide to change passwords for an online service, make sure it's patched first.
About your 1st question: Probably not, but why share even encrypted passwords to anyone?
The purpose with Key is to only have it locally and not shared on any server. And for the premium synchronization feature the data is sent encrypted between devices, so even F-secure can't see what is sent.
On the Key product page it says:
"F-Secure Key users data is protected despite of the Heartbleed vulnerability. With Key, your passwords are safe."
My question to that statement is:
Even if you use Key to log in to an online service that is not yet patched?
The heartbleed bug affects the remote server.
It allows people to steal the servers memory contents in small chunks.
I read on F-Secures web page that they have prevented this from happening on their servers.
If you log in to a vulnerable site (using Key or by typing the password manually / doesn't matter), then:
1) your password is sent to the server using OpenSSL protection
2) your password will be stored in the servers memory for a short time
3) someone may be reading the servers memory in small chunks at the same time (unlikely)
2) someone could have stolen the servers private SSL (https) decryption key from its memory during the last 2 years
3) and would somehow manage to capture your protected communication with the server
4) and would thus be able to decrypt your password
Perhaps other more serious risks relating to a compromised server.
Won't have time to start thinking on this, but anyway, it is the server accepting connections that is broken. This compromises the password you use on that compromised server.
Check what http://blog.meldium.com/home/2014/4/10/testing-for-reverse-heartbleed has to say about client vulnerability.
Thank you for an interesting link.
If I had registered at a malicious server then I'd have other problems besides reverse Heartbleed really, but yes, your point may be relevant and must be considered. I am no expert of OpenSSL (yet?) so this information was new.
Of course we could run encrypted ramdisks as swap...
In the blog about reverse Heartbleed they mention "certificate pinning" as one way to detect and block it. In case anyone is wondering what that is, it's part of Microsofts EMET (an exploit blocker + certificate trust feature) aimed for more advanced users.
The certificate trust feature only works with IE and can be a little difficult to set up without good help:
http://www.wilderssecurity.com/attachments/untitled1-png.241780/ Screenshots with instructions
I've written about EMET and some other security products that complement F-Secure here (more info in the "Spoilers"):
PS. Ram and swap made me think of on old thread regarding hibernate and pagefile security:
How I can to understand - today/yesterday - comes new version of Key for Windows, which available to download from webpage about F-Secure Key. Probably with fixed "static" library about OpenSSL.
no of course not.
if a server is heartbleeding, they can steel that password and the information you have sent them.
However, if you use a good password key-program than your password will be different on other servers you use and thus your password leaking does not result in more problems.