Why where your password is stored matters more than how long it is
Ask most people how to make a password strong and they will say "make it longer." That advice is not wrong, but it is incomplete in a way that misleads people about where the real risk sits. The hash function protecting a password on the server side changes how long it takes to crack that password by many orders of magnitude, often far more than any realistic change to the password's length. If you only internalize one fact about password security, it should be this one.
The same password, two very different outcomes
Consider a password with about 60 bits of entropy, roughly what you get from a fully random 10-character string drawn from a reasonable character set (entropy is length multiplied by log2 of the charset size, so a 10-character password from a 62-character alphabet gives you 10 times log2(62), just under 60 bits). Now hash that exact same password two different ways and look at what an attacker who has stolen the database actually faces:
| Storage method | Approx. guess rate (2026 GPU) | Rough time to exhaust 2^60 guesses |
|---|---|---|
| Unsalted MD5, SHA-1, or NTLM | Tens of billions/sec per GPU | Hours to low single-digit days on one GPU |
| bcrypt, cost factor 12 | A few thousand/sec per GPU | Many thousands of years on one GPU |
| Online login, rate-limited | A handful of attempts/sec | Effectively unreachable, account lockouts trigger first |
That is the same password. The length did not change. The character set did not change. What changed is the work required per guess, and that one variable spans a gap of roughly seven orders of magnitude between the worst row and the best. No amount of adding characters to your password closes a gap that size if the service storing it is still using a fast, unsalted hash. For a sense of how these numbers play out for a password of any length and composition, the crack-time estimator will run the math directly.
Online attacks versus offline attacks
These two attack modes are not the same problem and do not call for the same defenses. An online attack is someone guessing against your live login form, one attempt at a time (or a modest number of attempts in parallel), over the network. This is where rate limiting, account lockouts, CAPTCHAs, and multi-factor authentication do most of their work; even a mediocre password resists an online attacker for a long time because the attacker is stuck at a handful of guesses per second against a defended endpoint.
An offline attack is a different world entirely. It happens after a database breach, when the attacker has the hash values themselves and no server to rate-limit them. They run the cracking attempt on their own hardware, as fast as the hash function allows, with no lockout and no logging. This is the scenario the table above describes, and it is the scenario where the choice of hash function (Argon2id versus bcrypt versus an unsalted fast hash) is the entire ballgame. A detailed walkthrough of how real cracking runs actually proceed, dictionary-first, then rule-based mutation, then brute force for the remainder, is on the how passwords are cracked page.
The practical implication: you, as a user, have almost no visibility into which of these two worlds you are exposed to for any given account. You cannot tell from the login page whether a service hashes with Argon2id or stores plaintext in a spreadsheet (and both have happened at real companies). This is exactly why password reuse is the risk that matters most.
Reuse is the real threat, not length
Here is the chain of events behind the large majority of account takeovers that do not involve phishing: a service with weak storage gets breached, the stolen credentials get cracked or were never hashed at all, and the resulting plaintext password-and-email pairs get tried against every other service the same email address might be registered on. This is called credential stuffing, and it is entirely automated, run at massive scale, and does not care how clever your password was. If you used the same password on the breached low-value forum account and your email provider, the forum's weak hashing choice just became your email provider's problem.
A 16-character password reused across 20 sites is less safe in practice than a 12-character password used nowhere else, because the reused password's real-world strength is capped by whatever the weakest of those 20 sites did with it. Uniqueness defeats credential stuffing categorically: a cracked password from one breach simply does not work anywhere else, regardless of how it was cracked or how fast.
So what does "strong" actually mean
Put together, a password is meaningfully strong when three things are true at once, not just one:
- Enough entropy to resist offline guessing for a meaningful span of time even against a fast hash, which in practice means length and genuine randomness, not word substitutions or predictable patterns. A random 10 to 12 character password, or a longer passphrase of unrelated words, gets you into a defensible range.
- Unique per site, so a breach anywhere else never becomes a breach everywhere else. This is the single most effective thing an individual user controls, and it is why password managers exist: nobody is memorizing 60 unique strong passwords unassisted.
- Stored by the service with a slow, memory-hard hash (Argon2id, scrypt, or at minimum bcrypt), which is entirely out of the user's hands and entirely in the hands of whoever built the authentication system. This is why, as a user, you cannot fully protect yourself through password choice alone, and why, as a developer, hashing algorithm selection deserves more engineering attention than almost any password policy you could layer on top of it.
Length matters, but it is one variable among several, and it is not the one with the widest dynamic range. The hash function is. Treat where a password lives as at least as important as how it is composed, because the gap between a well-hashed and poorly-hashed credential is measured in orders of magnitude, not percentages.