2.Store the Smoothie, Not the Fruit

The Problem in Real Life

Storing Passwords vs. Storing Something You Can't Turn Back

Passwords, Hashing and Multi-Factor Authentication

• Username and password — the oldest lock: the user gives an identity (username or email) and a secret only they should know. Simple, familiar — and weak on its own, because people choose short passwords and reuse them everywhere.
• Never store passwords: a website must never store your actual password, not even encrypted. If the database is stolen — and databases do get stolen — every password would be exposed.
• Password hashing — store the smoothie: when you sign up, the server runs your password through a hash function and stores only the result. When you log in, it hashes what you typed and compares the two smoothies. If they match, the password was right. The server never needs to know your real password.
• Salt — a secret extra ingredient per person: if two fans both use summer2024, their hashes would be identical, and attackers have huge pre-made lists of hashes for common passwords. So the server adds a random salt — a different extra ingredient for each user — before hashing. Same password, completely different smoothies.
• Slow on purpose — bcrypt and Argon2: normal hash functions are designed to be fast. For passwords, fast is bad: an attacker with a stolen database could try billions of guesses per second. Password hashing functions like bcrypt and Argon2 are deliberately slow (a fraction of a second each) — unnoticeable when you log in, but it makes guessing billions of passwords take years.
• Credential stuffing — Sunday night's attack: attackers take email-and-password pairs leaked from other sites and try them automatically on yours. Hashing doesn't help here — the passwords are correct! What helps: MFA, detecting many failed logins, and checking new passwords against lists of known-leaked ones.
• MFA — something you know, have or are: multi-factor authentication asks for two different kinds of proof: something you know (a password), something you have (your phone, a security key) and something you are (fingerprint, face). Like a bank card: the card alone isn't enough, the PIN alone isn't enough. A stolen password without your phone is useless.

import bcrypt from "bcrypt";

// Sign up: store only the hash (bcrypt adds a random salt itself)
const passwordHash = await bcrypt.hash(password, 12);   // 12 = how slow
await db.query("INSERT INTO users (email, password_hash) VALUES ($1, $2)", [email, passwordHash]);

// Log in: hash what was typed and compare
const user = await findUserByEmail(email);
const ok = user && (await bcrypt.compare(typedPassword, user.password_hash));
if (!ok) {
  return res.status(401).json({ error: "Wrong email or password" });  // don't say which one
}