Storing passwords and managing sessions

Hashing, salting and slow password hashes, plus how sessions and tokens keep users signed in safely.

On the roadmap:Beginner · step 3: Secure the basics

Lesson 6 of 23 · 9 min read · quiz · exercise

Never store the password

You do not need to know a user's password, only to check it. So store a one-way hash of it.

Why plain hashes are not enough

General-purpose hashes (MD5, SHA-256) are built to be fast. An attacker with your leaked hashes can try billions of guesses per second, and use precomputed tables (rainbow tables) for common passwords.

What to do instead

  1. Add a unique random salt per user, stored next to the hash. Identical passwords then produce different hashes, and precomputed tables are useless.
  2. Use a password hashing function designed to be slow and memory-hungry: Argon2id, bcrypt or scrypt, with a work factor you raise as hardware improves.
  3. Optionally add a server-side secret ("pepper") kept outside the database.

Figure SDA-CORE-06-1 · What to do instead · © forcsguy.com

Sessions: staying signed in

After login, the server must recognise the user on later requests.

  • Server-side session: the server stores session data and gives the browser an unguessable session ID in a cookie. Easy to revoke (delete the record).
  • Token-based (for example JWT): the server signs a token containing the user's identity and the client sends it each time. No lookup is needed, but revoking one before it expires is hard, so keep lifetimes short and use refresh tokens.

Neither is automatically better. Server-side sessions are simpler and safer for typical web apps; tokens suit APIs and service-to-service calls.

Cookie settings that matter

  • HttpOnly: scripts cannot read it, which limits damage from cross-site scripting.
  • Secure: only sent over HTTPS.
  • SameSite=Lax or Strict: reduces cross-site request forgery.
  • A sensible expiry, and a new session ID after login to prevent session fixation.

Other protections

  • Rate limit login attempts and add lockout or delays.
  • Offer multi-factor authentication.
  • Compare secrets with a constant-time comparison.
  • Reset passwords with short-lived, single-use links sent to a verified email.
  • Never log passwords or tokens.

Real-world reading

Check your understanding

Question 1 of 3

0 correct so far

Why must passwords be hashed with a slow, salted algorithm such as bcrypt or Argon2?

© 2026 forcsguy.com. Original lesson text and diagrams. Books and sites linked above belong to their authors.