Dictionary Attack in Fastapi with Dynamodb

A dictionary attack against a FastAPI endpoint backed by DynamoDB typically exploits weak authentication or user enumeration logic. In this combination, the API layer (FastAPI) often exposes timing differences or error messages that reveal whether a given username or email exists in DynamoDB. For example, if the endpoint performs a GetItem or Query and returns a 401 for invalid credentials but a 400 with a descriptive message for a missing user, an attacker can infer valid identities. FastAPI route handlers that directly map user-supplied identifiers to DynamoDB key expressions without constant-time checks amplify this risk. DynamoDB’s behavior—such as returning an empty item versus a ConditionalCheckFailedException—can further leak existence information over the network. Attackers use wordlists to iterate through common usernames or emails, measuring response times and status codes to refine valid accounts. Because FastAPI does not inherently enforce rate limiting on authentication routes, repeated dictionary probes are feasible. Insecure handling of credentials in logs or error traces stored in DynamoDB can also aid post-compromise analysis for attackers. The lack of enforced lockout or exponential backoff enables rapid probing. This attack surface is especially relevant for serverless FastAPI deployments where DynamoDB is the primary identity store, since unauthenticated or weakly authenticated endpoints become direct targets.

To mitigate dictionary attacks, implement constant-time verification and robust rate controls in FastAPI when interacting with DynamoDB. Use a fixed-duration hash comparison regardless of user existence and enforce per-identifier rate limits. Below is a secure FastAPI route example using boto3 with DynamoDB, demonstrating constant-time behavior and parameterized queries to avoid injection or timing leaks.

import time
import hashlib
import secrets
from fastapi import FastAPI, HTTPException, Depends
import boto3
from botocore.exceptions import ClientError

app = FastAPI()

def get_dynamodb_client():
    return boto3.client("dynamodb", region_name="us-east-1")

def constant_time_compare(val1: str, val2: str) -> bool:
    return hmac.compare_digest(val1.encode("utf-8"), val2.encode("utf-8"))

# Simulated stored hash retrieval (use a dedicated secrets manager for production)
USERS_TABLE = "users"

def verify_user(username: str, candidate_password: str) -> bool:
    client = get_dynamodb_client()
    try:
        response = client.get_item(
            TableName=USERS_TABLE,
            Key={"username": {"S": username}}
        )
        item = response.get("Item")
        stored_hash = item.get("password_hash", {}).get("S", "") if item else ""
        # Always perform a hash operation to keep timing consistent
        dummy_hash = hashlib.sha256(secrets.token_bytes(32)).hexdigest()
        actual_hash = hashlib.sha256(candidate_password.encode("utf-8")).hexdigest()
        return constant_time_compare(actual_hash, stored_hash) if stored_hash else constant_time_compare(actual_hash, dummy_hash)
    except ClientError as e:
        # Log the error securely; avoid exposing details to the caller
        raise HTTPException(status_code=401, detail="Invalid credentials")

@app.post("/login")
async def login(username: str, password: str):
    if not username or not password:
        raise HTTPException(status_code=400, detail="Missing credentials")
    # Enforce rate limiting at the infrastructure or middleware layer
    if not rate_limiter.allow(username):
        raise HTTPException(status_code=429, detail="Too many attempts")
    if verify_user(username, password):
        # Issue token on successful constant-time verification
        return {"token": "example-jwt-token"}
    else:
        raise HTTPException(status_code=401, detail="Invalid credentials")

For DynamoDB-specific hardening, ensure your table uses encryption at rest and fine-grained IAM policies to limit who can read user credentials. Implement exponential backoff and jitter in client retries to reduce noisy neighbor effects that could distort timing. Complement FastAPI protections with an API gateway or middleware that enforces global rate limits and IP-based throttling, reducing the likelihood of successful dictionary campaigns. Where possible, replace direct username enumeration with tokenized identifiers and monitor anomalous scan patterns using CloudWatch metrics integrated with your security tooling.