KAHIBARO
Discord Login Register ☰
☰

15.7 Authentication Attacks

Table of Contents

Understanding Authentication Attacks

Authentication attacks try to break the “who are you” part of security. They target login, signup, reset password, or any place where users prove their identity. In this chapter you will see how attackers think about authentication, what common attacks look like, and which backend mistakes make them possible.

We will not fully re-explain password hashing, tokens, or OAuth here, since those have their own chapters. Here the focus is how those mechanisms can be attacked, and what you should watch out for when you build a backend.

The Attacker’s Goal

An attacker usually wants to:

They do not always need your database. If they can act as a victim’s session in your API, for that victim the effect is the same as “my account was hacked.”

You can think of authentication as two questions:

  1. “Who are you?” (identity)
  2. “Prove it.” (credential)

Authentication attacks try to either guess or steal the proof, or skip that proof step entirely.

Credential Stuffing

Credential stuffing uses real username and password pairs that leaked from other sites. Attackers assume users reuse passwords everywhere.

Example:

How Credential Stuffing Looks in Logs

You might see patterns like:

Example sequence:

text 
POST /api/login
body: {"email": "alice@gmail.com", "password": "Sunshine123"}
POST /api/login
body: {"email": "bob@yahoo.com", "password": "Password123"}
POST /api/login
body: {"email": "charlie@outlook.com", "password": "Qwerty1!"}

Same IP, different users, each tried once. This is very different from brute force, where many attempts target the same user.

Why Credential Stuffing Works

Main reasons:

Rule: Assume your users reuse passwords. Your job is to make stolen credentials from other sites much less effective against your backend.

Defenses Specific to Credential Stuffing

You will cover the details in other chapters, but for credential stuffing pay attention to:

Brute-Force and Password Guessing

Brute-force attacks try to guess a user’s password by trying many possibilities. These can be:

Brute-Force Patterns

Typical brute-force uses multiple attempts against the same account:

text 
POST /api/login
{"username": "alice", "password": "123456"}
POST /api/login
{"username": "alice", "password": "alice123"}
POST /api/login
{"username": "alice", "password": "Password123"}
POST /api/login
{"username": "alice", "password": "A1ice!2024"}

This might be done from one IP or many IPs to hide the pattern.

Account Enumeration via Error Messages

A mistake that helps brute-force is telling attackers which usernames exist.

Bad design:

Now the attacker can:

  1. Enumerate valid usernames using the message or status code.
  2. Brute-force only the valid accounts.

Better:

Rule: Do not reveal whether a username or email exists during login, password reset, or registration checks.

Simple Brute-Force Protections

Common protections you implement on the backend:

Example of progressive delays in pseudocode:

python 
def login(user_id, password):
    if failed_attempts_for(user_id) > 5:
        time.sleep(2)  # Slow down brute force
    if not check_password(user_id, password):
        record_failed_attempt(user_id)
        return error("Invalid username or password")
    reset_failed_attempts(user_id)
    return success()

Be careful: account lockout can itself be abused as a denial of service. If locking happens too quickly or lasts too long, an attacker can keep users locked out.

Password Spraying

Password spraying is similar to brute-force, but with a twist:

Example:

text 
Try password "Summer2024!" for each user in the organization list:
alice@company.com
bob@company.com
carol@company.com
...

Advantages for attackers:

Detecting Password Spraying

Indicators:

Defenses are similar to brute-force, but you should also:

Phishing and Social Engineering

Phishing is not a pure backend attack, but it often leads to valid credentials being used against your backend. Attackers trick users into:

Once the attacker has valid credentials, your backend will consider them legitimate unless you add extra protections.

How Backend Design Influences Phishing Impact

Even though phishing is a user-side problem, backend decisions affect damage:

Example: if your API issues never-expiring bearer tokens, and a user is phished, the attacker has long-term access. If instead your tokens expire quickly and refresh tokens are tied to a specific device, the damage is reduced.

Session Hijacking

Session hijacking is when an attacker gets hold of a valid session identifier and uses it to impersonate the rightful user. For a web backend that can be:

How Attackers Get Session IDs

Common paths:

Example: Cookie-Based Session

If your site sets:

http 
Set-Cookie: sessionid=abc123; Path=/; HttpOnly; Secure; SameSite=Lax

An attacker who somehow obtains abc123 can send:

http 
GET /account
Cookie: sessionid=abc123

Your backend will treat this as the authenticated user.

Protecting Sessions

Key backend-side protections:

Rule: Never treat any user-supplied session ID or token as safe. Always assume an attacker could send a stolen one and design with expiration, rotation, and invalidation.

Token Theft and Replay

Many modern backends use JWT or other bearer tokens. These tokens are often short strings that, if stolen, give full access for their lifetime.

