Search code examples
encryptionhashbcryptverification

Why is BCrypt specifically effective against rainbow tables?


If somebody has the encryption functions from BCrypt, and encrypts a dictionary of passwords and store them on a cd. Gets access to the hashed passwords in the database, shouldn't they be able to?

I hope the answer is no. If so, why not?


Solution

  • Bcrypt, like other PBKDF functions, includes salting and stretching. Salting means that it adds some extra random data with the password. The salt is public. So, for instance, if my salt is "f588d29a" and my password is "password" the thing I'm actually going to hash is "f588d29apassword" (this is not precisely how bcrypt does it, but it is equivalent).

    After salting, you'll hash (more in a second), and the output will be: "f588d29a,hash". So the salt and hash are known to everyone. But now your rainbow table that includes "password" isn't any use. You need "f588d29apassword" and also "aaaaaaaapassword" and also "aaaaaaabpassword" and also... a lot of passwords hashed. So that dramatically increases the amount of time and space you need. And longer salts can make this arbitrarily hard on the attacker for very little cost to the defender. This is the part that makes rainbow tables basically useless. Even if I find multiple people with the same password, their hashes will be different so my table doesn't help.

    The second half of bcrypt (and other PBKDFs) is stretching, which means that performing the hash function is time intensive. We're talking tens of milliseconds usually, so it's not a big deal to humans or to one hash, but it makes password guessing much more expensive.