BCrypt Tables for 6 digit numbers 000000-999999

Question

This is an example of a bcrypt project I am working on. 2a and 04 are always used and the password is a 6 digit number from 000000 to 999999

Using 2a and 4 rounds is there a hash table or calculator out there somewhere that shows what the 6 digit number (password) is in this example?

$2a$04$lzzo9IuiAWyIs2H4NI4w1.KDxgxgUi2h34k9rDaMP/PjEv/WktiMm

Answer 1

What you're looking for, in theory, is a thing called a "rainbow table", a lookup table of hashes to their original outputs. There are quite a few of them online (and they tend to be huge, containing far more than the mere million entries for "000000" to "999999"). They're most common for simple hashes (MD5, SHA1, etc.).

Unfortunately for you, bcrypt requires the use of a very standard technique for defeating rainbow tables: a salt that is combined with the password before hashing, meaning the range of passwords you need to check is essentially many orders of magnitude larger than the simple million values you're checking for.

Bcrypt actually requires a salt, so there's definitely one in there. I believe that in your example it is the lzzo9IuiAWyIs2H4NI4w1. part (the first 22 base64-encoded characters following the third $, as per Wikipedia's description of the algorithm). The salt has to be stored in plain text, but it means that any rainbow table created without using that specific salt is useless for cracking the output (and no pre-computed table will use that specific random salt).

Somebody could reuse a single salt (with at least some bcrypt implementations, this is possible) but salts are supposed to be generated uniquely for each password. Check whether the first part of the hashes (following the last $) that you want to reverse is different for each value. In any case, the existence of salts at all means a pre-generated rainbow table isn't going to help.

On the other hand, a million entries is a pretty small search space. Bcrypt is a somewhat old password hashing algorithm (notably, it lacks the tunable memory cost parameter that newer functions have, although most people don't have easy access to the hardware that can brute force it most quickly). For simply using a commodity CPU, the difficulty of brute-forcing depends on the "cost" or "work factor" parameter. In your example, this is 04 (the number between the second and third $), which is low by modern standards. You can certainly brute-force any given 6-digit password in under a day (worst-case, that requires just under 12 hashes per second, which should be easy at cost 4). If they aren't using unique salts, this is equivalent to building your own rainbow table and allows reversing all the hashes.

Building a rainbow table just consists of hashing a bunch of inputs (in this case, the full million possibilities), preserving the password < > hash mapping, and sorting by the hash outputs. They can take a while to compute, depending on how slow the hash function is (for a "cost" of 4, pretty quick), how much you can parallelize it (if you have a multi-core machine, each core can work on a different set of passwords; modern CPU caches have no problem with the memory cost of bcrypt), and how many entries you're trying (some rainbow tables have a billion entries; a million is nothing). They also require storage space, but for one table with only a million entries it should take less than 100 MB of storage.