Broken authentication is one of the most exploited vulnerability classes in web applications, and it consistently appears near the top of every major threat list including the OWASP Top 10. When authentication mechanisms fail – whether due to weak session management, missing account lockout, or insecure token handling – attackers gain a direct path to user accounts and sensitive data without needing to bypass firewalls or exploit complex code paths.
Security teams and developers who take broken authentication seriously can prevent account takeovers, data breaches, and regulatory violations before they happen. This article covers what broken authentication looks like in practice, how to detect it through testing and scanning, and what concrete steps to take to fix the most common weaknesses.
What Broken Authentication Actually Means
Broken authentication is not a single vulnerability – it’s a category covering any flaw in how a system verifies identity, manages sessions, or handles credentials. OWASP defines it broadly to include weak password policies, improper session expiration, insecure token storage, missing multi-factor authentication, and predictable session IDs.
The term is sometimes misunderstood as meaning “the login page is broken.” In reality, the login page may work perfectly while the authentication logic behind it is deeply flawed. A system can accept valid credentials, issue a session token, and still be completely vulnerable if that token is predictable, long-lived, or transmitted insecurely.
Common Attack Vectors Targeting Authentication
Credential stuffing and brute force attacks are the most straightforward: automated tools cycle through username and password combinations at scale. Without account lockout or rate limiting, these attacks succeed with minimal effort.
Session fixation is less commonly discussed but equally dangerous. An attacker sets a known session ID before a user logs in, then waits for the user to authenticate. If the application doesn’t regenerate the session ID post-login, the attacker now shares an authenticated session.
Insecure “remember me” tokens are another frequent culprit. Tokens that are predictable, not rotated, or stored in easily accessible locations give attackers persistent access long after the original login.
How to Detect Broken Authentication Vulnerabilities
Detection requires testing across several dimensions. Manual testing alone rarely catches everything – automated vulnerability scanning is necessary to cover the full surface area systematically.
Start with these detection steps:
1. Test session token entropy. Use a tool like Burp Suite to capture multiple session tokens across different logins and check for patterns. Predictable tokens are a critical finding.
2. Check session invalidation. Log out, then attempt to reuse the captured session token. If the request succeeds, the server is not properly invalidating sessions.
3. Test account lockout. Send 10–20 failed login attempts in quick succession. The application should block or throttle further attempts. No response to repeated failures is a clear broken authentication indicator.
4. Verify token regeneration after login. Compare the session ID before and after authentication. They must differ. A static session ID across the login boundary indicates session fixation risk.
5. Inspect token storage and transport. Session cookies should use the Secure and HttpOnly flags. Tokens stored in localStorage are accessible to JavaScript and at risk from XSS. Review the details on cookie security flags to understand what each flag prevents.
6. Review password policies. Test whether the application accepts passwords shorter than 8 characters or common passwords like “Password1”. Weak policies indicate gaps in authentication hardening.
Automated scanning tools run these and dozens of additional checks continuously, flagging regressions that appear when developers push new authentication-related code.
JWT and Token-Based Authentication Risks
Token-based authentication – particularly JWTs (JSON Web Tokens) – introduces a separate set of broken authentication risks that standard session testing misses.
The most dangerous is the “none” algorithm attack: if the server accepts a JWT with the algorithm set to “none”, an attacker can forge arbitrary tokens without a valid signature. This has been a real-world vulnerability in production systems. Similarly, confusing HS256 and RS256 algorithms – or accepting tokens signed with the public key as an HMAC secret – leads to complete authentication bypass.
For a full breakdown of where JWT implementations go wrong, the article on JWT security common implementation mistakes covers the specific flaws to test for and how to fix them.
A Scenario Worth Recognizing
A mid-size SaaS application undergoes a redesign of its authentication flow. The new code issues shorter session tokens for performance reasons and extends the default session lifetime from 30 minutes to 8 hours. Both changes slip through code review because each seems minor in isolation.
Three months later, a security audit finds the token space is small enough to brute force in under an hour on commodity hardware. The extended session lifetime means compromised tokens remain valid well into the next business day. Neither issue triggered any monitoring alert because the application itself was functioning normally.
This is the nature of broken authentication: the application works, users log in and out without issue, but the underlying mechanism has a flaw that’s invisible until it’s exploited.
Fixing Broken Authentication: Practical Remediation Steps
Remediation depends on which specific weaknesses are present, but the following baseline applies to most web applications:
Session management: Use cryptographically random session tokens of at least 128 bits. Regenerate session IDs after login, privilege escalation, and role changes. Set absolute session timeouts (e.g. 8–24 hours depending on application risk level) and idle timeouts (e.g. 15–30 minutes).
Account lockout and rate limiting: Implement lockout after 5–10 failed attempts, or use progressive delays. Apply rate limiting at the IP level, not just per-account, to defend against distributed credential stuffing.
Multi-factor authentication: MFA eliminates most credential-based attacks instantly. Even if credentials are stolen, the attacker cannot complete authentication without the second factor. Prioritize MFA for admin accounts and high-privilege roles first.
Credential storage: Passwords must be hashed with a modern algorithm – bcrypt, scrypt, or Argon2. MD5 and SHA-1 are not acceptable for password storage under any circumstances.
Token security: Validate JWT signatures server-side, reject “none” algorithm tokens, and enforce short expiry times with refresh token rotation.
The Myth: Strong Passwords Are Enough
A persistent misconception is that enforcing strong password policies effectively solves broken authentication. It doesn’t.
Password strength addresses credential guessing. It does nothing against session fixation, predictable tokens, missing MFA, or insecure session expiration. An attacker who steals a valid session cookie from an insecure connection doesn’t need to know the password at all. Authentication security requires a defense-in-depth approach – no single control is sufficient on its own.
Frequently Asked Questions
What is the most common broken authentication vulnerability?
Missing account lockout combined with no rate limiting is the most frequently observed issue in web application security audits. It allows automated credential stuffing attacks to run unchecked. Session tokens that don’t expire after logout are a close second.
How do automated security scanners detect broken authentication?
Automated scanners test for missing lockout mechanisms, insecure session token properties (length, flags, expiry), predictable token patterns, and improper session invalidation after logout. They run these tests on every scan cycle, which means regressions introduced by new code are caught quickly rather than during the next manual penetration test.
Is broken authentication only a risk for login pages?
No. Broken authentication affects any endpoint that relies on session state or tokens – password reset flows, API endpoints, OAuth callback handlers, and “remember me” features. The login page is just the most visible entry point.
Summary
Broken authentication vulnerabilities are consistently exploitable and consistently overlooked until they result in account takeovers. Detection requires systematic testing across session management, token handling, lockout behavior, and credential storage – not just a quick review of the login form.
The fixes are well-understood and not particularly expensive to implement. The gap is usually awareness and consistent testing coverage. Running continuous, automated security scanning ensures that authentication weaknesses introduced during development are caught before they reach production – and before an attacker finds them first.