What an offline brute-force attack actually costs
An offline attack starts when a database of password hashes leaks. From that point the attacker is no longer talking to your server, so rate limits, account lockout and monitoring are all irrelevant: they generate candidate passwords locally, hash each one, and compare. The only things that matter are how many candidates exist, how fast the hardware can hash, and how expensive one hash is.
The candidate count is the keyspace, CL for a uniformly random password of length L over an alphabet of C symbols. The attacker does not have to search all of it — on average the target sits halfway through a random search order, so expected work is half the keyspace and the worst case is the whole thing. That factor of two is the only probabilistic content in the model; everything else is division.
The rate has two parts, and separating them is what makes this calculator honest. The raw rate is how many times per second one GPU can evaluate the underlying primitive — a single SHA-256 compression, say. The work factor is how many of those primitive operations one password guess consumes: 1 for an unsalted single-round hash, 600,000 for PBKDF2-HMAC-SHA256 at the iteration count OWASP currently recommends. Effective guess rate is the raw rate times the number of accelerators, divided by the work factor. Nothing else in password storage moves the number this far.
Entropy is the other half of the story and is computed the same way here as on the password entropy calculator. Bits tell you the size of the search; this page converts that into wall-clock time and GPU-hours.
The formula, and why logarithms do the work
Written directly, average time t = CL ÷ (2R). The trouble is that CL overflows any calculator once the password gets past about twenty characters: 9420 is 2.9 × 1039, and 94128 has 253 digits. So work in logarithms, which is also how any practitioner would do it on paper.
Take log base ten of both sides: log10t = L · log10C − log102 − log10R. Every term is small and readable. Multiply the length by the digits-per-character figure, subtract 0.301 for the halving, subtract the exponent of the guess rate, and the answer is the exponent of the time in seconds. Subtract a further 7.499 — that is log10 of 31,557,600 seconds in a Julian year — to get years.
Two structural facts fall out of that expression. First, each extra character adds log10C to the exponent, which means it multiplies the time by C. One more character on a 94-symbol password is a 94-fold increase; one more on a lowercase password is a 26-fold increase. Second, a change in the work factor and a change in the hardware are interchangeable: moving from one GPU to a thousand is exactly cancelled by moving from a raw hash to PBKDF2 at 1,000 iterations. Defender and attacker are pulling on the same lever from opposite ends, and the defender's end is cheap.
The model deliberately gives the attacker every advantage. It assumes perfect linear scaling across accelerators, no candidate-generation overhead, no memory bandwidth limit, and no time spent on anything but hashing. Real attacks fall short of that, so the times here are floors.
Worked example: twelve mixed-case alphanumeric characters
Take a randomly generated twelve-character password using lowercase, uppercase and digits, stored as an unsalted fast hash, attacked by a single GPU benchmarking at 10 GH/s on that hash.
- Alphabet. 26 + 26 + 10 = C = 62.
- Entropy. log262 = 5.9542 bits per character, so 12 × 5.9542 = 71.45 bits.
- Keyspace. 6212. Squaring your way up: 622 = 3,844; 624 = 14,776,336; 628 = 2.1834 × 1014; 6212 = 628 × 624 = 3.2263 × 1021.
- Halve it. Average candidates tried = 1.6131 × 1021.
- Divide by the rate. Work factor 1, one GPU, so R = 1010 guesses per second. 1.6131 × 1021 ÷ 1010 = 1.6131 × 1011 seconds.
- Convert to years. ÷ 31,557,600 = 5,112 years on average, 10,224 years worst case.
- Price the attack. 1.6131 × 1011 s ÷ 3,600 = 4.48 × 107 GPU-hours. At even a few cents an hour of rented compute that is millions of dollars, which is the number that actually decides whether an attack happens.
- Now change the storage. Move the same password behind PBKDF2-HMAC-SHA256 at 600,000 iterations. R falls to 1010 ÷ 600,000 = 16,667 guesses per second, and the average time becomes 5,112 × 600,000 = 3.07 × 109 years.
- Or change the password. Keep the fast hash and add two characters: 5,112 × 62 × 62 = 1.96 × 107 years.
Steps 8 and 9 are the whole security argument in two lines. The storage decision, made once by an engineer, bought a factor of 600,000. Two characters, asked of every user forever, bought a factor of 3,844.
How to read the answer without fooling yourself
Read the exponent, not the digits. A result of 7.5 × 104 years and one of 8.1 × 104 years are the same answer; a result of 104 and one of 109 are different answers. The inputs carry at best one significant figure of confidence — nobody knows the attacker's hardware — so anything that survives a factor-of-ten error in the rate is a robust conclusion, and anything that does not is a coin flip.
Set your bar against the useful life of the secret, not against eternity. A password protecting data that stops mattering in five years needs to survive five years of attack, not a million. That reframing is what makes the numbers actionable: a figure above about 103 years is beyond any realistic campaign against one account, a figure in hours or days means the password is already gone, and the interesting decisions live in between.
Then apply the correction the model cannot make. Everything on this page assumes a uniformly random password. Real attackers do not brute force; they run wordlists, previous breach corpora and rule sets that mutate them, and they crack the great majority of human-chosen passwords in a real dump long before an exhaustive search would reach them. If the password was invented rather than generated, the honest reading of this page is that the answer is an upper bound with no lower bound at all.
Finally, notice what the model refuses to reward. Adding symbol characters moves C from 62 to 94, a factor of 1.5 per character. Adding one character multiplies by 62. Switching the hash multiplies by up to a million. Composition rules are the weakest of the three levers, and NIST SP 800-63B advises against them for exactly that reason — a point developed further in the password entropy calculator.
Average crack time by length and storage scheme
| Length | Entropy | Keyspace | Fast unsalted hash | PBKDF2, 600,000 iterations |
|---|---|---|---|---|
| 6 | 35.7 bits | 5.68 × 10¹⁰ | 2.8 seconds | 20 days |
| 8 | 47.6 bits | 2.18 × 10¹⁴ | 3.0 hours | 208 years |
| 10 | 59.5 bits | 8.39 × 10¹⁷ | 1.3 years | 7.98 × 10⁵ years |
| 12 | 71.5 bits | 3.23 × 10²¹ | 5,112 years | 3.07 × 10⁹ years |
| 14 | 83.4 bits | 1.24 × 10²⁵ | 1.96 × 10⁷ years | 1.18 × 10¹³ years |
| 16 | 95.3 bits | 4.77 × 10²⁸ | 7.55 × 10¹⁰ years | 4.53 × 10¹⁶ years |
The two columns differ by a constant factor of 600,000 at every length, because the work factor divides the rate and nothing else. That constant is a storage decision, not a password decision.
Where the work factors come from
The bcrypt options come from the algorithm's own definition: the cost parameter is an exponent, so cost 10 runs 210 = 1,024 iterations of the key schedule and cost 12 runs 4,096. The PBKDF2 options are the iteration counts in the OWASP Password Storage Cheat Sheet — 600,000 for PBKDF2-HMAC-SHA256 and 210,000 for PBKDF2-HMAC-SHA512. Treating those iteration counts as a straight divisor on the guess rate is exact for PBKDF2, whose cost really is a repeated hash. It is conservative for bcrypt, scrypt and Argon2, because those algorithms also consume memory and defeat the massive parallelism that makes GPUs fast, so measured GPU throughput against them falls further than the iteration count alone predicts. Argon2id, defined in RFC 9106, is parameterised by memory as well as time, and the memory parameter is the one this simple model cannot represent.
Assumptions and limits worth stating out loud
- It assumes a uniformly random password. Anything a person invented is found by dictionary and rule-based attacks that never touch the full keyspace.
- It assumes the attacker knows the length and alphabet. If they must also search shorter lengths the total is only about C/(C−1) times larger, so the secrecy of your policy is worth almost nothing.
- It assumes perfect parallel scaling. Real clusters lose throughput to candidate generation, PCIe bandwidth and thermal limits, so the times shown are floors.
- It assumes one hash rate for the whole campaign. Hardware improves; a figure that looks safe for a decade at today's rates may not be at the end of it.
- It ignores salts, and that is correct. A unique salt stops one search covering many accounts, but it does not slow a targeted search of one account at all. Only the work factor does that.
- It ignores everything except guessing. Phishing, credential stuffing, keyloggers and password reuse are unaffected by any number on this page.
- It reports averages. The worst case is twice the figure shown, and an unlucky defender can be found in the first minute of a search that averages centuries.
Related calculations and what to do with the answer
If you are choosing a password policy, run this page backwards. Fix the storage scheme first, because it sets the work factor and therefore the guess rate. Decide how long the secret must hold — the life of the data, not eternity. Then read off the length that clears that horizon with a factor of a thousand to spare, so a surprise in the attacker's hardware does not invalidate the decision.
If you are writing a pentest report, quote three numbers rather than one: the effective guess rate you assumed, the entropy of the password class, and the resulting GPU-hours. GPU-hours convert directly into rented-compute cost, and a cost figure is the only form of this result that a risk register can consume — feed it into an exposure model such as the annualised loss expectancy calculator, or alongside a severity rating from the CVSS base score calculator.
For raw cryptographic keys rather than passwords, the work factor disappears and the arithmetic simplifies to keyspace over rate, which is the case handled by the brute-force key search time calculator. And when the question is a collision rather than a preimage — two inputs sharing a hash, not one input matching a target — the birthday bound halves the effective bit strength and the numbers change completely; that is the hash collision probability calculator.
One last framing that survives every uncertainty in the inputs. A password with 60 bits of entropy behind Argon2 is stronger in practice than one with 80 bits behind unsalted MD5, because the storage decision moves the guess rate by more orders of magnitude than any plausible password policy moves the keyspace. If you can change only one thing, change the hash.
Key terms
- Offline attack
- Guessing against a stolen hash on the attacker's own hardware, where rate limits and lockouts do not apply.
- Work factor
- Primitive operations consumed per password guess. It divides the attacker's raw hash rate and is the defender's strongest lever.
- Salt
- A unique per-password value mixed into the hash. It prevents precomputation and shared work across accounts, but does not slow a targeted attack on one password.
- Rule-based attack
- A wordlist plus transformation rules — capitalise, append digits, substitute characters — that reproduces the patterns people use, and finds most human-chosen passwords far faster than exhaustive search.
- GPU-hour
- One accelerator running for one hour. The natural cost unit for an attack, because it converts directly into a rental price.