Password Security from the Defender's Side

Most breaches still involve a password somewhere. Understanding how passwords are stored and attacked is the fastest way to understand why some policies work and most don’t.

Storage: hashing, salting, and slowness

A well-built system never stores your password. It stores a hash, a one-way fingerprint. At login, it hashes what you typed and compares.

Three properties make a password hash strong:

1. One-way. You cannot reverse a hash. Attackers guess candidates and compare.
2. Salted. A random value per user means two people with the same password get different hashes, and precomputed tables are useless.
3. Slow. Algorithms like Argon2id, bcrypt, and scrypt are deliberately expensive, so each guess costs time and memory.

Algorithm	Designed for passwords	Typical GPU guess rate
MD5, SHA-1, SHA-256	No	Billions per second
NTLM	No	Hundreds of billions per second on modern rigs
bcrypt (cost 12)	Yes	Thousands per second
Argon2id	Yes	Tuned by memory cost, very low

The gap between the top and bottom of that table is the whole story. A fast hash makes a leaked database a list of plaintext passwords within days.

Why passwords fall

Attackers rarely brute force every combination. They use what people actually choose:

• Wordlists of real leaked passwords, like the famous RockYou list.
• Rules that mutate words the way people do: Summer becomes Summer2026!.
• Credential stuffing: trying passwords leaked from one site on another. Reuse is the real enemy.

What the guidance actually says

NIST SP 800-63B, the most cited standard, reversed a lot of old advice:

• Favor length over complexity. A passphrase of several words beats P@ssw0rd!.
• Don’t force periodic changes without evidence of compromise. Forced rotation produces Password1, Password2, Password3.
• Screen new passwords against lists of known breached passwords.
• Allow paste and password managers. Long unique passwords require them.

Check breaches without leaking passwords

The Have I Been Pwned Passwords API uses k-anonymity. You send only the first five characters of the password’s SHA-1 hash and get back every matching suffix. The service never learns which password you checked:

hash=$(printf '%s' 'correct horse battery staple' | shasum -a 1 | awk '{print toupper($1)}')
curl -s "https://api.pwnedpasswords.com/range/${hash:0:5}" | grep "${hash:5}"

If that prints a line, the password appears in a breach, along with a count.

Measure your policy in a lab

Build a lab domain or a test database, create accounts that follow your organization’s password policy, and run a cracking tool against the hashes with a common wordlist and rule set. The percentage cracked in an hour is the most persuasive number you can bring to a policy discussion. Use the Hash Identifier in this site’s toolkit to find the right mode for your hash type.

Do this only with test accounts you created. Real users’ hashes require explicit authorization and careful handling.

Beyond passwords

The strongest move is to stop relying on passwords alone:

• Phishing-resistant MFA such as FIDO2 security keys or passkeys stops most account takeover outright.
• Password managers make unique passwords per site practical.
• Monitoring for credential stuffing, such as many failed logins across many accounts from one source, catches attacks in progress.

Takeaway

Store with a slow, salted algorithm, screen against breached lists, drop forced rotation, and push toward passkeys. Everything else is detail.