Module 3 · Authentication Attacks

Last updated: May 1, 2026

Authentication bugs are high-severity by nature. Every subsequent authorization control in the application depends on correctly identifying the user. Break authentication and you bypass everything downstream. This is why auth-layer findings consistently rank as Critical in professional reports.

Modern frameworks handle the basics reasonably well. The authentication bugs that still land in 2026 engagements are almost always configuration errors, legacy code paths, or subtle implementation flaws around edge cases. This module teaches you the test techniques that surface those.

Username enumeration

Before trying to crack passwords, determine which usernames exist. Enumeration reduces the attack surface from “every possible username” to “known-valid accounts” — often 1000x faster.

Enumeration primitives:

• Error message delta. Submit a valid username with a wrong password. Then submit a clearly-invalid username with any password. Compare responses. “Incorrect password” vs “User not found” is gold.
• Timing delta. If the app hashes a password before checking the user, valid-username requests take longer (because hashing happens) than invalid-username requests (rejected early). Automate with a few hundred requests; compute response time averages.
• Password reset enumeration. “If this email exists, we’ve sent a reset link” is meant to prevent enumeration. But some apps leak timing or response size. Test the reset flow with a known-valid and known-invalid email; compare.
• Registration. Try to register with a known-valid email. “Email already in use” = enumeration.

Automation

ffuf -w usernames.txt -X POST 
  -d '{"username":"FUZZ","password":"wrongpassword123"}' 
  -H "Content-Type: application/json" 
  -u https://target.example.com/api/login 
  -fr "User not found"    # filter (exclude) responses matching this string

# Whatever response is NOT filtered = valid username detected

Password spraying vs brute-force

These two attacks target different defenses:

• Brute-force: many passwords against ONE account. Hits account-lockout policies fast. Rarely works against modern apps unless lockout is missing or bypassable.
• Password spraying: ONE password (or small set) against MANY accounts. Spreads the request load across accounts, avoiding per-account lockout. Surprisingly effective in the real world.

Password spraying execution

Build a list of enumerated usernames. Pick 3–5 likely passwords based on season, company name, culture. Typical picks for Indian enterprises in 2026: Winter2026!, {Company}@123, Password@2026, Welcome@123. Yes, they still work.

# Spray one password across all usernames
for user in $(cat usernames.txt); do
  curl -s -X POST https://target.example.com/api/login 
    -H "Content-Type: application/json" 
    -d "{"username":"$user","password":"Welcome@123"}" 
    -w "%{http_code} $usern" -o /dev/null
  sleep 1   # rate-limit yourself
done | grep "^200"

Rate-limit bypass techniques

If the target rate-limits by IP, try:

• X-Forwarded-For header rotation — some apps trust it for rate limiting
• Cycling source IPs through a proxy rotator
• Distributed spraying over many hours
• If the app tracks attempts per session, use fresh sessions per attempt

Credential stuffing

Attackers don’t guess passwords — they replay passwords that leaked from other breaches. The combolists are enormous; every major application has users who reuse credentials from breached services.

From a testing perspective, you verify the app has controls against credential stuffing, not that you can stuff specific credentials (that’s unethical). Verify:

• Have I Been Pwned integration — does the app warn/block on known-compromised passwords during registration or login?
• Anomaly detection — does the app flag unusual login locations, devices, or velocities?
• MFA coverage — is MFA mandatory, optional, or available only for admins?
• Account-takeover alerts — does the app notify users when sign-in happens from a new device/location?

Session cookie attacks

Covered in Module 1 but worth testing explicitly:

• Does the session cookie have HttpOnly, Secure, SameSite=Lax or stricter?
• Can you access the cookie via document.cookie in the browser console? If yes, HttpOnly is missing.
• Does logging out invalidate the session server-side? Copy the cookie to another browser; log out in the first; see if the second still works. If yes, logout is cookie-delete only (broken).
• Session fixation: set your session cookie, log in, observe whether the cookie value changes. If it doesn’t, the app is vulnerable to session fixation.
• Concurrent sessions: does the app allow unlimited concurrent logins or cap them?

JWT — the 2026 attack surface

JSON Web Tokens are self-contained signed tokens carrying claims. They’re used widely for API authentication. The classic JWT attacks still land in 2026 because frameworks get them wrong:

1. Algorithm confusion (alg: none)

If the server trusts the alg field in the token header, you can set it to none and drop the signature. The server may accept the unsigned token.

# Original token
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.{payload}.{signature}

# Modified: alg=none, signature stripped
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.{payload}.

Mitigation: server must validate alg against an allowlist.

2. Algorithm confusion (HS256 → RS256)

If the server expects RS256 (asymmetric — verify with public key), an attacker can change alg to HS256 (symmetric — sign with the public key as the secret). The server tries to verify with the public key using HMAC, and the attacker-crafted signature validates.

3. Weak signing key (HS256)

HS256 tokens signed with a short or guessable secret can be cracked offline with hashcat:

hashcat -m 16500 jwt_token.txt rockyou.txt
# Cracks HS256 tokens against a wordlist — extracts the secret

If you crack the secret, you can mint arbitrary tokens with any claims you want.

4. Missing expiration claim

Tokens without an exp claim are valid forever. Combined with any other vulnerability, this turns transient access into permanent.

5. Key confusion via kid header

