Password Crack Time Calculator

Background.

This calculator estimates how long an attacker who has stolen a password hash would need to brute-force it, and it puts the two variables that actually decide the answer in front of you rather than hiding them in a constant. The first is the size of the space the attacker has to search, which comes from the alphabet and the length. The second is how many guesses per second the attacker can make, which comes from the password hashing scheme and the hardware — and which varies by a factor of about a hundred million across the options on this page, on identical silicon.

That second point deserves saying plainly, because almost every "how long to crack my password" answer on the internet quietly assumes one hash and one machine. A 12-character password drawn at random from the 94 printable ASCII characters takes roughly 46,000 years to break on a single RTX 4090 if the site stored it as unsalted MD5. The identical password takes about 4.5 trillion years if the site used bcrypt at cost 12. The password did not change. The storage did. If you take one thing from this page, take that: the number below is far more a statement about the service holding your password than about the password itself.

The guess rates are not invented. Every preset is quoted verbatim from the hashcat project's own published benchmark of hashcat 7.0.0 on a single NVIDIA GeForce RTX 4090: 163.4 GH/s for MD5, 271.9 GH/s for NTLM, 58,562.8 MH/s for SHA-1, 22,138.4 MH/s for SHA-256, 1,195.7 kH/s for sha512crypt at 5,000 rounds, and 212.6 kH/s for bcrypt. One rate is derived rather than measured and is labelled as such: hashcat's bcrypt benchmark runs at cost factor 5, which is 32 iterations, so the cost-12 figure of 1,660.9375 guesses per second is that benchmark divided by 128, because 4,096 iterations is 128 times the work of 32. There is also a custom option, because no benchmark survives the next generation of hardware and you should be able to model whatever rate you think is realistic.

The attack modelled here is offline. The attacker holds the hash, runs locally, and tests guesses as fast as the hardware allows. That is the case that matters after a breach, and it is the case in which the strength of the password is the only thing standing between the attacker and the plaintext. It is not the case when someone is typing guesses into a login form: NIST SP 800-63B-4 requires verifiers to limit consecutive failed authentication attempts to no more than 100, so an online attack is bounded by the number of attempts the service permits, not by elapsed time, and no guesses-per-second figure describes it honestly. That is why there is no "online attack" preset here.

The arithmetic assumes the secret was generated uniformly at random from the stated alphabet — by a password manager, by dice, by a key generator. If you invented the password yourself, the estimate is an upper bound you will never reach, because real attackers do not start at aaaaaaaaaaaa and count upwards. They run wordlists, then leaked-password corpora, then rule-based mutations that know all about capitalising the first letter and appending a year. That is why NIST SP 800-63B-4 abandoned entropy scoring for human-chosen passwords entirely in favour of a length floor plus a breach-corpus blocklist. Nothing on this page is a verdict that a specific password is safe, and the note under the result says so on every render.

Below the widget you will find the derivation, the full benchmark table with the exact lines it was read from, a worked example computing 94¹² by hand, the difference between the average case and an exhaustive search, and an explanation of why moving a password from MD5 to bcrypt buys more security than adding four characters ever could.

What is password crack time calculator?

Password crack time is an estimate of how long a brute-force search takes to find a secret, computed as the number of guesses required divided by the number of guesses per second the attacker can make. The guess count comes from the search space: a secret of L symbols drawn from an alphabet of C symbols has C^L possibilities, and over a uniform space an attacker expects to find it after searching half of them, so the average case is C^L ÷ 2 and an exhaustive search is C^L. The guess rate is a property of the defender's storage choice and the attacker's hardware, not of the password. A fast general-purpose hash such as MD5 or SHA-256 was designed to be quick, which is exactly what makes it a poor password store — a single consumer GPU tests tens of billions of candidates a second against it. A password hashing function such as bcrypt, scrypt or Argon2 is deliberately slow and deliberately memory-hungry, and its cost parameter is a dial the defender turns: bcrypt's cost is the base-2 logarithm of its iteration count, so raising it by one doubles the attacker's work forever after. The resulting estimate is a ceiling, not a prediction. It describes the time to exhaust the space, which is what an attacker faces only when the secret really was drawn uniformly from that space. Against a human-chosen password, an attacker armed with a leaked-password corpus and a rule engine is typically finished in a tiny fraction of the time this page reports, which is why the figure should be used to compare storage schemes and generator settings, never to certify a password you thought up.

How to use this calculator.

1. 01Pick the alphabet the generator was configured with. If your password manager was set to letters and digits only, choose 62 even if the password it produced happens to contain a symbol-looking character.
2. 02Enter the length. For a passphrase, choose one of the EFF wordlists and enter the number of WORDS. The field is capped at 64 because that is the maximum length NIST SP 800-63B-4 asks verifiers to accept.
3. 03Choose how the password is stored. If you do not know, assume the worst — a service that has not said otherwise may well be using a fast unsalted hash, and that assumption is the one that matters after a breach.
4. 04Set the number of devices. One is a single high-end consumer GPU. Eight models a typical purpose-built rig. Six figures models a well-funded adversary renting cloud capacity.
5. 05Leave the attack model on Average unless you specifically want the bound. Average case is half the space, which is the expected number of guesses over a uniform key space; exhaustive is exactly twice that.
6. 06Read the note under the result before you read the result. It states the two assumptions the whole figure rests on: an offline attack on a stolen hash, and a secret produced by a random generator rather than by a person.

