Password Security: Length, Reuse, Breaches and How Passwords Are Actually Cracked

Password security comes down to two facts: attackers mostly do not guess passwords, they replay ones leaked from other sites, and when they do guess, they test billions of dictionary variants against stolen hashes rather than trying random strings. A unique password per site defeats the first; length defeats the second. A password manager delivers both, and a breach check tells you which existing passwords are already burned.

How accounts are actually taken over

The image of an attacker typing guesses into a login form is almost entirely wrong. Online guessing is slow, rate-limited and logged. What happens instead is credential stuffing: an attacker takes the email-and-password pairs from a breach at one site and tries them, automatically, against hundreds of others. It works because people reuse passwords, and it needs no cracking at all when the breached site stored passwords in plain text or in a hash that was already broken. The second route is offline cracking: the attacker obtains a database of password hashes and tests guesses against it on their own hardware, at whatever speed the hash function allows, with no lockout to stop them. The third is phishing, which bypasses the password's strength entirely by asking you for it; the phishing guide covers that separately.

Both of the first two depend on breaches, which is why the practical first step is not choosing a stronger password but finding out whether your current ones have already leaked. The breach response guide covers what to do when one has.

How passwords are stored

A well-run site never stores your password. It stores a hash: the output of a one-way function applied to the password plus a random salt. At login the site hashes what you typed with the same salt and compares. If the database leaks, the attacker has hashes, not passwords, and must guess. The salt prevents a precomputed table from covering every user at once; each hash must be attacked separately.

The choice of hash function determines the attacker's speed, and the difference between choices is enormous. A general-purpose hash such as MD5 or SHA-1 was designed to be fast, so a single consumer GPU tests tens of billions of candidates per second. A password hash is designed to be slow and memory-hungry, cutting that to thousands or tens of thousands per second. The OWASP Password Storage Cheat Sheet recommends Argon2id first, then scrypt, then bcrypt for legacy systems, with PBKDF2 acceptable where FIPS compliance requires it. Stored, a bcrypt hash carries its own cost factor and salt:

$2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW

The 12 is the cost: 2 to the power 12 rounds, doubling with each increment. You cannot tell from outside how a site stores passwords, which is a further reason not to reuse: the weakest site you share a password with sets the security of all of them.

How cracking works

Cracking tools such as hashcat do not iterate through every possible string. They work from wordlists, which are past breaches and dictionaries, and apply rules that mutate each word the way people do: capitalise the first letter, append a year, swap a for @, add an exclamation mark. Then they combine words. A password like Summer2025! is one dictionary word, one common rule and one common suffix; it is among the first candidates tested, and its symbols and digits do not help. What the attack cannot cheaply cover is length. Each additional character that is not predictable from the previous ones multiplies the search space, and past about sixteen characters even a fast hash puts uniform random passwords out of reach.

Two consequences. First, complexity rules that force a digit and a symbol produce predictable mutations and do not raise the cost of the attack; NIST SP 800-63B now explicitly tells services not to impose them. Second, a passphrase of several words chosen at random from a large list is both strong and typeable, which makes it the right choice for the few passwords you must remember, such as the one that unlocks your manager. The words must be random; a quotation or a sentence you would say is in the wordlists.

Our password checker measures strength the way a cracker sees it, by looking for dictionary words, patterns and substitutions rather than counting character classes; the weak password and common pattern checks explain what each finding means.

Checking for breaches without revealing the password

Have I Been Pwned maintains Pwned Passwords, a corpus of hundreds of millions of passwords seen in real breaches, and offers a lookup that never receives your password. The mechanism is called k-anonymity. The client computes the SHA-1 hash of the password locally and sends only the first five hexadecimal characters; the server returns every hash suffix in its corpus that begins with those five characters, each with a count of how often it appeared; the client checks for its own suffix in the list. The server learns a five-character prefix shared by several hundred hashes and nothing more.

password        -> SHA-1: 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8
prefix sent     -> 5BAA6
GET https://api.pwnedpasswords.com/range/5BAA6

response (excerpt, one suffix per line with its breach count)
1E4C9B93F3F0682250B6CF8331B7EE68FD8:10434004
...

match: suffix 1E4C9B93F3F0682250B6CF8331B7EE68FD8 is present, so "password" is breached

The response lists every suffix in the range, matching or not, so the server cannot tell which one you were interested in. This is how our password checker performs its breach lookup, how the built-in managers in the major browsers check saved passwords, and how a site can screen new passwords at signup as NIST recommends. Note that SHA-1 is used here only as a lookup key, not as protection, so its weaknesses as a hash do not matter; a breached password is breached regardless of how well it is hashed anywhere.

What a password manager changes

A manager does not make you better at choosing passwords; it removes the need to. It generates a long random password for each site, stores them all encrypted under one strong passphrase, and fills them in. Three things follow:

• Reuse ends, which removes credential stuffing as a threat to you personally.
• Length stops being a burden, so every password can be as long as the site allows.
• Phishing gets harder, because a manager fills credentials only on the domain it saved them for; a lookalike domain gets nothing. The browser password manager guide compares built-in and dedicated managers on this point.

The manager's own passphrase becomes the one password that matters. Make it a random multi-word passphrase, never reuse it, and protect the account with a strong second factor. The two-factor authentication guide ranks the options; a hardware key or passkey on the manager account is the single best upgrade most people can make.

What good service-side policy looks like

If you run a site, NIST SP 800-63B is the reference and it is specific. Allow at least 64 characters and the full printable character set including spaces. Do not require character classes. Do not expire passwords on a schedule; require a change only when there is evidence of compromise. Screen new passwords against a breach corpus and against context-specific words such as the service name. Rate-limit and monitor failed logins. Hash with Argon2id, scrypt or bcrypt at a cost tuned to your hardware. Offer, and preferably require for sensitive accounts, a phishing-resistant second factor.

A practical order of work

1. Check your important passwords for breaches. Anything that appears in the corpus is changed today, everywhere it was used.
2. Install a password manager and set a random four-or-more-word passphrase on it.
3. Replace reused passwords, starting with email (which resets everything else), banking, and any account that stores payment details.
4. Enable two-factor authentication on those same accounts, preferring an authenticator app, hardware key or passkey over SMS.
5. Let the manager generate everything new from now on and stop thinking about it.

The privacy hub connects this to the phishing pages and breaches that are the usual route to a stolen password.