Week Content

Opening Framing: The Foundation of Trust

Authentication answers the question: "Who are you?" It's the foundation upon which all access control is built. If authentication fails, an attacker becomes a legitimate user— or worse, an administrator.

Authentication vulnerabilities remain prevalent despite being well-understood. Weak passwords, flawed logic, missing protections, and implementation errors create opportunities for attackers to bypass identity verification entirely.

This week covers authentication mechanisms, common vulnerabilities, and testing techniques—from basic credential attacks to sophisticated bypass methods.

Key insight: Authentication is often the weakest link because it's where security meets usability, and usability usually wins.

1) Authentication Mechanisms

Understanding how applications verify identity:

Authentication Factors:

Something You Know:
- Passwords
- PINs
- Security questions

Something You Have:
- Hardware tokens
- Mobile devices (SMS, TOTP)
- Smart cards
- Email access

Something You Are:
- Fingerprints
- Face recognition
- Voice recognition

Multi-Factor Authentication (MFA):
- Combines 2+ factors
- Significantly harder to bypass
- Still has implementation flaws

Common Authentication Methods:

Form-Based Authentication:
- Username/password in HTML form
- POST to login endpoint
- Session cookie returned
- Most common method

HTTP Basic Authentication:
- Credentials in Authorization header
- Base64 encoded (NOT encrypted!)
- Authorization: Basic dXNlcjpwYXNz
- Sent with every request

Token-Based (JWT):
- Stateless authentication
- Token contains user info
- Signed but not encrypted (usually)
- Authorization: Bearer eyJhbG...

OAuth 2.0 / OpenID Connect:
- Delegated authentication
- "Login with Google/Facebook"
- Complex flows, many attack surfaces

API Keys:
- Static credentials for API access
- Often in header or query parameter
- No user context

Certificate-Based:
- Client certificates (mTLS)
- Strongest authentication
- Complex to implement

Authentication Flow:

Typical Login Flow:

1. User submits credentials
   POST /login
   username=admin&password=secret

2. Server validates credentials
   - Check database
   - Verify password hash

3. Server creates session
   - Generate session ID
   - Store session data

4. Server returns session cookie
   Set-Cookie: session=abc123; HttpOnly; Secure

5. Browser sends cookie with requests
   Cookie: session=abc123

6. Server validates session
   - Look up session ID
   - Return user context

Attack Points:
- Step 1: Credential guessing
- Step 2: Logic flaws, SQLi
- Step 3: Weak session generation
- Step 4: Cookie stealing
- Step 5: Session hijacking
- Step 6: Session validation bypass

Key insight: Every step in authentication is an attack surface. Understanding the flow reveals testing opportunities.

2) Username Enumeration

Discovering valid usernames before attacking passwords:

Why Username Enumeration Matters:

With valid usernames, attacker can:
- Target password attacks
- Attempt credential stuffing
- Social engineer users
- Map organization structure

Common Enumeration Points:
- Login forms
- Registration forms
- Password reset
- API endpoints

Detection Methods:

# Different error messages

Valid user, wrong password:
"Invalid password"
"Password incorrect"

Invalid user:
"User not found"
"Invalid username"

# This reveals which usernames exist!

# Response timing differences
Valid user: 500ms (password check)
Invalid user: 100ms (quick rejection)

# Response length differences
Valid user response: 1523 bytes
Invalid user response: 1498 bytes

# Status code differences
Valid user: 200 (with error in body)
Invalid user: 404

# Redirect differences
Valid user: Redirect to /dashboard
Invalid user: Stay on /login

Testing with Burp Intruder:

# Setup enumeration attack

1. Capture login request in Burp

2. Send to Intruder (Ctrl+I)

3. Set payload position on username:
   username=§admin§&password=anything

4. Load username wordlist:
   - SecLists/Usernames/
   - Names/names.txt
   - Custom based on recon

5. Configure Grep - Extract:
   - Error messages
   - Response length
   - Response time

6. Run attack

7. Analyze results:
   - Different response lengths
   - Different error messages
   - Response time anomalies

# Burp Intruder columns to check:
- Length (different = interesting)
- Status code
- Response time

Registration and Password Reset:

# Registration enumeration

