Password Spraying in Fastapi with Dynamodb

Password spraying is an authentication-layer attack where a small number of common passwords are tried against many accounts. When Fastapi services use Amazon DynamoDB as the user store, the combination of an HTTP API layer and a NoSQL database can unintentionally support or expose patterns that facilitate spraying.

Fastapi endpoints that perform credential validation by querying DynamoDB (for example via boto3 or an ODM) may implement username-based lookups with conditional checks on password hashes. If the endpoint does not enforce uniform response characteristics and rate controls, an attacker can iterate passwords across multiple accounts while observing timing differences or response-code patterns that reveal valid usernames.

DynamoDB itself does not introduce the weakness, but its access patterns and error behavior can amplify risks when the API layer lacks protections. For example, a GetItem or Query against a table with a partition key on username will return different HTTP status codes (200 vs 404) depending on whether the account exists, enabling username enumeration. If the application then hashes the provided password only when the account exists, timing discrepancies can further aid an attacker. Without rate limiting on the Fastapi route and without consistent response handling, a password spraying campaign can harvest valid accounts more efficiently.

Consider a common implementation pattern where Fastapi receives a JSON payload {"username": "alice", "password": "..."}, queries DynamoDB for that username, and compares a hash if the item exists. If the endpoint does not throttle requests per IP or per user pool and returns distinct behaviors for missing users, an attacker can run a low-and-slow spray using common passwords (such as "Password1") across a list of known usernames. The absence of per-user lockout or global rate limiting in the Fastapi layer, combined with DynamoDB’s low-latency responses, can make such campaigns harder to detect.

Because middleBrick scans the unauthenticated attack surface, it can identify authentication and rate-limiting misconfigurations in Fastapi routes backed by DynamoDB. It checks whether responses are consistent for existing versus non-existing accounts, whether rate limiting is applied, and whether the API exposes timing or metadata clues that aid spraying. The scan maps findings to relevant parts of the OWASP API Top 10 and provides remediation guidance without storing or altering your data.

To reduce the risk of password spraying when Fastapi interacts with DynamoDB, apply consistent authentication responses, enforce rate limiting, and avoid leaking account existence through timing or status codes. Below are concrete, safe patterns and runnable code examples.

1. Use a constant-time authentication flow

Always perform a hash comparison, even when the username is not found, using a dummy hash to keep timing similar. This reduces information leakage via response time.

import time
import hashlib
import hmac
from fastapi import FastAPI, HTTPException
import boto3
from pydantic import BaseModel

app = FastAPI()
dynamodb = boto3.resource('dynamodb', region_name='us-east-1')
table = dynamodb.Table('users')

def constant_time_compare(a: bytes, b: bytes) -> bool:
    return hmac.compare_digest(a, b)

def hash_password(password: str, salt: bytes) -> bytes:
    return hashlib.pbkdf2_hmac('sha256', password.encode('utf-8'), salt, 100000)

class LoginRequest(BaseModel):
    username: str
    password: str

@app.post('/login')
def login(payload: LoginRequest):
    username = payload.username.strip()
    # Always fetch the item to avoid branching on existence
    try:
        response = table.get_item(Key={'username': username})
        item = response.get('Item')
    except Exception:
        # Do not reveal errors; fall back to dummy comparison
        dummy_hash = hash_password(payload.password, b'0' * 16)
        constant_time_compare(dummy_hash, b'\x00' * 32)
        raise HTTPException(status_code=401, detail='Invalid credentials')

    stored_hash = item.get('password_hash') if item else None
    salt = item.get('salt') if item else b'0' * 16

    provided_hash = hash_password(payload.password, salt)
    if stored_hash is None or not constant_time_compare(provided_hash, stored_hash):
        # Even on mismatch, do work to keep timing similar
        constant_time_compare(hash_password(payload.password, b'0' * 16), b'\x00' * 32)
        raise HTTPException(status_code=401, detail='Invalid credentials')

    return {'status': 'ok'}

2. Enforce rate limiting at the Fastapi layer

Apply per-username or per-IP throttling to limit attempts over a rolling window. This complements DynamoDB’s storage characteristics and prevents rapid sequential requests that characterize spraying.

from fastapi import Request, HTTPException
from fastapi.middleware import Middleware
from starlette.middleware.base import BaseHTTPMiddleware
import time
from collections import defaultdict

class RateLimitMiddleware(BaseHTTPMiddleware):
    def __init__(self, app, max_attempts=5, window=60):
        super().__init__(app)
        self.max_attempts = max_attempts
        self.window = window
        self.store = defaultdict(list)

    async def dispatch(self, request: Request, call_next):
        if request.url.path == '/login':
            ip = request.client.host
            now = time.time()
            self.store[ip] = [t for t in self.store[ip] if now - t < self.window]
            if len(self.store[ip]) >= self.max_attempts:
                raise HTTPException(status_code=429, detail='Too many attempts')
            self.store[ip].append(now)
        response = await call_next(request)
        return response

app.add_middleware(RateLimitMiddleware, max_attempts=5, window=60)

3. Validate and normalize input before querying DynamoDB

Normalize usernames (e.g., lowercasing) to avoid case-sensitive enumeration and ensure your queries use a consistent partition key design. Also prefer parameterized queries to prevent injection issues.

import boto3
from fastapi import Depends

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('users')

def get_user(username: str):
    # Normalize to lowercase to avoid case-based leakage
    key = {'username': username.strip().lower()}
    response = table.get_item(Key=key)
    return response.get('Item')

These measures — consistent responses, rate limiting, and safe DynamoDB access patterns — reduce the effectiveness of password spraying against Fastapi services backed by DynamoDB. middleBrick can validate that your endpoints exhibit uniform behavior and that rate-limiting controls are observable during scans.