Accueil / retour à la liste

Identification and Authentication Failures

7) Identification and Authentication Failures

What it is

This category means the app fails at proving identity safely.

Simple split:

  1. Identification = “Which account is this?” (username/email/user ID)
  2. Authentication = “Prove it is really you.” (password, MFA, token, biometric)

If these controls are weak, attackers log in as other users.

Very common failures

  1. Weak password policy (123456, short passwords allowed).
  2. No MFA for risky users/actions.
  3. No rate limiting on login (easy brute force).
  4. Credential stuffing not blocked (reused leaked passwords).
  5. Session IDs are predictable or not rotated after login.
  6. Sessions never expire.
  7. “Remember me” tokens are weak or never revoked.
  8. Password reset flow is weak (guessable token, long token lifetime).
  9. User enumeration via login errors (“email not found” vs “wrong password”).

Step-by-step attack examples

Example A: Credential stuffing

  1. Attacker gets leaked username/password list from another breach.
  2. Attacker tries same combos on your login API automatically.
  3. Users who reused passwords get compromised.
  4. Attacker enters real accounts without breaking encryption.

Example B: Brute force due to no rate limit

  1. Attacker targets one account.
  2. Sends thousands of password guesses quickly.
  3. No lockout/rate limit/challenge stops attempts.
  4. Eventually one guess works.

Example C: Session fixation / weak session handling

  1. Attacker forces victim to use a known session ID.
  2. Victim logs in with that session.
  3. Server does not rotate session after authentication.
  4. Attacker reuses same session ID and hijacks account.

Tricky concepts explained

1) Authentication vs authorization

  1. Authentication = prove identity.
  2. Authorization = decide permissions after login.

You need both. A user can be authenticated but still not authorized for admin actions.

2) MFA (Multi-Factor Authentication)

MFA means using at least two different factor types:

  1. Something you know (password)
  2. Something you have (authenticator app/token)
  3. Something you are (biometric)

Important:

  1. SMS MFA is better than nothing, but vulnerable to SIM-swap.
  2. Authenticator app or hardware key is stronger.

3) Session management

After login, the app gives a session/token. If session handling is weak, attackers can bypass password entirely.

Must-have behavior:

  1. Random, high-entropy session IDs
  2. Rotate session ID after login and privilege change
  3. Short idle timeout and absolute timeout
  4. Invalidate session on logout/password change

4) User enumeration

If login says “user not found,” attacker learns valid accounts. Better:

  1. Use generic error like “Invalid credentials.”
  2. Keep response behavior consistent.

How to prevent it (clear implementation order)

  1. Enforce strong password policy and block common leaked passwords.
  2. Store passwords with strong hashing (Argon2id, bcrypt, or scrypt).
  3. Add MFA, at least for admins and high-risk actions.
  4. Add login rate limiting, lockout/backoff, and bot defenses.
  5. Detect and block credential stuffing patterns.
  6. Use secure session cookies: HttpOnly, Secure, SameSite.
  7. Rotate session/token after login and privilege elevation.
  8. Set session expiration (idle + max lifetime).
  9. Build secure password reset:
  10. Use random single-use tokens.
  11. Set short expiry.
  12. Invalidate old tokens when new one is issued.
  13. Re-authenticate users for sensitive actions (email/password change, payouts).
  14. Use generic authentication error messages.
  15. Log and alert on suspicious auth events (impossible travel, many failures).

Detection checklist

  1. Can I brute-force login quickly from one IP or many IPs?
  2. Are reused leaked passwords accepted?
  3. Is MFA required where risk is high?
  4. Does session ID rotate right after login?
  5. Are old sessions invalidated after password reset/change?
  6. Do login errors reveal valid usernames/emails?
  7. Are suspicious auth events monitored and alerted?

Business impact

  1. Account takeover.
  2. Fraud and unauthorized transactions.
  3. Data theft and privacy incidents.
  4. Admin compromise leading to full environment breach.