How to Prevent Login Brute-Force With Rate Limiting

The threat: unlimited password guesses

Without rate limiting, an attacker can POST to /login as fast as the server will accept connections. A four-digit PIN has 10,000 combinations; at 1,000 requests per second that's cracked in 10 seconds. The fix is to count failed attempts and return 429 Too Many Requests once the threshold is crossed.

Tracking attempts in memory

Use a defaultdict(list) that maps each client IP to a list of timestamps for recent failures. Before processing a login, prune expired entries and check the count:

import time
from collections import defaultdict
from flask import Flask, request, jsonify

app = Flask(__name__)

_attempts = defaultdict(list)
MAX_ATTEMPTS = 5
WINDOW = 60  # seconds

@app.post("/login")
def login():
    ip = request.remote_addr or "unknown"
    now = time.time()

    # prune timestamps outside the window
    _attempts[ip] = [t for t in _attempts[ip] if now - t < WINDOW]

    if len(_attempts[ip]) >= MAX_ATTEMPTS:
        return jsonify({"error": "Too many attempts"}), 429

    data = request.get_json()
    username = data.get("username", "")
    password = data.get("password", "")

    user = check_credentials(username, password)
    if user:
        _attempts.pop(ip, None)   # clear on success
        return jsonify({"message": "Login successful"}), 200
    else:
        _attempts[ip].append(now)  # record only on failure
        return jsonify({"error": "Invalid credentials"}), 401

Key design decisions

• Prune before counting - remove timestamps older than WINDOW seconds before comparing to MAX_ATTEMPTS. This gives a true sliding window, not a fixed bucket.
• Record only on failure - append to _attempts[ip] only when credentials are wrong, not on every request. Counting all requests would lock out valid users on slow networks.
• Clear on success - _attempts.pop(ip, None) lets a user who remembers their password log in even after hitting the limit, which is the correct UX.
• Return 429, not 401 - using the correct status code lets clients and WAFs distinguish a rate-limit response from a wrong-password response.

What a blocked response looks like

# after 5 wrong attempts:
curl -s -o /dev/null -w "%{http_code}" \
  -X POST http://localhost:8000/login \
  -H "Content-Type: application/json" \
  -d '{"username": "admin", "password": "wrong"}'
# -> 429

Production upgrades

In-memory tracking works per-process but resets on restart and does not span multiple instances. For production:

• Redis - store INCR login:fail:{ip} with EXPIRE 60; survives restarts and works across a load-balanced fleet.
• Per-username tracking - an attacker who rotates IPs bypasses per-IP limits; also count failures per username.
• CAPTCHA fallback - offer a CAPTCHA challenge before the hard block so legitimate users are not locked out entirely.