Broken Authentication / Weak Login Controls

SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration
SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration

All Entries

Scan Your Site

Check your website for this issue

Run an automated scan and see whether your site is affected — with plain-language findings and fixes.

Start Scanning
Category Authentication & Session Management
Typical Severity Critical
OWASP A07:2021 – Identification and Authentication Failures
CWE CWE-287 (Improper Authentication), CWE-521 (Weak Password Requirements), CWE-307 (Improper Restriction of Excessive Authentication Attempts), CWE-384 (Session Fixation)
Also known as Identification and Authentication Failures, Weak Credentials, Insecure Login, Session Management Vulnerabilities
Affected systems Any web application with user authentication: login portals, admin panels, APIs, SSO endpoints, password reset flows
Relevant standards NIST SP 800-63B (Digital Identity Guidelines), RFC 6749 (OAuth 2.0), RFC 7519 (JWT)

Overview

Broken authentication is a broad class of weakness that arises when the mechanisms an application uses to verify user identity or manage authenticated sessions are insufficiently robust. Flaws in this category allow attackers to bypass login controls entirely, impersonate legitimate users, or persist access beyond an intended session lifetime. It has consistently ranked among the most critical web application security risks and is formally classified under OWASP A07:2021 – Identification and Authentication Failures.

Common manifestations include: absence of brute-force protection, acceptance of weak or default credentials, insecure password storage, predictable or long-lived session tokens, missing or bypassable multi-factor authentication (MFA), and flawed password-reset workflows.

How it works

Attackers exploit authentication weaknesses through several well-documented techniques:

  • Credential Stuffing: Automated replay of username/password pairs leaked from other breaches. Effective where password reuse is common and no rate-limiting or anomaly detection exists.
  • Brute Force / Password Spraying: Systematic trial of passwords against one or many accounts. Password spraying tests a single common password (e.g., Spring2024!) across many accounts to avoid per-account lockout thresholds.
  • Default or Weak Credentials: Applications or infrastructure left with vendor-supplied default credentials (e.g., admin/admin) or policies that allow trivially guessable passwords.
  • Session Token Weaknesses: Predictable token generation (low entropy), tokens transmitted over HTTP rather than HTTPS, missing HttpOnly or Secure cookie flags, excessively long session lifetimes, or failure to invalidate tokens on logout (CWE-613).
  • Session Fixation (CWE-384): An attacker supplies a known session identifier before authentication; if the application does not rotate the session ID on successful login, the attacker's pre-planted identifier becomes valid.
  • Insecure Password Reset: Reset flows that rely on guessable security questions, tokens with insufficient entropy, tokens that do not expire, or that disclose whether an account exists (user enumeration).
  • Insecure Password Storage: Storing passwords as plaintext, with reversible encryption, or with weak hashing algorithms (MD5, SHA-1 without salt), enabling mass credential recovery if the database is compromised.
  • MFA Bypass: Flaws in MFA implementation such as predictable OTP seeds, absence of OTP replay protection, or fallback mechanisms that entirely circumvent the second factor.

Business impact

Successful exploitation of broken authentication vulnerabilities can lead to full account takeover of individual users or, in the case of administrative accounts, complete system compromise. Specific consequences include:

  • Data breach: Unauthorised access to personal, financial, or health data, triggering regulatory obligations under GDPR, HIPAA, PCI DSS, and similar frameworks.
  • Financial fraud: Attackers can initiate transactions, exfiltrate payment data, or monetise compromised accounts directly.
  • Privilege escalation: Access to an ordinary user account can serve as a pivot to administrative interfaces if role separation is weak.
  • Reputational damage: Publicised account takeovers erode customer trust and may drive users to competitors.
  • Regulatory fines: Failure to implement adequate authentication controls is explicitly cited in GDPR Article 32 and PCI DSS Requirement 8 as an area requiring technical safeguards.
  • Service disruption: Credential stuffing campaigns generate substantial traffic that can degrade performance for legitimate users.

