broken-authentication – Security skill for AI agents

> ⚠️ 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:

> 1. Ask the user to state the exact target URL, IP, account, or resource.

> 2. Ask the user to confirm written authorization and the permitted scope.

> 3. Show the exact command(s) and explain their expected effect.

> 4. 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

1. Authentication Assessment Report - Document all identified vulnerabilities

2. Credential Testing Results - Brute-force and dictionary attack outcomes

3. Session Security Analysis - Token randomness and timeout evaluation

4. Remediation Recommendations - Security hardening guidance

Core Workflow

Phase 1: Authentication Mechanism Analysis

Understand the application's authentication architecture:

# Identify authentication type
- Password-based (forms, basic auth, digest)
- Token-based (JWT, OAuth, API keys)
- Certificate-based (mutual TLS)
- Multi-factor (SMS, TOTP, hardware tokens)

# Map authentication endpoints
/login, /signin, /authenticate
/register, /signup
/forgot-password, /reset-password
/logout, /signout
/api/auth/*, /oauth/*

Capture and analyze authentication requests:

POST /login HTTP/1.1
Host: target.invalid
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)

Assess the applicable policy and threat model. Lack of character-composition rules is not itself a defect; prioritize length, compromised-password blocklists and rate limits. See [NIST SP800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html).

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)

API responses

{"error": "user_not_found"}

{"error": "invalid_password"}

### Phase 4: Brute Force Testing

Test account lockout and rate limiting:

Using Hydra for form-based auth

hydra -l admin -P /usr/share/wordlists/rockyou.txt \

target.invalid 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

Use synthetic paired credentials for explicitly authorized test accounts, never unrelated breached accounts:

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.invalid/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

Unchanged ID is a lead: verify attacker fixation and authenticated reuse.

A changed ID alone does not prove the old session was invalidated.

Attack scenario:

Attacker workflow:

1. Attacker visits site, gets session: SESSIONID=attacker_session

2. Attacker sends link to victim with fixed session:

https://target.invalid/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.invalid/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 |
| Sessi

… (full content is in the download package)