Sticky Password and the Heartbleed bug

Post updated April 18, by Sticky Password CTO Pavel Krčma

Why your Sticky Password data was safe from Heartbleed.

Here’s a summary of answers to questions I’ve received on our forum and via email concerning the Heartbleed Bug:

Your passwords stored in the Sticky Password database are secure and have never been at risk because of the Heartbleed vulnerability.

Here’s why:

The Heartbleed Bug allows bad guys to siphon data (like user names and passwords) from servers that users log into. The Sticky Password Master Password, which is the only key to the database, is never sent over the Internet and neither is the hash.

The reason for this is that the Sticky Password backend server never accesses your database, so there is no need to transmit the Master Password.

So the bad guys are not able to get the critical data they would need to access the database.

Only you know your Master Password. The authentication that takes place when Sticky Password syncs or performs a backup to the cloud (Sticky Password uses Amazon cloud services for our backend services) involves only your StickyID (your email address) and your StickyPass – which is different to your Master Password. For syncing and backing up to the backend servers, only the encrypted database is sent over the Internet, so even if an attacker were lucky enough to catch the communication he wouldn’t be able access the encrypted data inside the DB.

Because of this, Sticky Password is not susceptible to the Heartbleed vulnerability.

Our website, was never vulnerable to Heartbleed, because we used the latest main release of OpenSSL – which did not contain the bug! The Heartbleed Bug was introduced in a minor fix later on.

Scroll down to test the Heartbleed status of sites you visit.

Sticky Password backend services are hosted on Amazon cloud services. Amazon applied the patch to their systems immediately when it was available. We promptly changed the private key to ensure that no one could try to exploit the vulnerability using the old key.

Visit our forum or leave any additional question in the comments below.


Original post April 9

With the breaking news of the Heartbleed bug, we are updating Sticky Password customers and users on how the bug may have impacted Sticky Password and providing information on the steps we’ve taken to protect our customers.

We have no indication of any impact on Sticky Password

While was not affected, some of our servers were running the vulnerable version of OpenSSL and we immediately installed the patch.

Your master password, logins, passwords, authentication and private data are safely encrypted in Sticky Password and therefore are not affected by heartbleed.

What is Heartbleed?

Heartbleed is a new vulnerability (‘crypto bug’) that is the result of a coding error in the Transport Layer Security (TLS) protocol. The 2-year old bug allows attackers to place requests for data on vulnerable website servers. Instead of rejecting the request, affected servers provide the attacker with whatever data is available at that moment in time. The data received is ‘pot luck’, which simply means that the attackers don’t know what they are getting until they actually get it. Only after analyzing the data do the bad guys know what they have. In this way, attackers are able to get passwords, authentication cookies and other sensitive data.

For more details, visit, which was created by Codenomicon who teamed with Google in revealing the vulnerability.

An update to the open source program OpenSSL that is used by an estimated 2/3 of active web sites on the Internet has been created and is rapidly being deployed by sites affected by the bug.

Test a site for heartbleed vulnerability:

  • https://

  • All good, seems fixed or unaffected!
  • Host (the site) does not respond.
  • Possibly Unsafe. This site seems to be vulnerable to the Heartbleed bug. Wait for the site to update before changing your password
  • Invalid URL (site name).

Change your important passwords now!

While this step is necessary and will go a long way to foiling attackers, in this case, updating servers is not a guarantee of security. The 2-year duration of the vulnerability (March 14, 2012 – April 7, 2014), and the fact that it isn’t possible to tell if a site has in fact been exploited, indicates that attackers may use information such as authentication credentials, private keys to digital certificates and other information that would provide unauthorized access to the site.

We strongly recommend changing your passwords on sites that are known to have been vulnerable – do so after they have updated their SSL certificates. Do this as soon as possible for your critical websites like banks and other sites dealing with finances and other highly sensitive information. As it is good practice to change your passwords periodically, we recommend gradually going through your password-protected websites and changing the passwords in the coming days.