Authentication Vulnerability Testing

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 and can chain into business logic exploitation. Login forms vulnerable to SQL injection 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.
• 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.

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.

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

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:

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.

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.

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.

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.

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.

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.

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.

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

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 and defaultpassword.com.