How passwords are actually cracked

Whether a password is strong is not a property of the password alone. It depends on how the site stored it and how the attacker gets to guess. This page follows a cracking run in the order an attacker works, with the guess rates we measured.

Step 1: get the hashes

There are two very different situations, and most "how long to crack" numbers mix them up.

An online attack guesses against a live login form. Rate limits, lockouts, CAPTCHAs and monitoring hold the attacker to a handful of guesses per second per account, often fewer, so even a mediocre password survives a brute-force attempt there. What works online is credential stuffing: replaying email-and-password pairs leaked from some other site, on the bet that people reuse passwords.

An offline attack starts after a breach, when the attacker has a copy of the stored password hashes. There is no login form and no rate limit. They guess on their own hardware as fast as the hash function allows, and the rest of this page is about that case.

Step 2: identify the hash

A stored hash usually announces what it is, and with it how expensive each guess will be. A string that starts $2b$12$ is bcrypt at cost 12. One that starts $argon2id$v=19$m=19456,t=2,p=1$ is Argon2id with its memory and time settings in plain view. A bare 32-character hex string is most likely MD5 or NTLM, which cost almost nothing to compute. The format decides the guess rate, and the guess rate decides everything after it: on one RTX 5090, about 221 billion guesses per second against MD5 and about 2,381 against bcrypt at cost 12.

Salting matters at this point too. With an unsalted fast hash, each guess is checked against every user in the database at once, so cracking a million accounts costs the same as cracking one. A salted hash, which bcrypt, scrypt, Argon2 and PBKDF2 all use, gives every account its own salt, and every guess has to be repeated for each account.

Step 3: try passwords people have already used

Attackers do not start with brute force. They start with wordlists of real passwords from earlier breaches, tried in order of how common they are. A password at rank 1,473 on such a list falls on guess 1,473, however long or mixed it looks. Against bcrypt at cost 12, trying the whole 755,994-entry list we used takes one RTX 5090 about 5.3 minutes per stolen hash. Against a fast hash it is over before the cracking software has finished starting up.

This is where length-and-character-set strength meters go wrong, ours included. Our analysis of the most common leaked passwords shows how many of them such a meter calls strong.

Step 4: mutate the words

Next come rules: programs that rewrite each wordlist entry the way people "strengthen" passwords. Capitalize the first letter, swap a for @ and o for 0, append a year, append !. hashcat ships rule files built for this, such as best64.rule. A password like Summer2026! scores about 72 bits on an entropy meter, because it is 11 characters from all four character sets, yet it is a dictionary word, a year and a symbol: exactly the shape that rules produce. Mask attacks do the same thing for structure, for example trying every "capitalized word plus four digits".

Step 5: brute force what is left

Only the passwords that survive lists, rules and masks get brute-forced, and this is the one step where the textbook entropy calculation is the right model. Here the storage choice dominates. The table shows how long it takes to try every 10-character password made of upper and lower case letters and digits:

62¹⁰ is about 8.4 × 10¹⁷ combinations; the average password falls in half the time shown. RTX 5090 rates are from its published hashcat benchmark; see hash rates for the method and the derived figures.

On the same GPU the answer moves from 29 days against NTLM to 11 million years against bcrypt at cost 12, a factor of about 143 million. In password terms that factor is worth about 4.5 extra random characters from the same set: a user could close the gap by making a random password five characters longer. The catch is that the user never knows which storage they are up against, and a person's added characters are rarely random. A site that switches from a fast hash to bcrypt gives every user that protection at once.

What actually keeps a password safe

1. Randomness, then length. A random string from a password manager, or a passphrase of several randomly chosen words, is the only kind of password the brute-force numbers describe. Anything a person makes up gets tried at steps 3 and 4.
2. Never reuse a password. Reuse caps every account at the protection of the weakest site that stores it. A password that is unique to one site is useless to credential stuffing.
3. Turn on two-factor authentication. It protects the online path even after a password leaks.
4. If you run a login system: store passwords with Argon2id, scrypt or bcrypt at the OWASP settings or above, check new passwords against a blocklist of common and compromised passwords, and drop composition rules in favour of a minimum length. NIST SP 800-63B-4 requires the blocklist and forbids the composition rules.

Updated 1 November 2026.