Cybersecurity glossary

What is Broken Authentication?

Learn what broken authentication means, how weak login, session, and recovery designs lead to account takeover, and which controls from OWASP and NIST reduce authentication failures.

Identity and accessUpdated July 20, 2026
Also known asAuthentication failuresBroken authAuthentication bypass weaknesses

Definition

Broken authentication is a class of security weaknesses in which flaws in login, session handling, credential recovery, or authenticator lifecycle allow attackers to impersonate users or bypass identity checks.

Why broken authentication matters

Authentication is the gate between public traffic and user data. When that gate fails, attackers do not need an exotic memory corruption bug. They only need a way to become someone else.

Broken authentication covers the design and implementation mistakes that make impersonation practical: weak passwords, unprotected login APIs, fragile recovery, poorly handled sessions, and incomplete multi-factor flows. These issues remain common because identity logic is spread across web apps, mobile clients, SSO callbacks, and partner integrations.

Account takeover is the usual outcome. From there, attackers can change email addresses, drain balances, steal personal data, or pivot into privileged administrative functions.

What “broken” usually looks like

Authentication can fail at several layers.

Weak credentials

Default passwords, password reuse, short secrets, and missing breached-password checks invite stuffing and guessing.

Unprotected auth endpoints

Login, OTP, and reset APIs without rate limits, lockouts, or bot controls allow industrial-scale attempts.

Session flaws

Predictable tokens, tokens in URLs, missing Secure/HttpOnly flags, or no rotation after login enable hijacking.

Recovery abuse

Password reset and MFA recovery that rely on guessable answers or open redirects become alternate front doors.

MFA gaps

Optional MFA, bypass parameters, fatiguing push prompts, or SMS interception leave second factors unreliable.

Inconsistent clients

Mobile or legacy APIs authenticate with weaker rules than the primary website.

How attackers exploit authentication failures

1

Map identity flows

Find login, SSO, token refresh, password reset, MFA challenge, and remember-me endpoints across clients.

2

Test credential attacks

Attempt stuffing, spraying, and brute force while watching for lockout, CAPTCHA, and uniform error messages.

3

Probe session handling

Check token entropy, fixation, logout invalidation, concurrent sessions, and cookie attributes.

4

Abuse recovery and fallback

Target reset links, backup codes, call-center flows, and weak secondary email or phone changes.

5

Bypass or fatigue MFA

Look for skipped challenges, reusable OTPs, or social-engineering paths around the second factor.

6

Persist as the victim

Establish lasting access with session tokens, OAuth grants, API keys, or changed recovery contacts.

TopicPrimary focusExample failure
Broken authenticationProving identity incorrectlySession not rotated after login, enabling fixation.
Broken access controlAuthorization after identity is knownUser A can read User B's invoice by ID.
Credential stuffingReuse of breached passwords at scaleBotnet tests leaked pairs against /login.
Session hijackingTheft or prediction of active sessionsXSS steals an HttpOnly-less cookie.

High-impact examples

Password-only APIs on the open internet

A login endpoint that accepts unlimited guesses and returns distinct messages for “unknown user” versus “bad password” helps attackers both validate accounts and recover weak credentials.

Session fixation

If the application continues using a pre-login session identifier after successful authentication, an attacker who planted that identifier can inherit the victim’s authenticated session.

Long-lived reset tokens, tokens placed in query logs, or reset flows that do not invalidate previous sessions allow attackers who intercept one message to keep access.

MFA theater

Showing an MFA settings page while allowing API password grants without the second factor creates a bypass path sophisticated users never see in the UI.

Controls that reduce broken authentication

  • Require strong, unique credentials and check passwords against known-breach corpora where appropriate.
  • Hash passwords with a modern adaptive algorithm and never store reversible password encryption for login.
  • Deploy MFA, preferring phishing-resistant authenticators for privileged and high-risk accounts.
  • Rate-limit authentication, recovery, and OTP validation by account and by source identity.
  • Generate high-entropy session tokens, set Secure, HttpOnly, and appropriate SameSite attributes, and rotate on login.
  • Invalidate sessions on logout, password change, MFA change, and recovery completion.
  • Unify authentication policy across web, mobile, and partner APIs.
  • Monitor for stuffing patterns, impossible travel, sudden recovery changes, and repeated MFA failures.

Testing and operations

Security reviews should treat identity as a product surface, not a single /login form. Include federation callbacks, magic links, device codes, service accounts, and “login with token” debug endpoints.

Operationally, preserve enough auth telemetry to investigate takeover: account ID, outcome, MFA method, session ID hash, and risk signals—without logging secrets or full recovery tokens.

The practical takeaway

Broken authentication is any weakness that lets attackers forge or steal a valid identity proof. Passwords, sessions, MFA, and recovery all count.

Fix the whole lifecycle: resistant authenticators, protected endpoints, robust session handling, safe recovery, and consistent enforcement on every client that can create access. Authentication that looks polished in the UI but weak in an API is still broken.

Related security terms

Frequently asked questions

What is broken authentication in simple terms?

Broken authentication means the way an application verifies users is flawed. Attackers can take over accounts by guessing passwords, stealing sessions, abusing password reset, or bypassing multi-factor checks.

Is broken authentication the same as broken access control?

No. Broken authentication is about proving identity incorrectly. Broken access control is about what an authenticated or anonymous user is allowed to do. They often combine during account takeover incidents.

What are common examples of broken authentication?

Examples include credential stuffing without defenses, predictable session tokens, missing MFA, session IDs in URLs, weak password recovery, failure to rotate sessions after login, and accepting default or hardcoded credentials.

How do attackers exploit broken authentication?

They automate login attempts, replay stolen cookies, poison password-reset flows, force sessions, phish one-time codes, or abuse APIs that skip the same checks enforced in the UI.

How can organizations prevent broken authentication?

Use phishing-resistant MFA where possible, protect credentials with modern hashing, rate-limit and monitor auth flows, rotate session tokens after privilege changes, harden recovery, and align with OWASP and NIST digital identity guidance.

Does MFA eliminate broken authentication risk?

MFA greatly reduces password-only takeover, but weak MFA, insecure fallbacks, session fixation after MFA, and poorly protected recovery channels can still leave authentication broken.

Where should teams test for broken authentication?

Test login, logout, registration, password reset, MFA enrollment, remember-me, API token issuance, SSO callbacks, and every alternative client that can create a session.

References

Explore authoritative guidance and frameworks related to broken authentication.

Explore every security definition

Return to the glossary to search by term, alias, starting letter, or security category.

Browse glossary