Some JWT libraries look up the signing key via a kid (key ID) field in the header. If the kid is used in a database query, SQL injection is possible. If it’s used as a file path, path traversal can point to attacker-controlled content.

Tools

Use the JWT Decoder tool on RingSafe to inspect tokens. For fuzzing: jwt_tool (GitHub) automates all the common JWT attacks.

OAuth common flaws

• Missing state parameter — enables CSRF against the OAuth flow
• Redirect URI validation — if the server accepts partial-match redirect URIs, attacker redirects the code to their domain
• PKCE not enforced — public clients (mobile apps, SPAs) must use PKCE; if the server doesn’t enforce it, authorization codes can be intercepted
• Scope upgrade — initial request with minimal scopes, token refresh request with broader scopes. Some servers grant the upgrade.
• Open redirect → authorization code theft — if the callback URI has an open redirect, attacker chains it to steal codes

SAML common flaws

• Signature bypass — SAML responses are XML with a digital signature. Some parsers validate signatures but extract user identity from a different node (XPath injection territory).
• XML External Entity (XXE) — SAML parsers that allow external entities are XXE-vulnerable.
• Audience validation missing — if the AudienceRestriction is not checked, tokens for one application can be replayed against another.
• Replay protection — SAML responses have timestamps; if they’re not enforced, replays work.

MFA bypass patterns

• MFA check is client-side only (rare but found occasionally)
• MFA enrollment endpoint callable by any authenticated user to enroll their own device for the victim’s account
• Legacy auth paths (mobile app, API) that don’t require MFA even when web does
• Backup/recovery codes without rate limiting — brute-forceable
• “Remember this device” cookies that can be harvested and replayed

Exercises

1. Username enumeration in a test app. Spin up DVWA or OWASP Juice Shop. Attempt username enumeration via the password reset flow. Quantify the response-time or response-content delta between valid and invalid emails.

2. JWT inspection. Use the JWT Decoder tool on a token from any app you use. Identify the algorithm, claims, and expiration. Does the token have a reasonable expiration? Does it include unnecessary claims (PII, role hints)?

3. Session behavior test. On a web app you have an account with: log in, copy the session cookie, paste it into a private browser window, log out of the original window, then reload the private window. Does the cloned session still work? This reveals server-side logout behavior.

Check your understanding

• Why is password spraying more effective than brute-force against modern apps?
• What’s the difference between credential stuffing and brute-force?
• Why does alg: none work against some JWT implementations?
• What happens if a JWT has no exp claim?
• What is the “state” parameter in OAuth, and what does it prevent?

Take the 20-question quiz below to confirm your understanding. Pass with 70%+ to mark this module complete. Unlimited retries.

Authentication performance — when security and speed conflict

Strong authentication has unavoidable performance cost. bcrypt / argon2 password hashing: deliberately slow (50-200 ms per verification by design). At 1000 logins/sec a single auth box is saturated. Solutions:

Credential-stuffing defence — the layered playbook

Detection — what to log and what to alert on

Indian context — Aadhaar, DigiLocker, and the consent layer

Indian web apps increasingly federate identity through three special endpoints: Aadhaar e-KYC (biometric or OTP) — UIDAI-regulated, requires AUA / Sub-AUA agreement, audit log per access. DigiLocker — government document vault; OAuth-style flow; suitable for fintech / education / employment verification. Account Aggregator framework (RBI 2022) — consent-based financial-data sharing across banks / mutual funds / insurance. Each has its own security controls (mutual TLS, HMAC-signed requests, consent expiry, purpose limitation).

Practitioner takeawaywhen auditing Indian web apps that touch any of these, the threat model expands to include the IdP and the consent layer. DPDP Act consent requirements layer on top — expect detailed disclosure, granular control, and audit trails as table stakes.

  Login attempt
    │
    ▼
  [Edge — rate limit + bot detection]
    │  block too-fast / known-bad fingerprints
    ▼
  [Credentials check]
    │  bcrypt / argon2 — slow on purpose
    ▼
  [Breach-list check]
    │  reject known-pwned passwords
    ▼
  [Risk score — IP, geo, device, time]
    │  high-risk → step-up MFA
    ▼
  [MFA verify]  TOTP / WebAuthn / push
    │
    ▼
  [Session issued]
    │  HttpOnly + Secure + SameSite cookie
    │  short expiry; regenerate on privilege change
    ▼
  Logged user

Further reading

• OWASP Authentication Cheat Sheet
• NIST SP 800-63B — Digital Identity Guidelines
• haveibeenpwned API
• WebAuthn / FIDO2 spec
• UIDAI AUA documentation

Additional FAQs

Should I use OAuth as my only login mechanism?

For consumer apps, often yes — Google / Apple / Microsoft sign-in shifts auth complexity to those providers. For corporate apps, prefer SSO via your IdP (Entra ID, Okta). Run “username+password” only when neither path applies and you have the operational maturity to defend it.

Is SMS MFA still acceptable in 2026?

For low-risk consumer use, acceptable but not recommended — SIM-swap and SS7 attacks remain viable. For BFSI, regulators expect TOTP or push-based or WebAuthn. The migration path: offer SMS as fallback, default new users to TOTP / authenticator-app.

How long should sessions live?

Sensitive apps: 15 min idle / 8 h absolute. Standard web: 30-60 min idle / 24 h absolute. Long-lived devices (logged-in on personal phone): refresh-token rotation with 30-day cap. Always renew on privilege escalation; always invalidate on password change.