How passwords are actually cracked

Whether a password is "strong" is not a property of the password alone. It depends entirely on how it is stored and how an attacker gets to guess at it. This is the practical version, the one that explains why the same password can be safe on one site and cracked in seconds on another.

Two completely different attacks

Almost every "how long to crack" number you have seen conflates two situations that are nothing alike.

Online attacks guess against a live login screen. The attacker submits username and password combinations to the real service. This is slow and noisy: rate limiting, lockouts, CAPTCHAs and monitoring cap a realistic attacker to a handful of guesses per second, often far less. Against a well-run login, even a mediocre password can survive an online attack for a long time, which is why credential stuffing (reusing passwords leaked elsewhere) is the attack that actually works online, not brute force.

Offline attacks happen after a breach, when the attacker has stolen the database of password hashes. Now there is no login screen and no rate limit. They guess at the full speed of their own hardware, and this is where the choice of hash function decides everything.

Fast hashes vs. slow hashes

A password is never (should never be) stored as plain text. It is run through a one-way hash function and only the hash is kept. When you log in, the site hashes what you typed and compares. An attacker with the hash database tries to find an input that produces each stored hash.

The critical question is how fast that hash can be computed:

Fast hashes — MD5, SHA-1, SHA-256, and Windows NTLM — were built to be quick. A single modern GPU computes tens of billions of them per second. They were never designed to store passwords, and using them for that is the single most common serious mistake.
Slow hashes — bcrypt, scrypt, and Argon2 — were designed on purpose to be expensive. bcrypt has a "cost factor" that doubles the work with each step; at cost 12 a GPU manages only a few thousand guesses per second, not billions. Argon2 additionally burns large amounts of memory, which blunts the GPU advantage even further.

That gap is not small. For the identical stolen password, a fast hash can be exhausted in seconds while bcrypt at cost 12 would take years to centuries. The password did not change. The storage did. This is the whole reason the estimator shows six scenarios instead of one number.

Why raw "entropy" overstates safety

Entropy — length times the log of the character-set size — assumes a random password. Real passwords are not random. They are words, names, dates, and keyboard walks, decorated with a capital at the front and a "1!" at the end. Attackers know this, so they do not brute force blindly. They run:

Dictionary attacks — every word in huge wordlists, including every password from every past breach.
Rule attacks — programmatic mutations of those words (capitalize, leetspeak substitutions, append years and symbols) that mirror exactly how people "strengthen" passwords.
Mask attacks — brute force constrained to common patterns, like "Word + 4 digits".

A password like Summer2026! has respectable-looking entropy and falls almost instantly, because it is one dictionary word plus the two most predictable decorations. Treat any entropy estimate, including the estimator's, as a best case that assumes the attacker gets no help from patterns.

What actually keeps a password safe

Length and randomness beat complexity rules. A long passphrase of unrelated words or a random string from a password manager defeats dictionary and rule attacks far better than a short "complex" password.
Never reuse. The realistic online attack is someone replaying a password leaked from another site. A unique password per site makes that impossible.
Turn on two-factor authentication. It defends the online path even if the password is guessed or leaked.
If you run a service, store passwords with bcrypt, scrypt, or Argon2id — never a fast hash, never unsalted. This is the one decision that determines whether a breach of your database is a catastrophe or a shrug.

→ Try the crack-time estimator to see how the six scenarios play out for a sample password.