Episode 17 · Module 5 · Authentication & Identity

Password Hashing Done Right

18 May 2026 · 9:52 · Security for Legal SaaS

9:52 9:52

Encryption is reversible — hashing is not. Alice and Dan cover why “encrypted passwords” is the wrong answer, the modern algorithm hierarchy (Argon2id, bcrypt, scrypt), salts and rainbow table attacks, timing attacks and constant-time comparison, NIST 800-63B’s password policy revolution, credential stuffing defence with haveibeenpwned, and work factor calibration — all through the lens of legal SaaS where a breached password database has compounding consequences.

Today’s Lesson

Security for Legal SaaS — Episode 17: Password Hashing Done Right

Why “Encrypted Passwords” Is the Wrong Answer

When someone says their passwords are stored “encrypted,” alarm bells should ring. Encryption is reversible — if you can decrypt, so can an attacker who obtains your key. The 2012 LinkedIn breach exposed 117 million passwords hashed with unsalted SHA-1 — a hash function designed for speed, not resistance. Within days, the majority were cracked.

Key distinction: Hashing is a one-way function — you cannot reverse it to obtain the original password. Encryption is two-way — anyone with the key can recover the plaintext. Password storage requires hashing, never encryption. OWASP’s Password Storage Cheat Sheet is unambiguous on this point.

For legal SaaS platforms, a password database breach has compounding consequences. Lawyers reuse passwords across systems — a 2023 Bitwarden survey found 68% of internet users manage passwords for 10+ sites, with significant reuse. A cracked password from your platform becomes a credential stuffing weapon against court filing systems, client portals, and bar association accounts.

The Modern Password Hashing Algorithms

Argon2 — The Current Standard

Argon2 won the Password Hashing Competition in 2015, selected from 24 submissions by a panel of cryptographers. It comes in three variants:

Variant	Optimised Against	Use Case
Argon2id	Both GPU and side-channel attacks	Recommended default
Argon2i	Side-channel attacks	When timing attacks are the primary threat
Argon2d	GPU cracking	When side-channels are not a concern

OWASP recommends Argon2id with these minimum parameters:

Memory: 19 MiB (19456 KiB)
Iterations: 2
Parallelism: 1

The key insight is memory-hardness. Unlike bcrypt or PBKDF2, Argon2 requires a configurable amount of RAM per hash computation. GPUs have limited per-core memory — this makes massively parallel cracking economically infeasible.

bcrypt — Battle-Tested but Aging

bcrypt (1999) introduced the concept of an adaptive cost factor. Each increment doubles the computation time. It’s been the workhorse of password hashing for 25 years.

Cost Factor	Approximate Time (2024 hardware)	Suitable For
10	~100ms	Development/testing
12	~400ms	Production minimum
14	~1.6s	High-security applications

Limitations: bcrypt truncates input at 72 bytes. Passwords longer than 72 characters are silently truncated — which means a 100-character passphrase provides no more security than its first 72 characters. It also cannot leverage more than a fixed amount of memory, making it less resistant to modern GPU attacks than Argon2.

scrypt — Memory-Hard Pioneer

scrypt (2009) introduced memory-hardness before Argon2. Designed by Colin Percival for the Tarsnap backup service. It’s still a solid choice, but Argon2id is preferred because scrypt’s memory-hardness parameter (N) is less granular and it lacks Argon2’s hybrid resistance to both GPU and side-channel attacks.

Salts — Why They’re Non-Negotiable

A salt is a random value prepended to the password before hashing, unique per user. Without salts:

Identical passwords produce identical hashes (rainbow table attacks)
An attacker can precompute hashes for common passwords and compare them against your entire database simultaneously
The RockYou breach (2009) stored 32 million passwords in plaintext — the published list became the foundation for every password cracking dictionary since

Requirements:

