Authentication Vulnerabilities: The Complete Practical Guide

Authentication is the proof-of-identity step: the login, the second factor, the password reset, the remember-me cookie. An authentication vulnerability is anything that lets you skip, fake, or shortcut that proof and become a user you are not. The interesting part is how rarely it requires the actual password. You enumerate who exists, spray a common password across all of them, bypass a second factor that was never really enforced, or poison a reset link so the victim's token lands in your inbox. This guide maps the whole surface. Want to feel it rather than read about it? Sign up free and try it on a live target.

What is an authentication vulnerability?

The mental model in one sentence: authentication fails whenever the server accepts a proof of identity it should have rejected. That proof might be a password, a one-time code, a reset token, or a signed cookie. Each is a checkpoint, and each checkpoint has a way to be skipped, faked, replayed, or guessed. Most real findings are not cryptographic breaks, they are logic flaws: a step that is optional when it should be mandatory, a token that is trusted when it should be verified, an error message that reveals more than it should.

The three factors

Authentication draws on three kinds of proof:

• Something you know (a password, a PIN).
• Something you have (a phone, a hardware key, an authenticator app).
• Something you are (a fingerprint, a face).

Stacking two or more is multi-factor authentication (MFA), and it genuinely raises the bar, because stealing a password no longer gets you in on its own. But MFA is not a guarantee. If the second factor is not enforced on the server, or the code can be brute-forced, or a weaker recovery path exists, the extra factor collapses back to a single broken one.

Where authentication breaks

Authentication is not one feature, it is a set of flows, and each is an attack surface:

• The login form itself (enumeration, brute force, spraying).
• The registration flow (which leaks whether an account exists).
• The password-reset flow (token and host-header abuse, the richest surface).
• The remember-me path (forgeable persistent cookies).
• The MFA step (skippable, tamperable second factors).
• SSO and social-login handoffs (trusted redirects and replayable assertions).

A single app usually has several of these, and you only need one to break.

How to find authentication flaws

The method is consistent across every flow:

• Enumerate valid accounts first. Half the work disappears once you know a username is real.
• Probe the rate limiting. Is there any? Is it keyed only on something you can spoof?
• Read every error message. "Invalid username" and "invalid password" are different answers.
• Diff responses and timings. A few bytes of length difference, a 200 versus a 302, a slower response, each is an oracle.
• Inspect every cookie and token. Decode them. Is a session id rotated at login? Is a remember-me cookie signed, and with what?

The cheat sheet collects the exact signals.

Username enumeration

Knowing which accounts exist halves the work of every other attack. Apps leak it constantly: a different error for a bad username than a bad password, a different status code, a different response length, a slower response for a real user, a reset form that says "email sent" only for real accounts. Username enumeration covers every tell and how to script the diff.

Password-based attacks

Once you have valid usernames, you go after the passwords. Vertical brute force (many passwords, one user), password spraying (one common password, many users, to dodge lockout), credential stuffing (replaying breach combos), and plain default credentials. Password-based attacks covers when each one works and why spraying beats brute force in the real world.

When brute-force protection fails

Rate limits and lockouts are supposed to stop the above, and they are frequently built wrong. A throttle keyed on a spoofable source header, a counter you can reset, a lockout you can weaponize into denial of service against real users. Flawed brute-force protection covers bypassing the defenses that are meant to stop credential attacks.

Breaking MFA and OTP

A second factor only helps if it is enforced and the code is sound. Attackers skip straight to the post-login page, tamper the verification response, brute-force a short numeric code with no rate limit, replay an old code, or downgrade to a weaker recovery flow. MFA and OTP bypass covers the logic and code weaknesses that defeat the second step.

Password-reset abuse

The reset flow is the single richest surface, because it mints a credential and emails it. Poison the Host header so the reset link points at your server, read a token leaked in a response, reuse a token that never expires, or swap the account a token is bound to. Password-reset flaws walks the reset flow to full account takeover.

Session and persistent-token attacks

Even after a clean login, the session can betray the user. A session id that is not rotated at login enables fixation (you plant an id, the victim logs in, you ride it). A remember-me cookie that is guessable or weakly signed can be forged. Session attacks covers fixation and persistent-cookie forgery.

Other mechanisms

Beyond the core flows, SSO handoffs can trust an unvalidated return URL or a replayable assertion, social login can be taken over through an email collision, a "keep me logged in" shortcut can skip re-authentication on sensitive actions, and logout sometimes fails to invalidate the session. Other mechanisms covers these edges.

A worked example

Say you are handed a login with no other information. First you enumerate: you submit a known-bad username and a random one, and notice the real one returns "invalid password" while the fake returns "invalid username." You harvest a list of valid accounts that way. Next you spray a single weak password, Welcome1, across all of them, staying under any per-account lockout, and one account accepts it, but it has MFA. So you pivot to the reset flow: you request a reset for a high-value account and poison the Host header so the emailed link points at your server. When an admin triggers a reset, the token lands in your logs, and you set a new password. That is the loop: enumerate, attack the weakest credential, and if a factor blocks you, move to the flow that does not. No password was ever cracked for the account that mattered.

Prevention

• Return identical, generic errors for every failed login, reset, and signup so nothing reveals whether an account exists.
• Rate-limit server-side on the account and a trustworthy signal, never solely on a spoofable header, and prefer exponential backoff over hard lockouts that enable denial of service.
• Enforce MFA on the server at the final sensitive step, prefer phishing-resistant factors over SMS, and make one-time codes single-use, short-lived, and rate-limited.
• Issue reset tokens that are high-entropy, single-use, time-limited, and bound to one account, never placed in a response, with the reset URL built from a server-side allow-listed host rather than the Host header.
• Rotate the session id at login and sign all session and persistent state so nothing client-held is trusted.

The full per-mechanism detail is in securing authentication.

Where it connects

Authentication sits next to two topics you will reach for constantly. When the credential in play is a token, JWT attacks covers forging and cracking it directly, and a forged session or remember-me cookie is the same idea. And once you have taken over an account, broken access control is what you abuse next, because authentication gets you in as a user and authorization decides what that user can reach.

Where to go next

Work through the cluster in order, or jump to what you need. Start with username enumeration to find valid accounts, then password-based attacks and flawed brute-force protection. When you want every signal and payload in one place, the authentication cheat sheet has them. And when you are ready to break something real, sign up free and start hacking.