Brute-Force Defenses and Rate Limiting

Brute-Force and Credential Stuffing: Two Different Attacks Requiring Different Defenses

Brute-force and credential stuffing are both password-guessing attacks, but they differ fundamentally in their approach and the defenses that work against them.

Brute-Force Attacks

A brute-force attack systematically tries many passwords against a single account:

• Online brute-force: The attacker sends login requests directly to the application, trying passwords from a dictionary or generating them systematically.
• Offline brute-force: The attacker obtains a password hash database and cracks it locally using GPU clusters. No interaction with the application occurs.

Online brute-force characteristics:

• Targets a single account with many password attempts
• Slow — limited by network latency and server response time
• Detectable — generates many failed login attempts from a single source
• Defended by: rate limiting, account lockouts, CAPTCHA

Offline brute-force characteristics:

• Not detectable by the application — no login attempts are made
• Extremely fast — billions of guesses per second on GPU clusters
• Defended by: strong password hashing (Argon2id, bcrypt), password complexity requirements

Credential Stuffing

Credential stuffing is an attack where an attacker replays username and password pairs leaked from other services:

• The attacker obtains a list of credentials from a data breach (e.g., from Have I Been Pwned or dark web marketplaces)
• They use automated tools to try these credential pairs on many different websites
• The attack exploits password reuse — users who use the same password across multiple services

Credential stuffing characteristics:

• Targets many accounts with a single password attempt each (or a few attempts per account)
• Fast — distributed across thousands of IP addresses to avoid rate limits
• Hard to detect — each IP makes only a few requests, appearing as normal login attempts
• Defended by: MFA, breach password detection, device fingerprinting, bot detection

Why Rate Limiting Alone Is Not Enough

Rate limiting is effective against online brute-force but insufficient against credential stuffing:

• Brute-force: One IP, many attempts → rate limiting catches it
• Credential stuffing: Many IPs, few attempts each → rate limiting misses it

A comprehensive defense requires multiple layers:

Practical Rate Limiting and Lockout Strategies

Per-Account Rate Limiting

Limit the number of failed login attempts per account within a time window:

import time
from collections import defaultdict

# Simple in-memory rate limiter (use Redis in production)
failed_attempts = defaultdict(list)

MAX_ATTEMPTS = 5
WINDOW_SECONDS = 300  # 5 minutes

def is_account_locked(username):
    now = time.time()
    attempts = failed_attempts[username]
    
    # Remove attempts outside the window
    attempts[:] = [t for t in attempts if now - t < WINDOW_SECONDS]
    
    return len(attempts) >= MAX_ATTEMPTS

def record_failed_attempt(username):
    failed_attempts[username].append(time.time())

def login(username, password):
    if is_account_locked(username):
        return {'error': 'Account temporarily locked. Try again later.'}, 429
    
    if verify_password(username, password):
        failed_attempts[username].clear()  # Reset on success
        return {'status': 'success'}
    else:
        record_failed_attempt(username)
        return {'error': 'Invalid credentials'}, 401

Per-IP Rate Limiting

Limit the number of login requests per IP address:

from flask_limiter import Limiter
from flask_limiter.util import get_remote_address

limiter = Limiter(
    key_func=get_remote_address,
    default_limits=["200 per day", "50 per hour"]
)

@app.route('/login', methods=['POST'])
@limiter.limit("5 per minute")  # Strict limit for login endpoint
def login():
    # ...

Progressive Lockouts

Instead of a hard lockout (which creates a denial-of-service vector), use progressive delays:

def get_delay(failed_count):
    """Exponential backoff based on failed attempt count."""
    if failed_count <= 3:
        return 0  # No delay for first 3 attempts
    return min(2 ** (failed_count - 3), 30)  # Max 30 seconds

def login(username, password):
    user = get_user(username)
    
    if user:
        delay = get_delay(user.failed_login_count)
        if delay > 0:
            time.sleep(delay)  # Slow down the response
        
        if verify_password(password, user.password_hash):
            user.failed_login_count = 0
            return success()
        else:
            user.failed_login_count += 1
            return failure()

Why progressive lockouts are better than hard lockouts:

• Hard lockout: After 5 failed attempts, the account is locked for 30 minutes. An attacker can deliberately lock out any user (denial of service).
• Progressive delay: Each failed attempt increases the response time. The attacker is slowed down but legitimate users are not locked out.

CAPTCHA Integration

After a threshold of failed attempts, require a CAPTCHA:

def login(username, password):
    user = get_user(username)
    
    if user and user.failed_login_count >= 3:
        if not verify_captcha(request.form.get('captcha_token')):
            return {'error': 'CAPTCHA required'}, 403
    
    # ... proceed with login

Breach Password Detection

Check new passwords against known breach corpora (e.g., Have I Been Pwned's Pwned Passwords API):

import hashlib
import requests

def is_pwned_password(password):
    """Check if password appears in known data breaches using k-anonymity."""
    sha1 = hashlib.sha1(password.encode()).hexdigest().upper()
    prefix, suffix = sha1[:5], sha1[5:]
    
    response = requests.get(f'https://api.pwnedpasswords.com/range/{prefix}')
    hashes = response.text.splitlines()
    
    for h in hashes:
        if h.split(':')[0] == suffix:
            return True  # Password found in breach
    return False

This uses k-anonymity — only the first 5 characters of the hash are sent to the API, so the full password is never transmitted.

Practice: Design a Rate Limiting Strategy

Design a rate limiting strategy for a login endpoint that:

1. Limits each account to 5 failed attempts per 15 minutes
2. Limits each IP to 20 login attempts per minute
3. Requires CAPTCHA after 3 failed attempts
4. Does not permanently lock any account