How to safely migrate to bcrypt?

If you are not already using a CPU-intensive hash algorithm to store passwords, you should be ashamed. Read this post to purge your sins.

As a security researcher, I have seen many ways in which passwords are stored. Therefore, I am no longer shocked when I still encounter plaintext or MD5 hashed passwords. It is unfortunate that some people are still not on board with the dangers of this, or do not understand the importance of moving away from it immediately. What’s really a shame is when I encounter data of which only a certain part is correctly hashed. This means that someone has realized the importance of this and has even made the effort to apply a new algorithm, but has not fully migrated it. That is why I felt it necessary to make this post, in the hope of making people aware of this danger.

A screenshot of the leaked 500px.com database, containing both MD5 and bcrypt hashes. They almost did it right.

How can it go wrong?

What I see often is data of which different passwords are hashed in different ways. This indicates they moved on to a better hashing algorithm, but are only enforcing it since that day. Anyone who registers from then on, will make use of the new algorithm. When better implemented, some even recalculates a new hash whenever someone logs in again. By using 2 different algorithms, a password is checked in both ways when someone logs in. This all sounds pretty fine, but this still leaves all the old data vulnerable. Whenever someone with bad intentions gets access to this data, a part will still be unsafely hashed.

How can I fix this?

If you recognize this situation, it is not too late to improve your life. You should replace the old algorithm with a safe one everywhere, as in the bad examples. However, what you need to do differently is migrating all your gathered passwords as well. Some may say that this is impossible without access to the original password, but that is not a problem. You can hash the old hash with the new algorithm, and replace it with the correct hash whenever a person logs in again. I will demonstrate it with a small example. Let’s say your migrating from MD5 to bcrypt.

1. You replace all MD5 passwords in your database with a bcrypt hash of them. This is the important step that gets skipped a lot.
2. A user attempts to log in.
3. The password entered is verified against the stored bcrypt password.
4. If the password matches, the user is granted access.
5. If the password does not match, it is hashed with MD5 before we try to verify it again. This may be the first time a user logs in after the migration.
6. If the password matches, the hash in the database is replaced with a bcrypt hash of the original password and the user is granted access.
7. If it does not match, the password is invalid.

What algorithm do I migrate to?

The weakness of many hashing algorithms (such as the MD and SHA-families) is their speed. They are not designed for password hashing and are made as efficient as possible. Of course, hackers can take advantage of that efficiency. Many algorithms can also be optimized to run on a GPU, allowing hackers to attempt billions of passwords per second using a standard home computer.

Specific password-hashing algorithms have been created that run CPU, or even memory-intensive operations. This increases the cracking time for hackers by a multiple of thousands of times. I won’t go into detail about which algorithm is best to use, but the best known are bcrypt and scrypt. There are many articles about the pros and cons of each, but at least they are both a safe solution.

If you still have passwords stored somewhere in an insecure manner, now is the time to address this problem. If you already apply a secure algorithm everywhere, now is probably the time to increase the cost factor. That also means recalculating hashes when a user logs in again.