Broken authentication: testing authentication and session weaknesses in a pentest

Broken access control has received the most attention since the latest OWASP Top 10, but authentication and session weaknesses remain a category where we almost always find something during web application pentests. The category is formally called "Identification and Authentication Failures" (A07) in the OWASP Top 10, but informally we still refer to it as broken authentication. It covers everything that goes wrong around the question "are you who you say you are" and "how do we hold on to that identity throughout a session". A flaw here is rarely theoretical: it almost always leads to full account takeover. In this article we describe the weaknesses we see most often in practice, how a pentester tests for them and which measures actually help.

## Why authentication so often goes wrong

Authentication looks like a solved problem. There are mature frameworks, identity providers and libraries that do the heavy lifting. Yet it regularly goes wrong, for a number of recurring reasons. Developers build their own login flow because the standard solution did not quite fit. A registration or password reset function is thrown together faster than the actual login and receives less attention. Or an application has grown over the years, with new authentication methods added without the old ones being properly retired. The result is that the attack surface around authentication is broader than just the login screen.

Important to understand: authentication and session management are two sides of the same coin. Authentication proves once who you are, session management ensures the application remembers that proof on every subsequent request. A strong login with weak session management is just as leaky as a weak login. That is why we always test them together.

## The weaknesses we encounter most often

### Missing protection against brute force and credential stuffing

Many applications barely limit the number of login attempts. That enables not only classic brute force, but especially credential stuffing: the automated trying of username and password combinations from earlier data breaches. Because people reuse passwords, this is in practice one of the most successful attack methods.

### Weak password policy and predictable recovery mechanisms

Applications that accept short or common passwords lower the bar for an attacker. At least as risky is the password reset function. Predictable reset tokens, tokens that do not expire, or a "secret question" with an answer that can be found on LinkedIn give an attacker a back door that bypasses the actual login entirely.

### Multifactor authentication that can be bypassed

MFA is a strong measure, but only if it is implemented correctly. We encounter implementations where the second factor can be skipped via a request parameter, where the MFA check happens client-side, or where the one-time passcode can be tried an unlimited number of times. The recovery path around MFA is also a classic weak point: if you can reset MFA with just an email address, the added value is limited.

### Session tokens that are not secure

A session token should be unpredictable, sufficiently long and random. We still see tokens that contain incrementing numbers, or that reveal information about the user. The way tokens are stored also matters: a session cookie without the HttpOnly, Secure and SameSite attributes is vulnerable to theft via cross-site scripting or over unencrypted connections.

### Sessions that do not end correctly

A common mistake is that logging out does not invalidate the session on the server side. The token then remains usable, even after the user thinks they have logged out. Other variants: sessions without expiry, sessions that stay active after a password change, and the absence of session renewal after a successful login, which enables session fixation.

## How a pentester tests this

Our approach starts by fully mapping the authentication functionality: registration, login, password reset, MFA enrollment, session expiry and logout. Each of those flows is a potential access path.

For brute force and rate limiting we look at how many attempts an application allows and whether there is a delay, a lockout or a captcha after a number of failed attempts. We pay attention to subtle differences in error messages. An application that shows "user does not exist" for an unknown user and "incorrect password" for an existing user unintentionally reveals which accounts exist. This is called user enumeration and speeds up a targeted attack.

We examine session tokens for randomness and structure. We collect multiple tokens and analyze whether there is a pattern. We check the cookie attributes, test whether a token still works after logout, whether an old session remains valid after a password change, and whether the application issues a new token after a successful login. For MFA we try to bypass the second factor by manipulating requests, and we test whether the one-time passcode is bound to a limit.

Crucially, we do not only establish findings technically, but also demonstrate their actual impact. An attack chain in which user enumeration, missing rate limiting and a weak password policy together lead to account takeover is far more convincing for a client than three separate observations. That context also determines the priority in remediation.

## How to prevent it structurally

The most important measure is to not build authentication yourself where a mature alternative exists. Use a proven identity provider or framework and keep it up to date. Implement rate limiting and protection against credential stuffing everywhere, and consider checking passwords against known breaches. Apply a password policy that aligns with modern guidance: length over complexity, and no forced periodic changes without cause.

Enable multifactor authentication for sensitive functions and implement it server-side, with a limit on the number of attempts. Ensure session tokens are random and sufficiently long, store them in cookies with HttpOnly, Secure and SameSite, and issue a new token after every login. Invalidate sessions server-side on logout, after a password change and after a period of inactivity. Treat password reset with the same care as the login itself, with short-lived, single-use tokens.

Finally: have these measures tested periodically. Authentication changes along with the application, and a pentest is the way to establish whether the theory also holds in practice. After remediation we perform a retest as standard to confirm that the findings have actually been resolved and that no new weaknesses have been introduced.

Secure Audit performs web application pentests in which authentication and session management are a fixed part of the scope. We deliver concrete, reproducible findings with remediation advice and a retest. Get in touch for a no-obligation conversation about your application.