Sessions: the part of authentication that is usually wrong

Authentication answers who someone is, once. A session answers it on every subsequent request, for as long as it lives. The second mechanism handles thousands of times more traffic than the first and receives a fraction of the attention.

Where the session token goes

This is the decision everything else follows from, and the popular answer is the wrong one.

The argument for local storage is that cookies are vulnerable to cross-site request forgery. That is true and it has a standard, cheap fix. The argument against local storage is that any script injection anywhere on the origin — including in a dependency you did not write — can read the token and exfiltrate it. That has no fix at all.

// Every attribute here is doing something. None is optional.
cookies().set("session", token, {
  httpOnly: true,   // JavaScript cannot read it — the XSS mitigation
  secure:   true,   // HTTPS only, so it is never sent in plaintext
  sameSite: "lax",  // not sent on cross-site POSTs — the CSRF mitigation
  path:     "/",    // scope it as narrowly as the app allows
  maxAge:   60 * 60 * 8,
  // domain omitted deliberately: setting a parent domain shares the
  // cookie with every subdomain, including any you do not control.
});

Rotate the session at every privilege change

Session fixation works by getting a known session identifier into a victim's browser before they authenticate, then reusing it afterwards. The defence is to issue a new identifier whenever the trust level of the session changes.

• On login — never carry the pre-authentication identifier into an authenticated session
• On privilege elevation — entering an admin area, assuming another role, switching organisation
• On password or MFA change — and invalidate every other active session at the same time
• Periodically for long sessions — so a stolen token has a bounded useful life

Rotation on password change is the one most often missed, and it is the one users implicitly expect. Someone who changes their password because they believe their account is compromised has taken the action they think ends the attacker's access. If the attacker's session survives it, the interface has lied to them.

Logout must revoke server-side

Clearing a cookie is a client-side hint. If the token is a self-contained signed value with a long expiry, a copy taken earlier remains valid until it expires, and logout has accomplished nothing against the only attacker who matters.

If short-lived access tokens with refresh are the right model, rotate the refresh token on every use and detect reuse. A refresh token presented twice means one of the two holders is not the legitimate user, and the correct response is to invalidate the whole family rather than to serve both.

Password storage, briefly

This is settled territory, so the only real risk is improvising. Use a purpose-built password hash with a per-password salt and a deliberately high cost, and use a maintained library rather than composing primitives.

• Argon2id where available, otherwise scrypt or bcrypt — all three are acceptable; general-purpose hashes are not
• Never SHA-256, MD5 or any fast hash, salted or otherwise — speed is the vulnerability
• A long minimum length rather than composition rules; character-class requirements produce predictable substitutions
• Check candidates against a breached-password corpus, which excludes far more real-world guesses than any complexity rule
• Never truncate, never block paste, and never impose a maximum short enough to rule out a passphrase

Do not leak which accounts exist

Login, registration and password-reset flows commonly reveal whether an address is registered — through the message, the status code, or how long the response takes. That turns any address list into a membership list, which is both a privacy problem and the first step in a credential-stuffing campaign.

Leaks membership:
  Login:    "No account found with that email"
  Reset:    "That email is not registered"
  Register: "Email already in use"

Does not:
  Login:    "Email or password is incorrect"
  Reset:    "If that email has an account, we have sent a link"
  Register: "Check your email to continue"   <- then mail either a
            verification link or a "someone tried to register with
            your address" notice, depending on which case it was.

Also leaks: returning faster for an unknown address because no hash
was computed. Verify against a dummy hash so both paths cost the same.

What to verify before launch

1. 01The session cookie carries httpOnly, secure and an explicit sameSite, and no token is in local storage.
2. 02The session identifier changes on login, on privilege elevation and on password change.
3. 03Logout revokes server-side, verified by replaying a captured request afterwards and confirming it fails.
4. 04Changing a password invalidates every other active session, and the interface says so.
5. 05Login and reset are rate-limited per address and per source, with lockout that cannot be used to deny a real user access.
6. 06Error messages reveal nothing about which accounts exist, and both branches take comparable time.
7. 07Every authorisation check happens server-side; a hidden interface element is not an access control.

Item three is the one worth doing by hand. Capture an authenticated request, log out, replay it. A surprising number of systems answer it happily, and that single observation tells you whether logout is a security control or a visual one.