Overview
Authentication answers "who are you?", and the login flow is where that question is resolved. Because login is the gateway to an account, its design is a prime security concern. This lesson covers login flows and their common weaknesses.
Learning objectives
- Describe a typical login flow.
- Identify security requirements at each step.
- Recognize common login-flow weaknesses.
Core concept
A login flow verifies a user's identity, usually by checking a submitted credential (password, and ideally a second factor) against stored data, then establishing a session. Key security requirements:
- Verify credentials server-side against securely stored secrets.
- Return generic error messages that do not reveal whether the username or the password was wrong (anti-enumeration).
- Apply rate limiting / lockout to resist brute force.
- Regenerate the session ID on successful login (anti-fixation).
- Transmit credentials only over HTTPS.
How it works
The user submits credentials; the server looks up the account and verifies the password against its stored hash (never a plaintext or reversible form — see the password-storage lesson), optionally checks a second factor, and on success creates/regenerates a session. Each requirement defends a specific weakness: generic errors prevent username enumeration, rate limiting slows guessing, HTTPS prevents interception, and session regeneration prevents fixation. The flow must assume the client is hostile and enforce every check on the server.
Practical example
A robust login: the form posts over HTTPS; the server verifies the password hash; on failure it returns "invalid username or password" (identical whether the user exists or not); after several failures it rate-limits or temporarily locks the attempt source/account; on success it regenerates the session and sets a protected cookie. A weak login might say "no such user" vs "wrong password" — letting an attacker enumerate valid usernames — and impose no rate limit, enabling brute force.
Cybersecurity relevance
Login flows are heavily attacked: credential brute-forcing, credential stuffing (reusing breached passwords), and username enumeration are common. Defenses — generic errors, rate limiting/lockout, MFA, secure password storage, HTTPS, and session regeneration — directly counter these. Testers probe login for enumeration (differing responses/timing), missing rate limits, and weak session handling. This lesson frames the credential-storage, MFA, and reset topics that follow.
Common mistakes
- Distinct error messages for "unknown user" vs "wrong password," enabling enumeration.
- No rate limiting or lockout, allowing unlimited guessing.
- Not regenerating the session on login, leaving fixation exposure.
Key takeaways
- A login flow verifies identity server-side and establishes a session; it must use secure credential storage, generic errors, rate limiting, HTTPS, and session regeneration.
- Generic error messages prevent username enumeration; rate limiting/lockout resists brute force; regeneration prevents fixation.
- Login is heavily targeted (brute force, credential stuffing, enumeration); its controls directly counter these and are standard assessment checkpoints.
Check your understanding
- Why should a login return the same error message whether the username or the password is incorrect?
- Name two controls that defend a login flow against automated password guessing.