Broken Authentication and Sessions

The Problem of Identity

Authentication is the process of verifying that a user is who they claim to be. Session management is what keeps that identity across requests. When either one fails, an attacker can impersonate another user, and all the other security controls become irrelevant. The OWASP Top 10 groups these failures under A07:2021 — Identification and Authentication Failures (formerly "Broken Authentication").

These failures are especially dangerous because they attack the application's trust boundary directly. It does not matter how well protected your data is if an attacker can simply log in as a legitimate user, or worse, as an administrator. That is why authentication and session management deserve careful design and constant review.

Brute Force and Credential Stuffing

The most direct attack against authentication is brute force: trying many username and password combinations until one works. A more efficient variant is the dictionary attack, which tries common, well-known passwords instead of every possible combination. If the application does not limit attempts, an automated attacker can try millions of passwords.

Credential stuffing is today one of the most prevalent threats. It exploits the fact that people reuse passwords: the attacker takes lists of credentials leaked in other breaches and tries them en masse against your application. Since the credentials are valid somewhere, a fraction will also work on yours. To defend yourself you need rate limiting, temporary account lockout after several failures, CAPTCHA in the face of suspicious behavior, and detection of credentials known to be compromised.

Secure Session Handling

Once the user authenticates, the application issues a session identifier. If that identifier is compromised, the attacker hijacks the session with no need for the password. There are several classic mistakes to avoid. Session fixation occurs when the application does not generate a new identifier after login, allowing an attacker to fix a known value before the victim logs in.

For secure handling: generate long, random session identifiers with a cryptographically secure generator, regenerate the identifier after each authentication, always transmit it over HTTPS, and configure cookies with the HttpOnly, Secure, and SameSite attributes. Implement session expiration on inactivity and a logout that truly invalidates the session on the server, not just in the browser. These details, described in lesson 1, are the difference between a robust session and a trivially hijackable one.

Credential Storage and MFA

Passwords must never be stored in plain text or with reversible encryption. They must be stored using a password-specific hashing function like bcrypt, scrypt, or Argon2, which are deliberately slow and resistant to attacks with specialized hardware. Each password must carry a unique salt to prevent the use of precomputed tables (rainbow tables). Using fast hashes like MD5 or SHA-1 for passwords is a serious and frequent mistake.

The most effective measure to reduce the impact of stolen credentials is multi-factor authentication (MFA). By requiring a second factor (a TOTP code app, a FIDO2 security key, or similar) in addition to the password, even a compromised password is not enough to get in. MFA on its own neutralizes most credential stuffing and password phishing attacks, and it should be mandatory for all administrative accounts.

Designing Robust Authentication

Building secure authentication from scratch is difficult and error-prone, so the general recommendation is to lean on proven solutions: mature authentication frameworks, identity providers, and standards like OAuth 2.0 and OpenID Connect, rather than inventing your own scheme. These systems already correctly solve token management, expiration, and rotation.

Complement the design with good policies: require sufficiently long passwords instead of arbitrary complexity rules, check new passwords against lists of leaked passwords, offer secure account recovery that does not reveal whether a user exists, and log and monitor failed login attempts to detect attacks in progress. To validate your defenses, use tools like Burp Suite to analyze the login flow and session management, and consult the OWASP authentication guidance as a reference. Authentication is the front door: it is worth protecting it rigorously.