Calculate Password Cracking Time
This calculator estimates how long it would take an attacker to crack a password by brute force, given its length and the character set used. The core formula is C = N^L, where N is the number of possible characters and L is the password length — giving the total number of combinations. Cracking time is then T = C ÷ H, where H is the attacker's hash rate (guesses per second). Modern consumer GPUs can test 1–10 billion MD5 hashes per second; specialized rigs exceed 100 billion/sec. Even a single extra character multiplies combinations by N, making length the single most impactful factor in password security. Use this calculator to understand why "Tr0ub4dor&3" (11 mixed chars) is vastly stronger than "password123" (11 lowercase+digits).
When to use this calculator
- Security auditors benchmarking a company's password policy (e.g., verifying that a mandated 12-char minimum with special characters exceeds 1,000 years of cracking time at modern GPU speeds)
- IT administrators comparing the real-world strength of MD5-hashed vs. bcrypt-hashed passwords before migrating a legacy authentication system
- Developers setting minimum password requirements for a new web application and needing to justify the character-set and length rules to stakeholders with concrete time estimates
- End users deciding between a short, complex password ('P@5w!') and a longer passphrase ('correct-horse-battery-staple') to understand which is actually harder to brute-force
- Cybersecurity students and educators demonstrating exponential growth in password complexity during lessons on brute-force and dictionary attack defenses
Example calculation
- 8 alphanumeric
- 218 trillion combinations
How it works
3 min readHow It's Calculated
The math behind brute-force cracking time rests on two sequential formulas:
Step 1 — Total Combinations:
C = N ^ L
N = size of the character set (e.g., 26 for lowercase only, 62 for alphanumeric)
L = password length in characters
Step 2 — Cracking Time (worst case / exhaustive search):
T (seconds) = C / H
H = attacker's hash rate in hashes per second
T_avg (seconds) = C / (2 × H) ← average case: attacker finds it halfway through
Example:
8-char alphanumeric (N=62, L=8)
C = 62^8 = 218,340,105,584,896 (~218 trillion)
At H = 10,000,000,000 (10B hashes/sec, single RTX 4090 on MD5):
T_worst = 218,340,105,584,896 / 10,000,000,000 ≈ 21,834 seconds ≈ 6.07 hours
T_avg ≈ 3.03 hours> Note: Slower hash algorithms (bcrypt, Argon2) drop H to ~10,000–100,000/sec, multiplying time by a factor of 100,000× or more.
---
Reference Table
The table below uses H = 10 billion hashes/second (single consumer GPU, MD5) as the baseline. "bcrypt" column assumes H = 10,000/sec (cost factor 12).
| Length | Charset (N) | Combinations | Time @ 10B/s (MD5) | Time @ 10K/s (bcrypt) |
|---|---|---|---|---|
| 6 | Lowercase (26) | 308 million | < 1 second | 31 seconds |
| 6 | Alphanumeric (62) | 56 billion | 6 seconds | 65 days |
| 8 | Lowercase (26) | 208 billion | 21 seconds | 2.4 years |
| 8 | Alphanumeric (62) | 218 trillion | ~6 hours | 692,000 years |
| 8 | Full ASCII-95 (95) | 6.6 quadrillion | 7.6 days | 21 billion years |
| 10 | Alphanumeric (62) | 839 quadrillion | ~2.7 years | 2.7 trillion years |
| 12 | Alphanumeric (62) | 3.2 quintillion | ~10,000 years | practically infinite |
| 16 | Alphanumeric (62) | 4.7 × 10²⁸ | ~150 billion years | practically infinite |
| 20 | Lowercase (26) | 1.9 × 10²⁸ | ~60 billion years | practically infinite |
ASCII-95 includes uppercase, lowercase, digits, and all 33 standard special characters.
---
Typical Cases
Case 1 — The Classic "8-char Corporate Password" (e.g., P@ssw0rd)
Case 2 — The NIST-Recommended 15-char Passphrase (e.g., correct-horse-battery)
Case 3 — The "Secure-Looking but Short" Password (X$9!)
---
Common Mistakes
1. Assuming complexity beats length. A 6-char password using all 95 ASCII characters (C ≈ 7.4 billion) is cracked in under 1 second at modern GPU speeds, while a 20-char all-lowercase passphrase has C ≈ 1.9 × 10²⁸ — fundamentally uncrackable by brute force. Length dominates because the exponent is L, not N.
2. Ignoring the hash algorithm. Cracking time calculations are meaningless without knowing how the password is stored. MD5 and SHA-1 allow 10–100 billion guesses/sec per GPU. bcrypt (cost 12) or Argon2id allow only ~10,000/sec. Using a fast hash on a production database negates even a strong password policy.
3. Treating "worst case" as the only metric. Brute-force assumes random, uniform character distribution. In reality, attackers use dictionary attacks and rule-based mutations (e.g., Hashcat rules) that crack P@ssw0rd in milliseconds regardless of its theoretical combination count, because it matches a known pattern.
4. Forgetting salting. Unsalted hashes allow precomputed rainbow table attacks, reducing cracking time to a simple table lookup — effectively 0 seconds regardless of password length. NIST SP 800-63B mandates salting for all stored credentials.
5. Conflating online and offline attacks. Online attacks (login form) are rate-limited to perhaps 10 attempts/second; offline attacks (against a stolen hash database) run at full GPU speed. This calculator models offline brute force — the worst-case threat scenario.
---
Related Calculators
Frequently asked questions
What character set sizes should I use for common password types?
The standard sizes are: lowercase only = 26; uppercase only = 26; digits only = 10; lowercase + uppercase = 52; alphanumeric (lower + upper + digits) = 62; alphanumeric + 33 special ASCII chars = 95. If a policy says 'at least one special character,' assume N = 95 only if the attacker doesn't know which characters you used — in practice, attackers enumerate common specials first.
How fast can modern hardware actually crack passwords?
Speed depends heavily on the hash algorithm. A single NVIDIA RTX 4090 GPU achieves roughly 164 billion MD5 hashes/sec, ~22 billion SHA-256/sec, ~100,000 bcrypt (cost 12)/sec, and ~6,500 Argon2id/sec. Cloud-based cracking rigs with 8 GPUs multiply these figures by ~8×. These benchmarks are published annually by the Hashcat project and security researchers such as Jeremi Gosney.
Does this calculator account for dictionary attacks?
No — it models pure brute force (exhaustive keyspace search), which is the mathematical worst case. Dictionary and rule-based attacks (e.g., Hashcat's best64 rule set) are far faster against human-chosen passwords. A password like 'Passw0rd!' has 95^9 ≈ 630 quadrillion theoretical combinations, but it's cracked in milliseconds by any modern dictionary attack because it matches documented patterns. Use a password manager to generate truly random passwords.
What does NIST currently recommend for password length and complexity?
NIST Special Publication 800-63B (revised in 2024 as SP 800-63-4) recommends passwords of at least 8 characters as a minimum, strongly encourages 15+ characters, and discourages mandatory complexity rules (like forced special characters) in favor of length and checking passwords against known breached-password lists. Memorized secrets up to at least 64 characters must be supported by verifiers.
Why does adding one character make such a huge difference?
Because the formula is exponential: C = N^L. Adding one character multiplies the total combinations by N. For an alphanumeric password (N = 62), going from 8 to 9 characters multiplies combinations by 62×: from 218 trillion to 13.5 quadrillion. Going from 12 to 13 chars multiplies by 62× again. This is the mathematical basis for every security standard prioritizing length above all other factors.
Is a 12-character password actually safe today?
A truly random 12-character alphanumeric password (C = 62^12 ≈ 3.2 × 10²¹) takes roughly 10,000 years at 10 billion MD5 hashes/sec, and effectively forever with bcrypt. However, 'safe' depends on threat model: nation-state adversaries with GPU farms reduce that estimate, and non-random passwords (like 'Summer2024!') are cracked via dictionary attacks in seconds. NIST SP 800-63B recommends 15+ characters for high-value accounts.
What is the difference between average and worst-case cracking time?
Worst-case (T_worst = C / H) assumes the correct password is the very last one tried. Average case (T_avg = C / 2H) assumes the attacker finds it halfway through a random search — statistically the most likely scenario. For security analysis, worst-case is used to give the maximum possible exposure window. For expected breach time in risk modeling, average case is more realistic.
How does password salting affect cracking time calculations?
Salting doesn't increase the time to crack a single password — it eliminates precomputed rainbow table attacks and forces attackers to crack each hash independently. Without a salt, an attacker who cracks one MD5 hash has cracked every account using that same password simultaneously. With a unique per-user salt (as mandated by NIST SP 800-63B), the attacker must run the full brute-force calculation individually for each account.
Does this apply to PINs and numeric-only codes?
Yes. A 4-digit PIN uses N = 10, so C = 10^4 = 10,000 combinations — cracked in under 1 millisecond offline. A 6-digit PIN has only 1,000,000 combinations (~0.1 ms). This is why PINs are only secure when paired with hardware lockout mechanisms (like a phone that wipes after 10 incorrect attempts), not when the hash is exposed in a data breach.