How to fix it

  1. Enforce strong password policies: Require a minimum length of at least 12 characters. Check new passwords against lists of known-breached passwords (e.g., using the HaveIBeenPwned API or a local blocklist). Avoid complexity rules that are easily gamed (e.g., P@ssw0rd). Follow NIST SP 800-63B guidance, which favours length over complexity.
  2. Implement multi-factor authentication (MFA): Require MFA for all accounts, especially privileged ones. Prefer TOTP (RFC 6238) or FIDO2/WebAuthn hardware keys over SMS OTP, which is susceptible to SIM-swapping. Ensure MFA cannot be bypassed through fallback flows.
  3. Rate-limit and lock out authentication attempts: Apply progressive delays or temporary lockouts after a configurable number of failed attempts (e.g., 5–10). Implement CAPTCHA challenges for automated request patterns. Log and alert on anomalous login activity. Avoid revealing whether the lockout is due to account existence vs. wrong password.
  4. Store passwords with a strong adaptive hash: Use bcrypt, scrypt, Argon2id, or PBKDF2 with a sufficient work factor and a unique per-user salt. Never store plaintext or use MD5/SHA-1 for password hashing.
  5. Manage sessions securely: Generate session identifiers with at least 128 bits of entropy using a cryptographically secure pseudorandom number generator (CSPRNG). Set cookies with HttpOnly, Secure, and SameSite=Strict or Lax attributes. Regenerate the session ID upon successful authentication to prevent session fixation. Enforce absolute and idle session timeouts appropriate to the application's risk profile.
  6. Invalidate sessions on logout and password change: Ensure server-side session destruction on logout, not merely client-side cookie deletion. Invalidate all active sessions when a password is changed or an account is compromised.
  7. Secure password reset flows: Use high-entropy, single-use, time-limited tokens (at least 128 bits, expiry ≤ 15 minutes) delivered to a verified channel. Do not reveal account existence in error messages. Invalidate the token immediately after use.
  8. Eliminate default credentials: Require credential change on first login for all system accounts. Scan infrastructure and third-party components for known default credentials before deployment.
  9. Implement account takeover detection: Monitor for login from new geographies, devices, or IP ranges. Notify users of successful logins from unfamiliar contexts and provide a mechanism to report unauthorised access.
  10. Adopt an established authentication framework: Wherever feasible, delegate authentication to a well-audited identity provider (IdP) using OpenID Connect or SAML 2.0 rather than building bespoke authentication logic.

Sensagraph automatically detects common broken authentication indicators such as missing lockout controls, insecure cookie attributes, and exposed default credentials.

References

Frequently asked questions

Broken authentication refers to weaknesses in the process of verifying who a user is (identity verification, credential management, session handling). Broken access control (OWASP A01:2021) refers to weaknesses in determining what an authenticated user is permitted to do. The two are related but distinct: a broken authentication flaw lets an attacker log in as someone else, while a broken access control flaw lets an already-authenticated user do things they should not be allowed to do.

SMS OTP provides meaningful improvement over single-factor authentication but is considered a weaker form of MFA because it is susceptible to SIM-swapping attacks, SS7 protocol interception, and social-engineering of mobile carriers. NIST SP 800-63B classifies SMS OTP as a restricted authenticator. For higher assurance levels, TOTP apps (e.g., RFC 6238-compliant authenticators) or phishing-resistant FIDO2/WebAuthn hardware keys are strongly preferred.

A brute-force attack systematically generates or iterates over candidate passwords (often using wordlists or character-space enumeration) targeting a specific account. Credential stuffing uses real username/password pairs harvested from prior data breaches, exploiting the fact that many users reuse credentials across services. Credential stuffing is typically more efficient and harder to detect because each attempt uses a plausible, previously-valid credential pair, often distributed across many IP addresses using botnet infrastructure.

Argon2id is the current best-practice recommendation, having won the Password Hashing Competition and being endorsed by OWASP and NIST. Where Argon2id is unavailable, bcrypt with a work factor of at least 10 or scrypt with appropriate parameters are acceptable alternatives. PBKDF2-HMAC-SHA256 with at least 600,000 iterations is also acceptable and is used in FIPS-validated contexts. MD5, SHA-1, and unsalted SHA-256 are entirely unsuitable for password storage.

Secure session cookies should include: the Secure flag (cookie transmitted only over HTTPS), HttpOnly flag (cookie inaccessible to JavaScript, mitigating XSS-based session theft), SameSite=Strict or SameSite=Lax (mitigating CSRF attacks), an appropriate Max-Age or Expires value, and the Path attribute scoped as narrowly as the application permits. The session identifier itself must have at least 128 bits of entropy generated by a CSPRNG.

No. HTTPS (TLS) protects credentials and session tokens in transit from network-level eavesdropping, but it does not address the authentication logic itself. An attacker who obtains credentials through a database breach, phishing, or brute force will succeed regardless of whether the connection is encrypted. HTTPS is a necessary but not sufficient control; it must be combined with strong credential policies, rate-limiting, MFA, secure session management, and secure password storage.