# Mathematically, how long would it take to crack a bcrypt password hash?

So I'm currently using bcrypt to hash passwords with a randomly generated salt (as seen in the pip `bcrypt` module), with 12 rounds.

I have been looking around, but I cannot find a detailed and clear mathematical way to estimate how long it would take for a strong GPU (or even other methods of cracking) to crack my bcrypt hash.

I found this gist which descibes 8x Nvidia GTX 1080 Hashcat Benchmarks, but I can't seem to use the figures provided for bcrypt to apply to my implementation of the hashing algorithm.

Ok, so from the article you linked, we learn that the 8x Nvidia setup can calculate about 100 000 bcrypt hashes per second (H/s). The cost factor used for the bench mark is 5 - very low - if the comments are to be believed. For bcrypt, the number of rounds equals two to the power of the cost factor. So if yours is 12, your hash will be 212/25 = 27 = 128 times slower. So from 105 H/s you're down to 103 H/s.

Now all you need to know is that to crack a hash with n bits of entropy, on average you need to try 2n-1 times. So take a password consisting of 8 random lower case letters for instance. It has an entropy of n = log2(268) = 38 bits. To crack it you would need 238-1/1000 seconds = 4 years.

Note that the benchmark is from 2016. As time passes by, hardware gets faster. You will need to regularly reevaluate your cost factor to stay up to date.

• Also keep in mind that hashcat's benchmark mode represents ideal conditions - single hash, maximum attack throughput. Most real-world attacks on a single bcrypt may be slower relative to the benchmark for a given platform. Mar 23, 2018 at 3:21
• I'm a little bit confused by the password entropy part of this equation, maybe you can help me with the intuition part of this. Given a sufficiently complex password, is it correct that bcrypt reduces this entropy to the 128-bits of the bcrypt hash? Meaning, that regardless of password complexity, there is an upper worst case time to find a hash collision of 2^127 / 1000 seconds? Feb 4, 2019 at 1:07
• @swalog Yes, thats the worst case. But thats a bad worst case. The universe will have died the heat death before that. Feb 4, 2019 at 7:54

This is a common misconception about passwords. It depends on your definition of password. You have to first define what you mean by password, such as "8 alphanumeric characters". Once you define that, then we can calculate.

An "alphanumeric" is 26 upper case, 26 lower case, and 10 numeric characters, or 62 possible combinations.

To try all combinations of an 8 character password, that would be: 62 * 62 * 62 * 62 * 62 * 62 * 62 * 62

That's 218,000,000,000,000.

Divided this by 13094 (the number of hashes per second), and you get 16674820955 seconds, or 528 years.

The impracticality of trying all combinations leads to other strategies, such as instead choosing dictionary words or "Markov Chains" to test the sorts of passwords are likely to choose, instead of trying all random combinations. You can't mathematically calculate how fast this is because it's entirely subjective. It depends upon luck, what passwords the targets have chosen, and what passwords you've chosen to test. It's often something of the order of a 10% chance of cracking a password with a few hours of cracking, but again, that's subjective experience. Depending on whose password you are cracking and how you are cracking it, your experience will vary.

Anyway, the point is that this question has no answer. It's a misconception of how things work. And that's why you can't google the answer.

• If this question has no answer, what did you just write? Mar 23, 2018 at 12:47
• It can most definitely be estimated, and without any subjectivity. Anders did a quite fine job of doing that. Mar 23, 2018 at 14:02
• Where does the number of hashes per second come from? That's kind of the central question. Jun 19, 2020 at 10:54