OWASP A07
Testing for Authentication Failures
Login pages are usually well built. The failures are in everything around them — session lifecycle, account recovery, multi-factor fallbacks and the single sign-on integration nobody re-tested.
- Full session lifecycle, not just the login form
- MFA and recovery flows tested as bypass paths
- Includes OAuth and SAML integration handling
What authentication failures looks like in a real application
An application enforces multi-factor authentication properly at login. It also offers a "trouble receiving your code?" link that emails a magic sign-in link, which does not require the second factor. The strong control is present and the weaker parallel path around it is what an attacker will use. Every serious authentication finding we report has this shape.
The authentication failures variants we test for
Session lifecycle
- Session fixation, and whether the identifier is rotated on privilege change
- Whether logout invalidates server-side state or only clears the client cookie
- Session survival after password change, email change, MFA enrolment and account suspension
- Absolute and idle timeout behaviour, and concurrent session handling across devices
- Cookie attributes, and whether token scope is wider than the subdomain that needs it
Credential and enumeration attacks
- Username enumeration through response differences, timing and error wording — including registration and reset, which are often overlooked
- Rate limiting resilience: whether limits are per account, per IP, or bypassable by rotating either
- Credential stuffing resistance and behaviour under distributed low-rate attempts
- Password policy in practice, including whether known-breached passwords are rejected
Multi-factor and recovery
- Bypasses via alternate flows: magic links, backup codes, trusted devices and support-assisted recovery
- Whether the second factor is verified server-side or merely displayed
- Enrolment and reset of factors — frequently protected more weakly than login itself
- Reset token entropy, single use, expiry, and whether the token is bound to the requesting session
- Host header influence on reset links, which can send a valid token to an attacker's domain
Federated identity
- OAuth redirect URI validation, state parameter handling and authorisation code reuse
- SAML assertion signature verification, replay windows and audience restriction
- Account linking, where an unverified email can attach an attacker's identity to an existing account
How we test for authentication failures
We treat authentication as a lifecycle rather than an entry point. Each state transition — register, log in, elevate, change credential, enrol factor, recover, log out, suspend — is tested for whether the resulting session correctly reflects the new state. The most productive findings come from transitions, because they are where implementations forget to revoke something.
Recovery flows get disproportionate attention, since they exist to let someone in without their credentials and are frequently the weakest path to a full takeover.
How authentication failures gets fixed
- Keep session state server-side so revocation is immediate and real
- Rotate the session identifier on every privilege change, and invalidate all sessions on credential change
- Require the existing second factor to change or remove a second factor
- Ensure every alternate access path meets the strength of the primary one, or remove it
- Bind reset tokens to a single use, a short expiry and the requesting context, and build links from server configuration rather than the Host header
- Rate limit per account as well as per address, and monitor for distributed low-rate attempts
Common questions
We have multi-factor authentication. Is that not sufficient?
It closes the main door and is worth having. The findings we report are usually in the paths built around it: recovery links that skip it, factor enrolment protected only by a session, support tooling that can authenticate on a user's behalf, and API tokens issued before the factor was required. Multi-factor authentication is only as strong as the weakest way to obtain a session without it.
Is username enumeration worth fixing?
On its own it is low severity. It matters as a multiplier: a confirmed user list makes credential stuffing and targeted phishing far more efficient, and it frequently combines with a weak rate limit into a genuinely serious path. We report it with that context rather than as a standalone item, and note that eliminating it entirely often conflicts with usability.
Do you test our identity provider as well?
We test your integration with it, which is where the findings almost always are: redirect validation, state handling, assertion verification and account linking. The provider's own infrastructure is out of scope unless you operate it yourself, in which case we scope it explicitly.
How should session timeouts be configured?
Both an idle timeout and an absolute maximum lifetime, with the values driven by what the session can do rather than by convenience. An administrative session that can move money warrants a short idle timeout and step-up authentication for sensitive actions. The more important property is that expiry is enforced server-side, since a client-side timer stops nothing.
Do you test our password reset flow?
Always, because it exists specifically to grant access without credentials and is frequently the weakest route to a full account takeover. We check token entropy, single use, expiry, whether the token is bound to the requesting session, whether the reset link is built from server configuration rather than the Host header, and whether the flow reveals which addresses are registered.
Are magic links less secure than passwords?
Not inherently, and they remove password reuse risk entirely. The security depends on the delivery channel and the token: an emailed link inherits the security of that mailbox, and if the token is long-lived, reusable or not bound to the requesting device, it becomes a durable credential sitting in an inbox. Treated as a single-use short-lived token, they are a reasonable design.
Do you test single sign-on and social login?
Yes, and the findings are almost always in your integration rather than in the provider. We test redirect URI validation, state parameter handling, authorisation code reuse, assertion signature verification and audience restriction. Account linking gets particular attention, because an unverified email address is frequently enough to attach an attacker's identity to an existing account.
Let's scope your infrastructure.
Tell us what you have built and what you are testing against. You will speak to a Lead Security Architect, not a sales desk, and you will get a written scope with a fixed price before any work begins.