Lesson 43 · Web and backend

Logins: authentication and sessions

When you log in, a website has to answer two questions: who are you, and what may you do? Follow Ada through signing up, logging in and staying logged in. The server never keeps her password, only a salted, slow hash; after a successful login it starts a session and hands her browser a session ID in a protected cookie. Then see two common additions: signed tokens (JWT) and a second factor.

12 min11 steps5 questionsIntermediate

Fig 43 · Interactive

Loading figure…

or ← →

Check yourself

5 quick questions

Pick an answer to see why. Your score saves with your progress.

01Ada is logged in and tries to open Ben's inbox. The server refuses. Which check said no?

The server already knows who she is (authentication). Authorization decides what she may do, and Ben's inbox is not hers.

02What should a server store so it can check Ada's password later?

A hash cannot be turned back into the password. The salt makes equal passwords hash differently, and a slow algorithm makes guessing very costly. OWASP recommends exactly this.

03At login, how does the server know the typed password is right?

Hashing works one way only. The same password with the same salt and settings always gives the same hash, so equal hashes mean the right password.

04Why is the session cookie marked HttpOnly?

HttpOnly hides the cookie from JavaScript (document.cookie). Secure is the flag that keeps it to HTTPS.

05A site uses JSON Web Tokens instead of a session table. What is one downside?

The server trusts any token with a valid signature until its expiry time, unless it also keeps a block list. A session row can simply be deleted.

Key terms

Glossary

Authentication: Checking who someone is, for example by a password, and on later requests by a session cookie.
Authorization: Deciding what an authenticated user may do, such as reading only their own messages. Always checked on the server.
Hash: A one-way function: easy to compute from the input, practically impossible to turn back. The same input always gives the same hash.
Salt: Random bytes stored next to a password hash and mixed into it, so equal passwords get different hashes.
Session: The server's memory that a browser has logged in: a row with a random session ID, the user and an expiry.
Cookie: A small name=value pair a server asks the browser to keep and send back with later requests to the same site.
JSON Web Token (JWT): A signed token that carries claims such as the user and an expiry time; the server checks the signature instead of a table.
Multi-factor authentication: Logging in with two kinds of proof, such as a password (something you know) and a phone or security key (something you have).

Fine print

Notes and sources

The salt in the figure is fixed so you can check the numbers; a real server draws a new random salt for every password, so two people with the same password still get different hashes.
slow_hash on the card is Python's hashlib.scrypt with OWASP's minimum settings (n=2**17, r=8, p=1), which needs 128 MiB of memory per try. That cost is small for one login and huge for someone trying billions of guesses. Argon2id is OWASP's first choice where it is available.
A real session ID comes from secrets.token_urlsafe(32): 256 random bits, written as 43 URL-safe characters. The one in the figure is a fixed example.
Passwords and cookies are only safe on the way because the connection is HTTPS. Over plain HTTP anyone on the network could read them.
Real sites add more: a new session ID right after login, limits on repeated failed logins, and checks that every request is allowed, not just logged in.

Quiz Unlocks after the last step.