Cryptographically random (use os.urandom() or /dev/urandom, never Math.random())
Minimum 16 bytes (128 bits)
Unique per user, per password change
Stored alongside the hash (this is not a secret — its purpose is to defeat precomputation)

Modern algorithms (bcrypt, scrypt, Argon2) generate and embed salts automatically. If you’re implementing salt management manually, you’re probably using the wrong library.

Timing Attacks and Constant-Time Comparison

When verifying a password, naive string comparison (==) leaks information through timing. If the comparison fails on the first byte, it returns faster than if it fails on the last byte. An attacker making thousands of requests can statistically determine the correct hash byte-by-byte.

The defence is constant-time comparison — functions that always take the same amount of time regardless of where the mismatch occurs. Every major framework provides this:

Python: hmac.compare_digest()
Node.js: crypto.timingSafeEqual()
Go: subtle.ConstantTimeCompare()
Java: MessageDigest.isEqual()

Implementation note: Even with constant-time comparison, the hashing step itself has variable timing based on the input. This is acceptable — the timing variation reveals nothing about the stored hash, only about the submitted password (which the attacker already knows).

Password Policies — Length Over Complexity

NIST Special Publication 800-63B (Digital Identity Guidelines) overturned decades of conventional wisdom in 2017:

Old Policy (Deprecated)	NIST 800-63B Recommendation
Minimum 8 characters with uppercase, lowercase, number, symbol	Minimum 8 characters (15+ recommended), no composition rules
Forced rotation every 90 days	No periodic rotation unless compromise evidence
Security questions for recovery	Prohibited (answers are guessable/social-engineerable)
Password hints	Prohibited

Why? Composition rules produce predictable patterns (P@ssw0rd1!). Forced rotation produces incremental changes (Summer2024! → Autumn2024!). Length provides exponential entropy growth — a 20-character passphrase of random words defeats any brute-force attack regardless of character composition.

NCSC (UK National Cyber Security Centre) guidance aligns: “Help users cope with password overload” — allow password managers, stop penalising length, stop requiring rotation.

Credential Stuffing Defence

Credential stuffing attacks use leaked username/password pairs from other breaches against your platform. The haveibeenpwned database contains over 12 billion compromised accounts.

Defence Layers

Layer	Mechanism	Effectiveness
Compromised password check	Check against haveibeenpwned API (k-anonymity model) at registration and login	Blocks known-compromised passwords
Rate limiting	Maximum 5 failed attempts per account per 15 minutes	Slows automated attacks
IP reputation	Block/challenge requests from known botnet IPs	Reduces attack volume
Device fingerprinting	Challenge logins from unrecognised devices	Detects credential stuffing from new origins
CAPTCHA on threshold	Trigger after 3 failures	Blocks automated tooling

Troy Hunt’s haveibeenpwned Pwned Passwords API uses k-anonymity — you send only the first 5 characters of the SHA-1 hash of the password, receive all matching suffixes, and check locally. The full password never leaves your server. NIST 800-63B specifically requires checking passwords against known-compromised lists.

Implementation Checklist for Legal SaaS

Production checklist:

Use Argon2id (preferred) or bcrypt with cost factor ≥12
Never implement your own hashing — use established libraries (argon2-cffi, bcrypt, passlib)
Check passwords against haveibeenpwned at registration and periodic login
Enforce minimum 12 characters, no maximum below 128, no composition rules
Allow and encourage paste (password managers rely on it)
No forced rotation without evidence of compromise
Constant-time comparison for all credential verification
Log authentication failures with IP/user-agent (but NEVER log the attempted password)
Rate limit failed attempts per account and per IP

The Dropbox breach (2012, disclosed 2016) exposed 68 million bcrypt hashes. Despite the breach, bcrypt’s work factor meant mass cracking was economically impractical. Proper hashing doesn’t prevent breaches — it ensures breached data is useless.

Work Factor Calibration

