1

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

hashrate(H/s)-https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40  
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

user31925
  • 71
  • 2
user2762594
  • 17
  • 1
  • 1
  • 4

2 Answers2

3

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

If:

  • 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.

Royce Williams
  • 9,128
  • 1
  • 31
  • 55
1

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.

Jonathan
  • 2,288
  • 13
  • 16