Goals

• Understand how bcrypt do ‘salting’

• Especially, how it can do salting without storing salt at extra columns dedicated for ‘salt’

Basics

Rainbow Table Attack

Rainbow Table is a table with various possible passwords and it’s hashes. When attacker somehow got the hased password table, it can use Rainbow Table to reverse a hash back into its original password.

Salting

Definition

If random value (the “salt”) is added to each password before hashing, their hashes will be completely different from the hashes without salt.

Effect

When all hashes are ‘salted’, attacker can’t use a single rainbow table. It needs a rainbow table with all possible salts for each possible password.

How Bcrypt stores salt and hash

Bcrypt does add salt before hashing, but where does it go? Since salt is a random value for each hashes, it needs to be saved for each hash value somewhere.

The answer is… it’s embedded in the hash value!(…!?!)

$2b$12$<salt><hash>

This is the format of the Bcrypt hash result:

• 2b: The bcrypt version identifier.

• 12: The cost factor (indicating how many rounds of hashing to perform, making brute-force attacks harder).

• <salt>: A 16-character base64-encoded string representing the randomly generated salt.

• <hash>: The final hashed password, also base64-encoded.

So, salt is just stored together with hash, so that it doesn’t need additional column for salt value!

By doing so, it can be simply applied to whatever the database is. How smart!