Common Authentication Vulnerabilities and How to Fix Them
Authentication is the front door of your application. Attackers do not need a clever exploit if they can simply log in as someone else. These are the authentication weaknesses we find most often.
Credential stuffing and brute force
Attackers take username and password pairs leaked from other breaches and try them against your login. Because people reuse passwords, a small percentage succeed.
Fixes:
- Rate limit login attempts per account and per IP.
- Add bot detection or progressive challenges after repeated failures.
- Check new passwords against known breached password lists.
- Offer and encourage MFA, and require it for admins.
User enumeration
Different responses for "user not found" and "wrong password", or different timing, let attackers build a list of valid accounts.
Fixes: return the same message and similar response times for both cases on login, signup and password reset.
Weak password reset flows
Password reset is effectively a second login system and often weaker than the first.
- Predictable or long-lived tokens. Use long random tokens that expire quickly and can only be used once.
- Host header poisoning. If the reset link is built from the request's
Hostheader, attackers can make it point to their domain. Build links from a fixed configured URL. - Token leakage via referrer when the reset page loads third-party resources.
- No session invalidation. After a password reset, invalidate existing sessions.
MFA bypasses
- The MFA step can be skipped by navigating directly to a post-login URL.
- One-time codes have no rate limit, so they can be brute forced.
- Backup codes or "remember this device" tokens are weak.
- MFA can be disabled without re-authentication.
- Account recovery bypasses MFA entirely.
Fix: treat a session as fully authenticated only after MFA completes, rate limit code attempts, and require re-authentication to change security settings.
OAuth and social login mistakes
- Linking accounts by email without verifying the email at the identity provider.
- Missing or unchecked
stateparameter, enabling login CSRF. - Loose redirect URI validation.
Account takeover via email change
If a user can change their email without confirming the new address and re-authenticating, an attacker with brief session access can take over the account permanently.
Authentication checklist
| Area | Good practice |
|---|---|
| Passwords | Strong hashing such as Argon2id or bcrypt, breached password checks |
| Login | Rate limits, uniform errors, bot protection |
| MFA | Available to all, required for admins, rate-limited codes |
| Reset | Single-use, short-lived random tokens, fixed link domain |
| Sessions | Rotate on login, invalidate on reset and logout |
| Sensitive changes | Re-authentication required |
Testing authentication
SecurityInfinity agents test login, signup, reset and MFA flows for enumeration, missing rate limits, token weaknesses and bypasses, and give precise fixes. Start free.
Frequently asked questions
Should we build our own authentication?
Usually not. Use a well-maintained identity provider or framework library, and focus on configuring it correctly.
Is SMS MFA good enough?
It is better than no MFA, but vulnerable to SIM swapping. Authenticator apps and passkeys are stronger.
Are passkeys more secure than passwords?
Yes. Passkeys resist phishing and credential stuffing because there is no shared secret to steal or reuse.