How Long to Crack a Password? 2026 GPU Benchmark Numbers Explained

A single NVIDIA RTX 4090 running hashcat v7.0.0 burns through MD5 hashes at 163 billion per second. That is not a typo. The benchmark, posted to the hashcat forum in August 2025 by user slyexe, means an 8-character lowercase password hashed in MD5 falls in well under a second of exhaustive search.

The number that matters for how long to crack a password is not the GPU speed alone. It is the ratio of keyspace to hash rate, modulated by the hash function's cost. SHA-256 runs at 22 billion hashes per second on the same card. bcrypt at production cost factor 10 runs at roughly 5,600 hashes per second. That gap is the difference between seconds and years.

This post works through the actual arithmetic. I use published RTX 4090 benchmarks, NIST SP 800-63B guidance on password composition, and real dictionary attack behavior to show why most real passwords die fast and why a 12-character random string does not. You can plug your own strings into the password strength checker as you read.

The starting point is raw hash throughput. The hashcat forum benchmark thread for the RTX 4090 on hashcat v7.0.0 reports these speeds for a single GPU:

These are billions of hashes per second. NTLM, the hash format Windows used by default for local accounts, is the fastest at roughly 285 billion per second. MD5 is close behind. SHA-256, which many modern systems use for password hashing when no slow KDF is applied, runs at 22 billion per second.

The speed difference between MD5 and SHA-256 is about 7x. The speed difference between SHA-256 and bcrypt is roughly 4 million times, once you account for cost factor. That is the single most important number in password cracking, and I will return to it.

bcrypt is deliberately slow. It is based on the Blowfish cipher, which uses a large, continuously mutating subkey table. Each candidate password requires hundreds of sequential memory reads and writes that depend on the previous step. This serializes work across GPU threads and kills the parallelism that makes GPUs fast for MD5 and SHA-256.

The hashcat benchmark for bcrypt mode 3200 runs at cost factor 5 by default. On an RTX 4090 that is about 180 kH/s (180,000 hashes per second), according to the bcrypt benchmark table compiled in 2026. Production systems do not use cost 5. They use cost 10 or 12.

Cost factor is an exponent. Cost 5 means 2^5 = 32 rounds of key setup. Cost 10 means 2^10 = 1024 rounds. Each increment doubles the computation time. Dividing the cost 5 speed by 32 gives the cost 10 speed: 180,000 / 32 = 5,625 hashes per second. At cost 12, divide by 128: roughly 1,400 hashes per second.

The newer RTX 5090 reaches about 250 kH/s at cost 5, which translates to roughly 7,800 hashes per second at cost 10. Still slow. An 8-character lowercase password space has 208 billion combinations. At 7,800 hashes per second, exhaustive brute force takes about 2.7 years on a single RTX 5090. Compare that to 9 seconds for SHA-256 on a 4090.

bcrypt was first presented by Niels Provos and David Mazieres at the 1999 USENIX Security Symposium in their paper "A Future-Adaptable Password Scheme." The design goal was explicitly to make hardware acceleration expensive, which is why it remains a recommended password hash more than 25 years later.

Here is the arithmetic for four password profiles against two hash functions. The SHA-256 column uses 22.1 GH/s (22.1 billion hashes per second). The bcrypt column uses cost factor 10 at 5.6 kH/s (5,600 hashes per second).

The math is simple: divide the keyspace by the hash rate. An 8-character lowercase password has 26^8 = 208,827,064,576 combinations. At 22.1 billion SHA-256 hashes per second, that is 208 billion / 22.1 billion = 9.4 seconds. The same password against bcrypt cost 10 at 5,600 hashes per second is 208 billion / 5,600 = 37 million seconds, which is about 1.2 years.

The 8-character password using all 95 printable ASCII characters has 95^8 = 6,634,204,312,890,625 combinations. Against SHA-256 that is 6.63 quadrillion / 22.1 billion = 300,000 seconds, or about 3.5 days. Against bcrypt cost 10 it is 6.63 quadrillion / 5,600 = 1.18 trillion seconds, or about 37,000 years.

