Authentication verifies identity, and session management maintains that authenticated state across subsequent requests, usually by issuing a session ID cookie. The two must not be confused: a strong login cannot save an application whose session IDs are guessable, reused, or never rotated. Session token entropy should be at least 128 bits drawn from a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG) like /dev/urandom or crypto.randomBytes, not from generic RNGs such as rand() or Math.random(). After login, the session ID should be rotated to defeat session fixation, where an attacker plants a known identifier on the victim beforehand. Storing privileged state in the session (and never in client-side tokens that the server does not re-check) helps prevent privilege escalation, and sending a clear audit trail of important actions supports investigation and accountability.
Password storage is its own discipline because hashes leak. Secure storage uses strong one-way hashing with a unique salt per password so precomputed rainbow tables are useless. Password stretching (bcrypt cost, PBKDF2 iteration count, or Argon2) makes each guess expensive, and modern APIs like PHP's password_hash with PASSWORD_BCRYPT or PASSWORD_ARGON2ID handle salts and algorithm choice correctly. Plain SHA-256 is far too fast for password hashing — GPUs can test billions per second. A pepper is a server-side secret added on top of the salt: even if the database is stolen, attackers without the pepper cannot crack hashes offline. Comparisons of hashes and HMACs must run in constant time to avoid timing oracles that leak information byte by byte, and authentication code paths should avoid revealing whether the username or the password was wrong in measurably different ways.
Cookies carry this session state and must be configured defensively. Secure means HTTPS-only, HttpOnly blocks JavaScript access (reducing the impact of XSS), and SameSite restricts cross-site sending. SameSite=Strict prevents the cookie from being sent on any cross-site request, including top-level navigations, breaking some login flows but maximizing CSRF protection; SameSite=Lax allows the cookie on top-level navigations but blocks most other cross-site requests, balancing usability and security. Cookie name prefixes add further guarantees: __Host- requires Secure, no Domain attribute, and Path=/ (binding the cookie to the exact host, preventing subdomain cookie tossing), while __Secure- requires Secure so the cookie cannot be silently downgraded to HTTP.
Beyond cookies, CSRF defenses often rely on tokens. The synchronizer token pattern binds a random CSRF token to the user's session and rejects state-changing requests without a valid match. The double-submit cookie pattern sets a CSRF cookie and expects the client to echo its value in a header; because attackers cannot read the cookie cross-site, the values will not match. SameSite=Lax already blocks many cross-site POSTs, but legacy apps and certain flows still need explicit tokens for defense in depth. Multi-factor authentication (MFA) strengthens login but is not a silver bullet: push-based MFA is vulnerable to MFA fatigue (spamming the user until they approve), browsers and password managers are vulnerable to session theft after MFA, and phishing sites can still capture one-time codes — phishing-resistant factors like FIDO2/WebAuthn security keys and device-bound passkeys bind the credential to the legitimate origin. Security questions are a weak factor because they rely on public or guessable facts. CAPTCHAs slow automated abuse like credential stuffing but are increasingly bypassable and should be one layer, not the only one.