Your hashing work factor should be calibrated to your hardware, targeting 200–500ms per hash on your authentication servers. OWASP’s guidance: “Err on the side of longer computation time.”

Recalibrate annually as hardware improves. When you increase the work factor, rehash existing passwords on next successful login — verify against the old hash, then silently upgrade to the new parameters. The user never notices; your security improves continuously.

Conclusion

Password hashing is a solved problem — but only if you use the solution. Argon2id with appropriate memory and iteration parameters. Salts generated automatically. Constant-time verification. Length-based policies without composition rules. Compromised credential checking via haveibeenpwned. And the work factor recalibrated annually.

The cost of getting this right is one afternoon of implementation. The cost of getting it wrong is 117 million cracked passwords and a breach notification to every client your platform serves.

Alice: Welcome back to Security for Legal SaaS. I’m Alice.

Dan: And I’m Dan. Episode 17 — Password Hashing Done Right. Alice, let me start with something I’ve heard developers say in interviews. “Don’t worry, our passwords are encrypted.” Why does that make you wince?

Alice: Because encryption is the wrong word and the wrong mechanism. Encryption is reversible — you encrypt data so you can decrypt it later. If your passwords are encrypted, that means somewhere in your infrastructure there’s a decryption key. Anyone who obtains that key — a disgruntled admin, an attacker who compromises your key management, a misconfigured backup — can decrypt every password in your database in one operation.

Dan: So what’s the correct approach?

Alice: Hashing. A hash function is a one-way mathematical transformation. You put the password in, you get a fixed-length output — the hash — and there is no mathematical way to reverse it back to the original password. When a user logs in, you hash what they typed and compare it to the stored hash. You never need to recover the original password. You never should be able to.

Dan: But not all hash functions are equal. LinkedIn learned that the hard way.

Alice: LinkedIn stored 117 million passwords hashed with unsalted SHA-1. SHA-1 is a general-purpose hash function designed to be fast. That’s exactly what you don’t want for password hashing. Fast means an attacker with a GPU — a graphics processing unit, the same chip used for gaming, which can run thousands of calculations in parallel — can compute billions of SHA-1 hashes per second. Within days of that breach, the majority of those passwords were cracked using dictionary attacks and rainbow tables.

Dan: What’s a rainbow table?

Alice: A precomputed lookup table. If I hash “password123” with SHA-1, I always get the same output. An attacker can compute hashes for millions of common passwords in advance, then just look up each hash in your breached database against their table. Instant match, instant crack. This is what salts defeat.

Dan: Explain salts.

Alice: A salt is a random value — at least 16 bytes — that’s unique to each user and generated fresh every time a password is set. You prepend it to the password before hashing. So “password123” with salt “a7f3b2...” produces a completely different hash than “password123” with salt “9c4e1d...”. Rainbow tables become useless because the attacker would need a separate table for every possible salt value. That’s computationally impossible.

Dan: Got it. So what algorithms should we actually be using?

Alice: The current recommendation from OWASP — the Open Web Application Security Project, the industry’s go-to source for web security standards — is Argon2id. It won the Password Hashing Competition in 2015, selected by a panel of cryptographers from 24 submissions. Its key innovation is memory-hardness — each hash computation requires a configurable amount of RAM. GPUs have thousands of cores but limited per-core memory. If each hash computation requires 19 megabytes of RAM, you can’t parallelise thousands of them on a GPU like you can with SHA-1 or even bcrypt.

Dan: What about bcrypt? I see it everywhere.

Alice: bcrypt is still acceptable — it’s been the industry workhorse since 1999. It introduced adaptive cost factors. You set a cost of 10, that’s 2-to-the-10 iterations. Cost 12 is four times slower than cost 10. You calibrate it so one hash takes about 200 to 500 milliseconds on your production hardware. That’s imperceptible to a user logging in, but devastates an attacker trying billions of combinations. The limitation is that bcrypt truncates passwords at 72 bytes and can’t leverage large amounts of memory.

