This is more of a theoretical rather than a practical question. To give a bit of background, the discussion at work has come up with what to set our password complexity to and what the logistics would be if a DB was stolen (for this situation lets say I have 1000 passwords in md5).

I've done the following math (no idea if I'm correct)

hashrate (H/s)                  
GTX 1080ti  43750000000                 

Size    length              keyspace Total(comb)        build time in days
8       lower               26       2.08827E+11        5.52453E-05
10      lower+upper         52       1.44555E+17        38.24209152
11      lower+upper+numeric 62       5.20366E+19        13766.2859

8 gpu cards 3.5E+11                 

Size    length  keyspace        Total           build time in days
8       lower               26  2.08827E+11     6.90566E-06
10      lower+upper         52  1.44555E+17     4.78026144
11      lower+upper+numeric 62  5.20366E+19     1720.785737

Since hashcat is just brute forcing I can assume that the build time would be the same as my crack time? How can I calculate how long it would take rainbow tables to crack the DB

  • MD5? you might as well not even bother. use a PBKDF or stay home.
    – dandavis
    Jun 1, 2018 at 19:51
  • @dandavis Again this is more about theoretical password cracking, not physical application. There are many ways to implement properly encrypted passwords. Jun 1, 2018 at 20:07
  • 1
    no, there is no way to properly encrypt passwords, that's just it, you need to derive them....
    – dandavis
    Jun 1, 2018 at 20:46
  • And how does this relate to my original question? Jun 1, 2018 at 21:07
  • The question itself is at fault. Why would you generate your own rainbow table for md5 when people have already done it? Just download the thing. project-rainbowcrack.com/table.htm Jun 2, 2018 at 1:42

2 Answers 2


I can't speak to the precise time needed to generate a rainbow table. But I can address your question more generally.


  • it's a single hash
  • it's an unsalted hash format
  • the password is known to be of sufficiently limited complexity and length, such that an equivalent rainbow table is both feasible and available
  • the password is of sufficient time-dependent value to the attacker ("we gotta crack this hash in 20 minutes or the bad guy gets away" scenarios)

... then a rainbow table can be of specific limited value (and even then, it's a gamble).

Otherwise, as soon as either A) you have more than one password to crack, or B) the complexity of the password is not known, the usefulness of rainbow tables drops off rapidly. With a rainbow table, you can only look up one hash at a time, and that lookup takes a significant amount of time. In that amount of time, you can test trillions of potential passwords against millions of hashes with hashcat.

The modern, efficient option is to build an attack plan with hashcat that supplants (and goes far beyond) the equivalent rainbow table - because most unsalted hashes are so fast that you're much better off just using hashcat. Most passwords will fall to an attack using straight dictionaries, dict+rules, combinator/hybrid attacks, masks, etc.

tl;dr: hashcat is much more efficient for most of the common use cases.

  • 2
    Ah okay, you answered the question I should have asked. Thanks Jun 1, 2018 at 22:58

You're comparing apples to oranges. You can't compare these.

If there are rainbow tables for the length of password you're password happens to be, it should be faster.

but hashcat will run through a ton of optimizations that might be faster depending on the actual password.

If your password is dogwalkscat, and you happen to have rainbow tables for 11 character passwords, you'll have a hit. But if hashcat has dogwalkscat in the dictionary, it will try all dictionary words guess the password very quickly... most likely faster.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .