It depends on three things: its length, the characters it can contain and how the breached service stored it. This table combines them, and you can switch the scenario.
Updated . 6 min read.
The table
Average time an attacker would need to find a randomly generated password, by its length and the characters it can contain. Switch the scenario to see everything move.
Red: under an hour. Amber: under a year. Green: a year or more. “More than 100 million years” means impossible in practice.
Length
Numbers only
Lowercase
Upper and lowercase
Letters and numbers
Letters, numbers and symbols
6
instantly
instantly
instantly
1 second
9 seconds
8
instantly
10 seconds
44 minutes
2 hours
1 day
10
instantly
1 hour
2 months
1 year
51 years
12
50 seconds
1 month
6 centuries
44 centuries
5,277 centuries
14
1 hour
1 century
16,744 centuries
179,555 centuries
more than 100 million years
16
5 days
690 centuries
more than 100 million years
more than 100 million years
more than 100 million years
18
1 year
467,074 centuries
more than 100 million years
more than 100 million years
more than 100 million years
20
1 century
more than 100 million years
more than 100 million years
more than 100 million years
more than 100 million years
Passphrases
For passphrases generated at random from a 7,776-word list, assuming the attacker knows the list and the number of words (the worst case):
Same scenario as the table above.
Words
Average time
3
23 seconds
4
2 days
5
45 years
6
3,502 centuries
7
more than 100 million years
8
more than 100 million years
A random 16-character password is green in all four scenarios.
The attacker tries passwords on the login page. It is slow because every attempt goes over the network, and most services block or slow down after a few failures, so in reality it is even slower. Only very common passwords fall here.
Slow hash: 100,000 guesses per second
Someone has stolen the database, but the service stored passwords with an algorithm designed to be slow, such as bcrypt, scrypt or Argon2. Each guess costs a lot of computation. This is what any well-built service should do.
Fast hash on one graphics card: 10 billion per second
The stolen database used a fast hash (plain SHA-1 or SHA-256). A single high-end graphics card tests billions per second. This is the scenario our generator and checker use: realistic and slightly pessimistic.
Fast hash on 12 graphics cards: a trillion per second
A dedicated rig with several graphics cards attacking very fast hashes like MD5 or NTLM (the Windows one). Some older services still store passwords this way.
How it is calculated
If a password has L characters and each is chosen at random from N possible ones, there are NL combinations. On average, the attacker succeeds after trying half of them:
average time = NL ÷ 2 ÷ guesses per second
For example, 12 characters of letters and numbers: 6212 ≈ 3.2 × 1021 combinations. At 10 billion per second, half of them takes 1.6 × 1011 seconds, about 5,100 years.
In the table that cell says 44 centuries, a bit less, because when several character types are involved we only count passwords containing at least one of each, as our generator does. It is a small adjustment, but we prefer not to round in our favor. The same calculation expressed in bits is in the guide to password entropy.
What the table does not tell you
It only applies to random passwords. A password chosen by a person is not attacked by trying every combination, but by starting with words, names, dates and leaked passwords. Chelsea1985! has 12 characters of all four types and, according to the table, should hold for centuries; in reality it falls in minutes. For those, use the checker, which looks for those patterns.
A leaked password is cracked instantly, whatever it measures, because it is already on the lists that get tried first.
Hardware keeps improving. Graphics cards get faster every few years, so leave some margin. With 16 random characters you have plenty.
Frequently asked questions
How long does it take to crack an 8-character password?
If it is random and uses all four character types, about a day on average with one graphics card against a fast hash, and a few minutes with a multi-card rig against MD5 or NTLM. If it is a word with a number at the end, seconds. Eight characters is no longer enough.
What about 12 characters?
Random with every character type, about 78 bits: thousands of centuries even against a fast hash. That is a reasonable minimum if you also use two-factor authentication. If you chose it yourself, the real time depends on how predictable it is, not on the table.
Why do other tables give different times?
Because they assume a different attack speed. The ones shared on social media usually assume a slow hash like bcrypt, so their times come out much longer. Offensive security tables assume fast hashes and come out shorter. That is why you can choose the scenario here: a figure only means something next to its assumption.
Is the time in the table the maximum or the average?
The average: half of all combinations. With luck an attacker can hit it sooner; with bad luck it takes twice as long.