Ethical Hacking
Authentication Attacks
Authentication is the front door of every web application. Every weakness in how an application identifies its users — broken flows, insecure reset mechanisms, missing rate limits, bypassable MFA — is a path into accounts that should be protected. This lesson covers the most consistently found authentication failures in real assessments.
Authentication vs authorisation — a critical distinction
Authentication answers "are you who you claim to be?" — verifying identity. Authorisation answers "are you allowed to do this?" — verifying permission. Both can fail independently. OWASP A07 covers authentication failures. OWASP A01 covers authorisation failures (broken access control from Lesson 37). They are related but distinct, and a finding in one category does not imply a finding in the other.
Authentication failures are particularly impactful because they represent the outermost boundary of access control. A broken authorisation check inside an application assumes the user authenticated legitimately. A broken authentication mechanism means the attacker never needed to authenticate at all — every authorisation check downstream becomes irrelevant once they are inside as a valid user.
Authentication failure categories — OWASP A07
No account lockout or rate limiting
Login forms that allow unlimited password guesses without throttling or lockout are vulnerable to brute force. The Hydra and password spraying techniques from Lesson 22 apply directly here. On web applications, Burp Intruder automates credential stuffing and password spraying with precise control over timing and payload lists.
Insecure password reset flows
Password reset mechanisms that use predictable tokens, tokens that never expire, tokens sent in URLs that appear in server logs, or security questions with publicly available answers. The attacker takes over accounts through the reset flow rather than cracking the password directly — often faster and leaving less evidence.
Session tokens not invalidated on logout
Clicking logout should invalidate the session token server-side. Applications that only delete the cookie client-side — without marking the session invalid on the server — allow anyone with a copy of the old token to continue accessing the application after the legitimate user has "logged out." Captured tokens from network captures or XSS remain valid indefinitely.
Default or weak credentials
Admin panels, CMS installations, and web-accessible database interfaces left with default credentials. admin:admin, admin:password, root:root. Checking default credentials against every admin interface found during enumeration is one of the fastest-returning techniques in a web assessment — takes thirty seconds and occasionally yields immediate admin access.
Session IDs exposed in URLs
Session tokens that appear in the URL path or query string — rather than in cookies — appear in server logs, browser history, Referer headers sent to third-party analytics services, and browser address bars where shoulder-surfing is possible. Any of these exposures gives an attacker a valid session token without needing to steal a cookie.
Testing login brute force protection in Burp Intruder
Burp Intruder automates payload insertion into any part of an HTTP request. For testing authentication — whether rate limiting and lockout exist — the workflow is to capture a login request in Burp Proxy, send it to Intruder, mark the password parameter as the injection point, and configure a password wordlist. Intruder sends every password from the list and flags responses that differ from a failed login.
The scenario: You are testing the DVWA login page. Security is set to low. You want to determine whether the login form has any rate limiting or account lockout after repeated failed attempts — and demonstrate whether a valid password can be found through brute force.
# Burp Intruder workflow — testing for missing brute force protection
# Do this in the Burp GUI, not the terminal — but the steps are documented here
# Step 1 — capture the login POST request in Burp Proxy
# Enable intercept, submit the login form, the request appears in Burp
# Step 2 — send to Intruder
# Right-click the captured request → Send to Intruder
# Step 3 — configure the attack position
# In Intruder → Positions tab, clear all auto-detected positions
# Highlight the password value and click Add § to mark it as the payload position
# The request should look like:
# username=admin&password=§password§&Login=Login
# Step 4 — configure the payload list
# In Intruder → Payloads tab:
# Payload type: Simple list
# Load the fasttrack.txt wordlist
# /usr/share/wordlists/fasttrack.txt (222 entries — start small)
# Step 5 — run the attack and identify successful login
# Click Start Attack
# In the results table, look for a response with a different:
# - Response length (successful login returns different content)
# - Status code (302 redirect on success vs 200 on failure in some apps)
# - Response time (significant variation sometimes indicates success)
# Step 6 — confirm rate limiting assessment
# Count the number of requests sent before any response changed
# If 222 attempts were sent with no lockout or delay — rate limiting is absent
# Document: X attempts were made in Y seconds with no throttling or lockout triggeredBreaking it down:
A failed login returns a page saying "Login failed" — a specific number of bytes. A successful login redirects to the dashboard — either a different status code (302) or a different response length. Intruder's results table makes this immediately visible — the outlier row stands out against 221 identical responses. Sorting by response length or status code surfaces the successful attempt instantly even in large wordlists.
The absence of any delay, throttling, or lockout across 222 authentication attempts is itself the finding — independent of whether a valid password was found. A login endpoint that accepts 26 requests per second without any protective response allows an attacker to test millions of passwords per hour against any account. Report both: the weak credential found (critical) and the missing rate limiting that made it findable (high).
Insecure password reset — a consistently overlooked attack surface
Password reset flows are almost always tested last and fixed last — yet they are one of the most reliable routes to account takeover in real assessments. The flow must verify that the person requesting the reset actually controls the account — which requires a mechanism that attackers cannot predict, intercept, or replay.
The most common failures appear in predictable patterns. Knowing these patterns turns password reset testing from a general "check if it works" exercise into a structured set of specific checks, each targeting a known failure mode.
Credential stuffing — one breach becomes many
Credential stuffing uses username-password pairs from known data breaches and tests them against other applications. People reuse passwords. A credential set from a forum breach in 2019 may still work on the victim's banking application, corporate VPN, or cloud storage account — because they used the same password everywhere.
The 2020 Zoom credential stuffing attack — 500,000 compromised accounts sold on dark web forums — used credentials from completely unrelated breaches. Zoom did not have a vulnerability. The users did not have weak passwords by conventional measures. The only failure was password reuse across services. From a defender's perspective, the only complete solution is MFA — because a credential stuffing attacker has valid credentials. Rate limiting slows them down. MFA stops them entirely.
In a pen test, credential stuffing assessment is typically limited to checking whether the application has rate limiting that would detectably slow such an attack, and whether it integrates with breach detection services — HaveIBeenPwned's API allows applications to check submitted passwords against known breach databases at registration time, blocking users from setting known-compromised passwords.
MFA bypass techniques
Multi-factor authentication significantly raises the authentication bar — but implementations frequently have weaknesses. Testing MFA is not just checking that it exists. It is checking that it cannot be bypassed, that the codes are not predictable, and that the flow enforces completion before granting access.
Skipping the MFA step
Some applications implement MFA as a second step after password validation — the user proves their password, gets redirected to the MFA page, and must enter their code before reaching the dashboard. If the application grants a partial session after password validation, it may be possible to directly navigate to the dashboard URL rather than the MFA page — bypassing MFA entirely. Test by completing the password step, then changing the URL from /mfa to /dashboard or /home rather than entering the code.
Response manipulation — changing "false" to "true"
Some applications validate the MFA code client-side, or make a server request that returns a JSON response like {"valid": false}. Intercepting this response in Burp and changing false to true — before the browser receives it — tricks the client-side logic into treating an invalid code as valid. This fails against properly server-enforced MFA but works against implementations where the client makes the access decision based on an API response it should not trust.
TOTP code brute forcing
Time-based OTP codes are six digits — one million possible values, valid for 30 seconds, with typical implementations allowing the previous and next window for clock drift. That is around three million codes per 30 seconds window. Without rate limiting on the MFA code entry, an attacker who has compromised valid credentials can brute force the OTP code automatically. The window is tight but with fast enough requests it is theoretically feasible. In practice, rate limiting on the MFA endpoint is as important as rate limiting on the password endpoint.
SIM swapping and social engineering — out of scope but worth documenting
SMS-based MFA is weaker than TOTP or hardware keys because phone numbers can be transferred through social engineering of the mobile carrier (SIM swapping). This is outside a typical technical pen test scope — but when SMS MFA is found, the report should note that SMS is considered the weakest MFA form by NIST and that TOTP or hardware key MFA is preferable. The finding is not a vulnerability in the application but a risk assessment observation about the MFA type chosen.
Remediation priorities for authentication findings
Authentication findings have a clear remediation hierarchy. The fixes are well-established, the effort is generally low, and the impact of not fixing them is immediate account compromise. A client who asks which authentication finding to fix first gets a simple answer: whatever allows the fastest path to account takeover goes first.
The table above doubles as a testing checklist. Each finding has a specific, testable condition and a specific, implementable fix. Authentication assessment that works through all five areas — and tests the fixes after they are applied — produces a complete picture of the account access security posture rather than a collection of individual observations.
Teacher's Note: The single most commonly missed authentication finding in web assessments is session invalidation on logout. Testers confirm the login works, test brute force protection, check the reset flow — and forget to verify that clicking logout actually invalidates the server-side session. Copy the session cookie in Burp before clicking logout. After logout, replay the cookie in a new Burp request. A 200 response to a protected endpoint means the session is still valid. This takes thirty seconds to test and is a finding in about a quarter of applications assessed.
Quiz
Scenario:
Scenario:
Scenario:
Up Next · Lesson 41
Session Hijacking
Cookie theft, token replay, session fixation, and the techniques that let attackers take over authenticated sessions without ever knowing the user's password.