Dan: And scrypt?

Alice: scrypt was the first memory-hard password hash, designed in 2009 by Colin Percival for his Tarsnap backup service. Still solid, still a valid choice. Argon2id is preferred because it combines memory-hardness with better resistance to both GPU attacks and side-channel attacks — timing leaks that could reveal information about the hash computation.

Dan: Let’s talk about timing attacks. That’s an interesting one.

Alice: When you compare the user’s submitted hash against the stored hash, a naive equality check — using double-equals in most languages — short-circuits. It returns false as soon as it finds the first differing byte. An attacker can measure response times. If the first byte matches but the second doesn’t, the response takes slightly longer than if the first byte was already wrong. Over thousands of requests, they can statistically determine the hash byte by byte.

Dan: That sounds impractical but I’m guessing it’s been demonstrated.

Alice: Repeatedly. The defence is constant-time comparison — a function that always examines every byte regardless of where the mismatch occurs. Python has hmac.compare_digest. Node has crypto.timingSafeEqual. Every major language provides one. Use it for all credential verification. Never write your own string comparison for security-sensitive values.

Dan: Now — password policies. I grew up with “must contain uppercase, lowercase, number, and special character.” NIST says that’s wrong now?

Alice: NIST — the U.S. National Institute of Standards and Technology, which sets widely adopted security benchmarks — their Special Publication 800-63B, published in 2017 and updated since, explicitly deprecated composition rules and forced rotation. Composition rules produce predictable patterns. When you require a capital letter, people capitalise the first character. When you require a number, they append 1. When you require a symbol, they use an exclamation mark. Attackers know these patterns. “P@ssw0rd1!” satisfies every composition rule and falls in seconds.

Dan: So what does NIST recommend instead?

Alice: Length. Minimum 8 characters — they recommend 15 or more. No maximum below 128. No composition rules. No forced rotation unless there’s evidence of compromise. Allow paste — because that’s how password managers work, and password managers are the single most effective credential hygiene tool. And critically — check every password at registration against known-compromised password lists.

Dan: Like haveibeenpwned.

Alice: Troy Hunt’s Pwned Passwords API contains over 900 million compromised passwords. The API uses a technique called k-anonymity — a privacy method where you only reveal partial information so the server never learns the full value. You send only the first five characters of the SHA-1 hash of the password. The API returns all matching suffixes. You check locally. The full password never leaves your server, and Troy Hunt never learns what password you’re checking. NIST 800-63B requires this check. If a user picks a password that’s appeared in previous breaches, reject it with a clear explanation and suggest they use a password manager.

Dan: For legal SaaS specifically — why does this matter more than average?

Alice: Lawyers reuse passwords. They manage dozens of systems — court filing portals, client management platforms, bar association accounts, your platform. A credential stuffing attack takes passwords leaked from one breach and tries them against your login. If a lawyer used the same password on your platform as they did on a breached service, the attacker walks right in. Rate limiting, device fingerprinting, CAPTCHA — those challenge-response tests that ask you to click traffic lights or type distorted letters to prove you’re human — after failed attempts — all necessary. But checking against compromised passwords at registration prevents the problem at the source.

Dan: One last thing — work factor calibration. How do you keep up with hardware improvements?

Alice: Annually, benchmark your hashing parameters on your authentication servers. Target 200 to 500 milliseconds per hash. When you increase the work factor, you don’t need to force password resets. On the next successful login — verify against the old hash, then silently re-hash with the new parameters and store the upgraded hash. The user never notices. Your security improves continuously. The Dropbox breach proved this works — 68 million bcrypt hashes were exposed, but bcrypt’s cost factor made mass cracking economically impractical.

Dan: Next episode — JWT Anatomy and Pitfalls. Spoiler: the “none” algorithm is exactly as terrifying as it sounds.

Alice: Until then, I’m Alice.

Dan: And I’m Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.