The formula.

The search space is C^L: a secret of L symbols, each drawn independently from an alphabet of C symbols, has that many possible values. If the draw was uniform, every value is equally likely, so an attacker working through the space in any fixed order expects to hit the right one halfway through. That gives C^L ÷ 2 as the expected guess count and C^L as the guarantee. This page defaults to the average case because it is the honest expectation; the exhaustive figure is offered because it is the number most people picture, and it is always exactly double.

Dividing by the guess rate turns guesses into seconds. The rate is the product of a per-device figure and the number of devices, and GPU cracking of a single stolen hash parallelises almost perfectly, so treating eight cards as eight times one card is a good approximation and a slightly conservative one.

The per-device figures come from hashcat's own published benchmark output. The exact lines are reproduced in the citations, and the important structural fact they reveal is the size of the gap: 163.4 GH/s for MD5 against 212.6 kH/s for bcrypt at hashcat's default cost, a ratio of roughly 770,000 to one, and against 1,660.9 H/s for bcrypt at cost 12, a ratio of roughly 98 million to one. In entropy terms, moving a password from unsalted MD5 to bcrypt cost 12 is worth about 26.5 bits — the same as adding four characters to a printable-ASCII password, achieved without the user changing anything at all.

The bcrypt cost-12 rate is the one derived number on this page and it is worth showing the working. hashcat's mode 3200 benchmark prints 'Iterations: 32'. bcrypt's cost parameter is the base-2 logarithm of its iteration count, so 32 iterations is cost 5. A deployment at cost 12 runs 2¹² = 4,096 iterations, which is 4,096 ÷ 32 = 128 times the work per guess, so the rate is 212,600 ÷ 128 = 1,660.9375 guesses per second. Every doubling of the cost parameter halves it again.

Seconds are converted to years using the Julian year of exactly 365.25 days at 86,400 seconds each, which is 31,557,600 seconds — the definition NIST gives in its Time and Frequency reference and the same constant used elsewhere in this codebase. Both time outputs are rounded to 12 significant digits rather than to a fixed number of decimal places, because they range from well under a microsecond to well past 10²⁴⁰ years and no fixed decimal place is meaningful across that span.

A worked example.

Frequently asked questions.

References& sources.

1. [1]hashcat project forum — 'NVIDIA RTX 4090 Benchmark HC 7.0.0' (hashcat 7.0.0, CUDA 12.6, one NVIDIA GeForce RTX 4090). Source of every guess rate on this page, quoted verbatim: Hash-Mode 0 (MD5) 163.4 GH/s; Hash-Mode 1000 (NTLM) 271.9 GH/s; Hash-Mode 100 (SHA1) 58562.8 MH/s; Hash-Mode 1400 (SHA2-256) 22138.4 MH/s; Hash-Mode 1800 (sha512crypt $6$) [Iterations: 5000] 1195.7 kH/s; Hash-Mode 3200 (bcrypt $2*$) [Iterations: 32] 212.6 kH/s. The 'Iterations: 32' annotation is what fixes the benchmarked bcrypt cost factor at 5 and makes the cost-12 rate derivable as 212,600 ÷ 128.
2. [2]NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, §3.1.1.2 and §3.2.2. Source of the 64-character length ceiling used here ('Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters'), the 15-character single-factor minimum, and the rate-limiting requirement that bounds an online attack at no more than 100 consecutive failed authentication attempts.
3. [3]NIST SP 800-63B-4, Appendix A 'Strength of Passwords'. Source of the standing caveat that this page's arithmetic does not describe a human-chosen password: entropy has often been used to characterise user-chosen password strength, but estimating it for a human's choice is problematic, so the guideline adopts 'a different and somewhat more straightforward approach based primarily on password length'.
4. [4]NIST, Computer Security Resource Center Glossary — 'security strength'. 'A number associated with the amount of work (i.e., the number of operations) that is required to break a cryptographic algorithm', measured in bits, with roughly 2^S operations required at strength S. Used to relate the guess counts on this page to the bit figures beside them.
5. [5]NIST, Time and Frequency from A to Z (X to Z). Source of the year constant used to convert seconds to years: 'In astronomy, the Julian year is defined as being equal to exactly 365.25 days, with each day having 86,400 seconds' — 31,557,600 seconds.
6. [6]IETF RFC 20 (Internet Standard 80), 'ASCII format for Network Interchange'. Source of the printable-character alphabet sizes: US-ASCII graphic characters occupy code points 0x20 through 0x7E inclusive with SPACE listed inside the graphic set, giving 95 printable characters or 94 excluding SPACE.
7. [7]Electronic Frontier Foundation (2016). 'Deep Dive: EFF's New Wordlists for Random Passphrases'. Source of the passphrase pool sizes offered here: the long list is '7,776 words (6⁵)' and the two short lists are '1,296 words (6⁴)'.