POST /register
username=admin&email=test@test.com

Response: "Username already taken"
→ admin exists!

# Password reset enumeration

POST /forgot-password
email=admin@target.com

Valid email: "Password reset sent"
Invalid email: "Email not found"

# Or timing-based:
Valid: Sends email (slow)
Invalid: Quick response

# Or behavior-based:
Valid: Shows partial email (a***@target.com)
Invalid: Generic message

Key insight: Secure applications show identical responses regardless of whether the username exists.

3) Password Attacks

Attacking the password component:

Brute Force Attacks:

# Online brute force (slow, detectable)

# Burp Intruder
1. Capture login request
2. Set payload on password field
3. Use password wordlist
4. Monitor for successful login

# Rate limiting bypass attempts:
- IP rotation
- Header manipulation (X-Forwarded-For)
- Slow attack (avoid lockout)
- Distributed attack

# Common password lists:
/usr/share/seclists/Passwords/
- Common-Credentials/10k-most-common.txt
- Leaked-Databases/rockyou.txt
- darkweb2017-top10000.txt

Credential Stuffing:

# Using leaked credentials

Concept:
- Obtain leaked username:password pairs
- Try on target application
- Password reuse = account access

Sources:
- Have I Been Pwned
- Leaked database collections
- Previous breaches

Testing:
# Burp Intruder - Pitchfork mode
Position 1: username
Position 2: password (same row)

Load:
Payload 1: leaked_usernames.txt
Payload 2: leaked_passwords.txt

# Each request uses username1:password1, username2:password2, etc.

Password Spraying:

# Few passwords against many users

Why spraying works:
- Avoids account lockout
- Users choose weak passwords
- Common patterns exist

Approach:
1. Enumerate valid usernames
2. Try ONE password against ALL users
3. Wait (avoid lockout)
4. Try next password

Common spray passwords:
- Season + Year: Summer2024!
- Company + numbers: Acme123!
- Common patterns: Password1!

# Burp Intruder - Cluster Bomb
Position 1: username (all users)
Position 2: password (few passwords)

# With timing:
- 1 password per hour
- Monitor for lockouts

Default Credentials:

# Always check defaults first!

Common defaults:
admin:admin
admin:password
administrator:administrator
root:root
test:test
guest:guest

Application-specific:
WordPress: admin:admin
Tomcat: tomcat:tomcat, admin:admin
Jenkins: admin:admin (older versions)
phpMyAdmin: root:(empty)

Resources:
- https://cirt.net/passwords
- https://default-password.info
- SecLists/Passwords/Default-Credentials/

Key insight: Start with default credentials and password spraying—they're faster than brute force and often successful.

4) Authentication Bypass

Bypassing authentication without valid credentials:

SQL Injection in Login:

# Classic SQLi bypass

Vulnerable query:
SELECT * FROM users WHERE username='$user' AND password='$pass'

Payload:
username: admin'--
password: anything

Resulting query:
SELECT * FROM users WHERE username='admin'--' AND password='anything'
                                            ↑ Comment ignores rest

Other payloads:
admin' OR '1'='1'--
' OR 1=1--
' OR 'a'='a
admin'/*
' OR ''='

# NoSQL injection (MongoDB)
username: {"$gt": ""}
password: {"$gt": ""}

# JSON:
{"username": {"$gt": ""}, "password": {"$gt": ""}}

Logic Flaws:

# Authentication logic bypass examples

1. Response Manipulation
   # Intercept response, change:
   {"success": false} → {"success": true}
   {"authenticated": 0} → {"authenticated": 1}

2. Parameter Manipulation
   # Add/modify parameters:
   POST /login
   username=admin&password=wrong&authenticated=true
   
   # Or remove password requirement:
   username=admin

3. Forced Browsing
   # Access authenticated pages directly:
   /admin/dashboard
   /user/settings
   # Without logging in first

4. HTTP Method Tampering
   # POST blocked? Try:
   GET /admin
   PUT /admin
   # Or override:
   X-HTTP-Method-Override: GET

5. Step Skipping
   # Multi-step login:
   Step 1: Username
   Step 2: Password
   Step 3: MFA
   
   # Skip directly to step 3 with valid session

Password Reset Flaws:

# Password reset vulnerabilities