A typical token-based flow:

  1. User logs in with username and password.
  2. Backend returns an access token, for example a JWT, and sometimes a refresh token.
  3. Client includes the access token in an Authorization: Bearer <token> header.

If an attacker steals the token, they can perform any request that the real user can, until the token expires or is revoked.

Common Token Theft Paths

Token Replay

Replay is when an attacker records a valid authentication step or token, then reuses it later.

Example:

  1. User makes a valid API call with Authorization: Bearer X.
  2. Attacker on the network captures this request.
  3. Attacker sends the same header to your API again.
  4. Request succeeds because the token is still valid.

Replay is easier if:

Basic Defenses for Token-Based Systems

As a backend developer, you can:

Example of a safer JWT configuration conceptually:

MFA Bypass and Weak Second Factors

Multi-factor authentication (MFA) combines:

  1. Something you know, like a password.
  2. Something you have, like a phone or hardware key.
  3. Something you are, like a fingerprint.

MFA reduces many authentication attacks, but if implemented poorly it can be bypassed.

Common Weaknesses

Example logic flaw:

Backend Responsibility for MFA

As the backend:

Logic Flaws in Authentication Flows

Not all attacks involve guessing or stealing credentials. Some attacks exploit mistakes in how you designed the authentication steps.

Example 1: Skipping Email Verification

Flow:

  1. User signs up with user@example.com.
  2. Backend creates user with email_verified = false.
  3. Verification email is sent with a token.

Bug:

Impact:

Example 2: Weak “Remember Me” Tokens

Flow:

  1. User logs in and checks “Remember me.”
  2. Backend sets a cookie remember_token="12345".
  3. On future visits, if remember_token is present, you log them in automatically.

Bug:

Attack:

Safer approach:

Example 3: Insecure “Magic Link” Login

Magic link login:

  1. User enters email.
  2. Backend sends a login link: /magic-login?token=<random>.
  3. When clicked, the token logs the user in.

Bug:

If an attacker gets an old magic link URL, they can log in as the user. Your backend should ensure these tokens:

Password Reset Attacks

Password reset is often the weakest link in authentication, since it provides a way to take over an account without the existing password.

Typical secure flow:

  1. User submits their email.
  2. Backend sends an email with a short-lived, random token in a reset link.
  3. User clicks the link, sets a new password.
  4. Backend invalidates the token and ends existing sessions.

Common mistakes:

Example of an insecure scheme:

text 
Reset link:
https://example.com/reset?user_id=123&ts=1690000000

Attacker guess:

Better:

text 
Reset link:
https://example.com/reset?token=3fbb9e9a-66a4-4e6d-b27a-4466db5e7c33

Backend stores:

token_hash (SHA-256)user_idexpires_atused
a9f5...1232026-08-27 10:30:000

On use:

  1. Hash the incoming token.
  2. Look up the hashed token.
  3. Check it exists, not expired, not used.
  4. Mark as used.

OAuth and Social Login Misuse

OAuth 2.0 and social logins like “Login with Google” or “Login with GitHub” reduce password handling on your side, but introduce new types of mistakes.

Typical secure sequence:

  1. Your app redirects the user to the provider with a client id, redirect URI, and state.
  2. User logs in at the provider and consents.
  3. Provider redirects back with a code.
  4. Your backend exchanges the code for tokens and retrieves the user profile.
  5. Your backend creates or finds a local account for that external id.

Common mistakes:

Example attack scenario without state:

  1. Attacker logs in with their Google account via your app and sees the redirect URL.
  2. Attacker sends that URL to a victim and tricks them to click it.
  3. The victim’s browser sends the request, but the resulting session on your site is bound to the attacker’s Google identity.
  4. Confusing behavior or account confusion can follow, depending on implementation.

As a backend developer:

API Keys and Shared Secrets

Some backends use API keys or shared secrets for machine-to-machine authentication. These are often long strings like:

text 
sk_live_51JLv6bF2...

If these keys are exposed, anyone who has the key can act as the authorized client.

Common exposure paths:

As an attacker:

From the backend side:

Detecting and Responding to Authentication Attacks

Backend developers rarely stop all attacks entirely, but you can make them visible and limit damage.

What to Log

At minimum, for authentication-related endpoints, log:

Avoid logging:

Simple Detection Rules

Examples:

Once detected, you can:

Summary

Authentication attacks focus on breaking “who are you” rather than directly breaking your encryption or database. As a backend developer, you need to be aware of:

Your authentication system is not just a login form. It is the entire set of flows around account access, session management, reset, and external login. Designing and implementing these flows carefully, and watching how they are used in the wild, is one of the most important skills in backend security.

Views: 5

Comments

Please login to add a comment.

Don't have an account? Register now!

© 2025 Kahibaro
Visitors: 3162 / 24h
Impressum / Imprint
Datenschutz / Data Policy