See how long exhaustive search really takes against MD5, bcrypt, PBKDF2 or scrypt on measured GPU hashrates, and the password length it forces.
hashcat v6.2.6, optimised kernels, one GPU, as published by Chick3nman. GPU count scales linearly here; the one published 14-GPU run came in at 87 to 97 percent of linear, so this errs slightly in the attacker's favour.
| Algorithm | hashcat -m | RTX 4090 | RTX 5090 |
|---|---|---|---|
| NTLM (Windows) | 1000 | 288,500,000,000 | 340,100,000,000 |
| MD5 | 0 | 164,100,000,000 | 220,600,000,000 |
| SHA-1 | 100 | 50,638,700,000 | 70,245,100,000 |
| SHA-256 | 1400 | 21,975,500,000 | 28,353,300,000 |
| SHA-512 | 1700 | 7,483,400,000 | 10,048,600,000 |
| md5crypt (Unix MD5) | 500 | 61,283,800 | 87,367,800 |
| sha512crypt (Unix SHA-512) | 1800 | 1,179,600 | 1,479,800 |
| PBKDF2-HMAC-SHA256 | 10900 | 8,865,700 | 11,157,200 |
| PBKDF2-HMAC-SHA512 | 12100 | 3,120,900 | 4,245,400 |
| bcrypt | 3200 | 184,000 | 304,800 |
| scrypt | 8900 | 7,126 | 7,760 |
| Argon2id | — | Not benchmarked | Not benchmarked |
OWASP Password Storage Cheat Sheet, in its own order of preference. NIST SP 800-63B names no algorithm: it requires a salt of at least 32 bits and a cost factor raised over time.
| # | Algorithm | OWASP setting | Why it ranks there |
|---|---|---|---|
| 1 | Argon2id | m=19456 (19 MiB), t=2, p=1 | Memory-hard, so a GPU cannot hold thousands of copies at once — and that parallelism, not clock speed, is what a cracking rig is made of. |
| 2 | scrypt | N=2^17 (128 MiB), r=8, p=1 | Also memory-hard, and the fallback where an Argon2id implementation is not available. |
| 3 | bcrypt | Cost 10 or higher; 72-byte input limit | Legacy systems only. Its cost is CPU time, not memory, and it silently truncates past 72 bytes. |
| 4 | PBKDF2-HMAC-SHA256 | 600,000 iterations | Choose only where FIPS-140 compliance is required; it is the easiest of these to accelerate. |
| 5 | PBKDF2-HMAC-SHA512 | 220,000 iterations | Same FIPS-140 case, with a wider internal hash and a correspondingly lower iteration floor. |
Estimates cover exhaustive search only, using published single-GPU hashcat benchmarks. Real attacks try leaked passwords and dictionaries first, so a guessable password falls far sooner than any figure here.
You might also find these calculators useful
Guess resistance, crack time and NIST 800-63B rev 4 checks
Generate and verify SHA-256, MD5, SHA-1, SHA-512 and SHA-3 digests
See which AES, RSA, ECC and hash key sizes are equally strong.
Generate strong random passwords & memorable passphrases, with live strength
The honest answer depends far less on your password than on how the site storing it hashed the thing. The same twelve characters that fall in under a day behind MD5 hold for longer than the universe has existed behind bcrypt at cost 12. This calculator works from measured GPU hashrates rather than round numbers, so you can put a real figure on either case and see the minimum length a given configuration forces on a password policy.
Exhaustive search has to walk a keyspace of N^L, where N is the size of the character pool and L is the length. On average the password turns up halfway through, so the expected work is half the keyspace, and dividing that by the attacker's guess rate gives the time. Everything interesting hides in the guess rate. A bare digest such as MD5 or SHA-256 runs at tens of billions of guesses per second on a single modern GPU, because it was designed to be fast. A password hash is designed to be slow, and exposes a cost parameter that divides the rate directly: bcrypt's cost is a base-2 exponent, so cost 12 does 4,096 iterations where the benchmark setting of cost 5 does 32, and the attacker's throughput drops by that same factor of 128. That single parameter moves the answer further than any composition rule.
Crack Time Formula
An administrator reads the shortest length that survives a century against the hash their application already uses, and writes that number into the policy
An engineer shows what raising bcrypt from cost 10 to cost 12 does to an attacker's throughput before asking for the login-latency budget
A responder whose password table leaked works out how long the stored hashes hold against a rented multi-GPU rig
A trainer puts the length-by-character-set table on screen and lets the exponential do the arguing
Moving from SHA-256 to bcrypt at cost 12 slows an attacker by more than seven orders of magnitude. No amount of added punctuation comes close.
Each figure carries its hashcat mode number, so you can run hashcat -b -m 3200 yourself and compare. None of them are estimates.
OWASP sets floors (bcrypt cost 10, PBKDF2-HMAC-SHA256 at 600,000 iterations) and this shows precisely what falling short of them buys the attacker.
Rather than guessing at a minimum length, read the shortest one that still survives a century against the hardware you are willing to assume.
Against a bare digest, no time worth measuring. Eight random printable ASCII characters are a keyspace of about 6.6 quadrillion, and a single RTX 4090 runs SHA-256 at roughly 22 billion guesses per second, so the average search finishes in about a day and a half. On MD5 it is a matter of hours. Behind bcrypt at cost 12 the same eight characters hold for tens of thousands of years. The password did not change; the storage did.
There is no honest single figure, which is why this calculator asks you for a GPU count rather than offering a supercomputer tier. The largest publicly benchmarked cracking rig is 14 RTX 4090s reaching about 2 trillion MD5 guesses per second. Set the count to whatever adversary you want to model and the arithmetic follows; a page that hides that behind the word supercomputer is inventing the number.
NIST SP 800-63B revision 4 requires verifiers to permit at least 15 characters when a password is the only factor, and at least 8 when it sits alongside another factor. Those are floors for the verifier, not targets for you. The figure at the top of this page is the length that actually survives a century against the configuration you selected, which is usually the more useful number.
Because it is an exponent, not a multiplier. Cost c means 2^c iterations, so each step up doubles the attacker's work. hashcat benchmarks bcrypt at cost 5, which is 32 iterations; production systems should run at 10 or higher, and cost 12 is 4,096 iterations. Going from the benchmark setting to cost 12 divides the attacker's throughput by 128 for a login cost measured in milliseconds.
Published hashcat v6.2.6 benchmark runs with optimised kernels, on a stock-clocked RTX 4090 and an RTX 5090, released by Chick3nman. Every algorithm here lists its hashcat mode number so the figure can be reproduced with hashcat -b -m and compared. Argon2 is listed without a rate on purpose: hashcat only added Argon2 support in version 7, so no comparable benchmark exists to cite.
No, and the difference matters. This page models exhaustive search, which is the ceiling: it assumes the attacker learns nothing from the fact that people choose words, names and dates. A strength checker prices those patterns, so it will tell you that a 15-character passphrase made of four common words falls in seconds even though its keyspace looks enormous. Use this page to size a storage configuration, and a strength checker to judge one particular password.