1. Token Prediction
   # Weak tokens:
   reset_token=123456 (sequential)
   reset_token=admin_1703123456 (timestamp)
   
   # Brute force short tokens
   
2. Token Leakage
   # Token in URL → Referer header leaks it
   # Token in response body
   
3. Host Header Injection
   # Intercept reset request:
   Host: attacker.com
   
   # Reset email contains:
   https://attacker.com/reset?token=xyz
   
4. Account Takeover via Email
   # Change email before reset:
   POST /update-email
   email=attacker@evil.com
   
   # Then request reset

5. No Rate Limiting
   # Brute force reset tokens
   /reset?token=000001
   /reset?token=000002
   ...

"Remember Me" Vulnerabilities:

# Persistent login tokens

Weak implementations:
- Token = base64(username)
- Token = MD5(username)
- Token = username:timestamp

Testing:
1. Decode remember-me cookie
2. Look for patterns
3. Forge for other users

Example:
remember=YWRtaW4= → base64("admin")

Forge for "victim":
remember=dmljdGlt → base64("victim")

# Token prediction
remember=user123_1703123456
remember=user123_1703123457 (increment)

Key insight: Authentication bypass often comes from logic flaws, not technical exploits. Think about what the developer assumed.

5) Multi-Factor Authentication Bypass

Even MFA has vulnerabilities:

MFA Bypass Techniques:

1. Skip MFA Step
   # After password auth, go directly to dashboard
   # Some apps don't enforce MFA server-side

2. Brute Force OTP
   # 6-digit codes = 1,000,000 combinations
   # Without rate limiting, feasible
   # Check for lockout policies

3. Response Manipulation
   # Change MFA response:
   {"verified": false} → {"verified": true}
   
4. Code Reuse
   # Can old codes be reused?
   # Some implementations don't invalidate

5. Backup Codes
   # Often less protected
   # Weaker entropy
   # Stored insecurely

Testing MFA:

# MFA testing checklist

□ Is MFA enforced server-side?
  - Try accessing protected pages directly
  
□ Can OTP codes be brute forced?
  - Test rate limiting
  - Test lockout after failures
  
□ Are codes time-based (TOTP)?
  - Test expired codes
  - Test future codes
  
□ Can codes be reused?
  - Submit same code twice
  
□ Is there backup code functionality?
  - Test backup code security
  - Are they rate limited?
  
□ Can MFA be disabled?
  - Without re-authentication?
  - Without confirming via MFA?
  
□ Are there logic flaws?
  - Skip MFA page
  - Manipulate responses
  
□ Is there MFA enrollment bypass?
  - Skip enrollment
  - Enroll different device

SMS and Email OTP Vulnerabilities:

# SMS-specific issues

SIM Swapping:
- Social engineer carrier
- Take over phone number
- Receive all SMS codes

SS7 Attacks:
- Telecom protocol vulnerabilities
- Intercept SMS messages

SMS Flooding:
- DoS by sending many codes
- Drain SMS budget

# Email OTP issues

Account Takeover:
- Compromise email first
- Then receive OTP codes

Email Forwarding:
- User has forwarding rule
- Codes go to attacker

Key insight: MFA significantly raises the bar but isn't impenetrable. Implementation flaws often exist.

Real-World Context: Authentication in Practice

Authentication vulnerabilities in the wild:

Case Study - Credential Stuffing: Major breaches often start with credential stuffing. Users reuse passwords from breached sites. Automated tools test millions of credential pairs against target applications.

Bug Bounty Patterns: Authentication bypasses are high-value findings. Password reset flaws, logic bypasses, and MFA weaknesses command premium payouts because of their direct impact.

Defense Challenges: Security vs. usability tensions are strongest in authentication. Account lockouts annoy legitimate users. Complex passwords are forgotten. MFA adds friction.

MITRE ATT&CK Mapping:

• T1110 - Brute Force: Password attacks
• T1078 - Valid Accounts: Credential stuffing
• T1556 - Modify Authentication Process: Bypass techniques

Key insight: Authentication is often tested superficially. Thorough testing of every mechanism and flow finds bypasses.

Guided Lab: Authentication Testing

Test authentication on DVWA and PortSwigger labs.