A 12-character random password using all 95 printable ASCII characters has 95^12 = 5.4 x 10^23 combinations. Against SHA-256 on a single RTX 4090, exhaustive search takes about 777,000 years. Against bcrypt cost 10, it takes roughly 3 trillion years. At that point you are not cracking anything. You are waiting for the heat death of the universe.

You can compute the entropy of your own passwords with the entropy calculator and compare against these baselines.

Brute force is the slow path. Real password cracking runs dictionary and rule-based attacks first, and they succeed far more often than exhaustive search.

The rockyou wordlist, leaked from a 2009 breach of the RockYou social gaming site, contains about 14 million unique passwords. hashcat can try every entry in a wordlist against an MD5 hash set in seconds on a 4090. Against SHA-256, the full rockyou list takes under a second. Against bcrypt cost 10, it takes about 40 minutes on a single GPU.

Rules make dictionaries more effective. A hashcat rule takes a base word and applies transformations: capitalize the first letter, append a digit, replace "o" with "0", append a year. The best64.rule set that ships with hashcat applies 77 rules to each word. A 14 million entry wordlist with best64.rule produces about 1 billion candidates. Against SHA-256 at 22 billion per second, that entire candidate set runs in under 50 milliseconds.

This is why human-chosen passwords fall fast. People do not pick random strings. They pick words, capitalize the first letter, and add a number. The rule engine models that behavior directly. NIST SP 800-63B, the Digital Identity Guidelines, explicitly notes that human-chosen passwords carry far less entropy than a random string of the same length. The guideline moved away from recommending forced composition rules (must contain uppercase, digit, symbol) because those rules push users toward predictable patterns that rule-based attacks exploit.

If you want a password that survives, generate it randomly. The password generator produces strings with uniform randomness across the full ASCII set, which is the only way to actually realize the keyspace sizes in the table above.

NIST SP 800-63B, published in 2017 and updated since, is the current US federal guidance on digital identity and password policy. Several of its recommendations directly contradict the password rules you probably learned in the 2000s.

The guideline says: do not impose arbitrary composition rules. Do not require periodic password changes unless there is evidence of compromise. Do allow long passwords (up to at least 64 characters). Do accept all ASCII characters including spaces. Do screen new passwords against a list of known compromised passwords.

The reasoning is empirical. Composition rules like "one uppercase, one digit, one symbol" do not increase entropy in practice. They increase predictability. Users respond to the rule by capitalizing the first letter and appending "1" or "!". Rule-based cracking tools model this exactly.

The guideline also recommends using a memory-hard or computationally expensive hash for password storage. bcrypt, scrypt, Argon2, and PBKDF2 are all acceptable. Plain SHA-256 with no salt and no iteration count is not acceptable for password storage, and the benchmark numbers above show why: 22 billion hashes per second means any short password is dead on arrival.

You can verify whether a bcrypt hash is correctly formatted and matches a known password using the bcrypt hash checker.

The numbers in this post assume a single GPU. A serious attacker uses a rig of 4 to 8 GPUs, which scales the speed linearly. A cluster of 8 RTX 4090s hits 177 billion SHA-256 hashes per second, cutting the 8-character lowercase time from 9 seconds to about 1.2 seconds. Cloud GPU rental makes this accessible to anyone with a credit card.

The numbers also assume the attacker has the hash. If the hash is stored correctly with a per-user salt, rainbow tables are useless, but brute force and dictionary attacks still work at full speed. Salt prevents precomputation, not online guessing.

The bcrypt numbers assume the implementation uses cost 10 or higher. Many legacy systems use cost 5 or lower, or use legacy hashes like MD5 or SHA-1. Those systems are cracked at the speeds in the first table, not the bcrypt table. Check what your system actually uses.

Finally, these are exhaustive search times. Dictionary attacks with rules finish much faster against real password distributions. The 9-second SHA-256 figure for 8-character lowercase is a worst case for that specific keyspace. A dictionary attack against real user passwords typically succeeds in under a minute against unsalted SHA-256.

The hash function matters more than the password length. An 8-character random password against bcrypt cost 10 survives about 1.2 years on a single RTX 4090. The same password against SHA-256 survives 9 seconds. Pick a slow, memory-hard hash for storage, and pick a long random password for the user side. Those two decisions collapse the attack economics more than any composition rule ever did. Test your own passwords against these baselines with the password strength checker.