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
- Add a unique random salt per user, stored next to the hash. Identical passwords then produce different hashes, and precomputed tables are useless.
- 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.
- 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=LaxorStrict: 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
Related reading
- Pagelets Parallelize Server-side Processing at YelpYelp engineers · YelpCase Studies
- Server Side Rendering at WixWixYouTube
- MongoDB at Baidu: Multi-Tenant Cluster Storing 200+ Billion Documents across 160 ShardsMongodb engineers · MongodbCase Studies
- Secure Infrastructure To Store Bitcoin In The Cloud at CoinbaseCoinbase engineers · CoinbaseCase Studies
Show 6 moreShow fewer
- Sherpa: Distributed NoSQL Key-Value Store at YahooYahoo engineers · YahooCase Studies
- Akutan: Distributed Knowledge Graph Store at eBayeBay engineers · eBayCase Studies
- The Site Reliability WorkbookGoogle SRE team · O'Reilly / GoogleBooks
- Espresso: Distributed Document Store at LinkedInLinkedIn engineers · LinkedInCase Studies
- Datadog Engineering BlogDatadog engineers · DatadogBlogs
- Novoda Engineering BlogNovoda engineers · NovodaBlogs
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?
Try it: see a system in action
One tap in a real app already crosses a client, a server and a database. Watch it happen, then try scoping a brief a few different ways below.
The app
Email and password, typed once, never asked again this session
What just happened
Tap the button to send a real request.
One tap in the app sends a real request. Watch where it actually goes.
Go further: the Builder
Once you know what to ask, the Builder is where you turn requirements into an architecture. Come back to this once you've met a few more concepts.
Try it yourself
Your user table leaks. Compare the damage if passwords were stored (a) in plain text, (b) as unsalted SHA-256, (c) with Argon2 and a per-user salt.
Click what a strong design here would need:
More in Building blocks
© 2026 forcsguy.com. Original lesson text and diagrams. Books and sites linked above belong to their authors.