Security
Password Hashing
Passwords are never encrypted — they are hashed with algorithms designed to be slow: bcrypt, scrypt or Argon2, salted per user, with a tunable work factor that keeps cracking expensive as hardware improves. Fast hashes like SHA-256 are exactly wrong for this job. When the database leaks, the work factor decides whether it is a bad week or a headline.
Purpose
Storing passwords means planning for the breach: assume the table leaks, and ask what the attacker can do with it. Encryption is wrong (the key leaks with the data); fast hashes are wrong (GPUs try billions of SHA-256 guesses per second). Password hashing uses deliberately slow, memory-hard functions so each guess costs real compute — the defence is priced in attacker dollars per password.
When to Use It
Any system holding credentials, plus the adjacent cases teams forget: API keys and reset tokens (a fast hash is acceptable there only because they are high-entropy random strings, unlike human passwords), and legacy databases mid-migration from MD5 — a solvable problem, not a rewrite.
Trade-offs
The work factor is a genuine dial between security and login latency — too low is crackable, too high melts your CPU under a login stampede and hands attackers a denial-of-service lever. Argon2's memory-hardness blunts GPU farms but costs server RAM per concurrent login. And hashing protects the stored password only: phishing, reuse and weak passwords need other tools (MFA, breach-list checks).
Implementation
Use Argon2id (or bcrypt with cost ≥ 12) via a maintained library — salting is automatic; never construct your own scheme. Calibrate the work factor to a few hundred milliseconds on production hardware and re-tune periodically. Upgrade legacy hashes opportunistically: verify against the old hash at login, then re-hash with the modern algorithm. Add a breach-corpus check at registration, and rate-limit login attempts — offline cracking is not the only path.