Chapter 3 · Authentication & Access· Beginner· ~11 min

Passwords in Practice

Passwords are the worst kind of secret, except for everything else we've tried. How they go wrong, and how to make them go wrong less often.

You will learn

  • What "password strength" really measures
  • How servers should (and shouldn't) store passwords
  • Why "salted hash" is non-negotiable, and what bcrypt does extra
  • The practical fix that beats almost everything else: a password manager plus MFA

Where strength comes from

A password's strength is its entropy, how many guesses an attacker would need to find it. Length matters more than character variety: a 20-character all-lowercase passphrase is harder to crack than an 8-character mixed mess.

The mental model: assume an attacker has the password file and runs an offline cracker at billions of guesses per second per GPU. Your password needs enough entropy that, even at that rate, the attacker would run out of patience or money before finding it.

How sites should store them

Storing passwords in plain text is indefensible. Storing them encrypted is only slightly better, because anyone with the database also tends to have the key.

The right approach is to store a slow, salted hash of each password. Three pieces:

  • Hash: a one-way function. Even with the file, the attacker can't reverse it.
  • Salt: a unique random value added to each password before hashing. Means two users with the same password get different hashes, and pre-computed "rainbow tables" are useless.
  • Slow: bcrypt, scrypt, or Argon2. They have a tunable cost parameter that makes each guess take many milliseconds, multiplying an attacker's cost.

Plain SHA-256 is not slow enough

A modern GPU can compute billions of SHA-256 hashes per second. That's a great hash for integrity checks and a terrible one for passwords. Use bcrypt/scrypt/Argon2.

What goes wrong in practice

  • Reuse. One site is breached; the same email and password are tried on a hundred others (this is called credential stuffing). Reuse is the single most common cause of account takeovers.
  • Common patterns. Names, dates, "P@ssw0rd!", keyboard runs. All on the cracker's wordlist.
  • Theft. A keylogger, a fake login page, a friend looking over your shoulder.
  • Forced rotation. Modern guidance (e.g. NIST SP 800-63) says don't force regular password changes; they push users toward worse choices.

What actually works

Two changes wipe out most of the threat:

  1. Use a password manager. Generate long, unique, random passwords for every site. You only have to remember one master password, which you should make a long passphrase.
  2. Turn on multi-factor authentication. Even if your password leaks, a second factor (hardware key or app-generated code) usually stops the attacker cold.

Passphrases beat "complex" passwords

Four random unrelated words (think copper-violin-orbit-banana) are easy to type, easy to remember, and far stronger than P@55w0rd!.

For people building sites

The current sensible defaults:

  • Minimum length of 12; no upper bound (allow long passphrases).
  • Check submitted passwords against the Have I Been Pwned breach list (k-anonymity API).
  • Store as bcrypt (cost 12+), scrypt, or Argon2id.
  • Rate-limit failed attempts; lock or back off rather than forcing CAPTCHA.
  • Encourage (or require) MFA. Use WebAuthn for high-value accounts.
  • Don't force scheduled rotation; do force it on suspicion of compromise.