Timing Attack in Flask with Dynamodb

A timing attack in a Flask application that interacts with Dynamodb can occur when response times differ based on secret-dependent branching, such as iterating over candidate credentials or checking user existence before validating a signature. In Flask, developers often build login or token verification endpoints that first query Dynamodb for a user or API key and then perform additional cryptographic checks. If the query or subsequent logic short-circuits on the first mismatch, an attacker can measure subtle differences in HTTP response times and infer information about valid usernames, API keys, or HMAC comparisons.

With Dynamodb, timing variability can stem from conditional checks like if item and item['password'] == candidate where a missing item or a mismatched field causes an early return. Flask routes that use Python’s hmac.compare_digest correctly are safer, but if the developer compares strings with == before calling hmac.compare_digest, early-exit branches introduce measurable differences. An attacker sending many crafted requests can observe millisecond-level differences and gradually recover a secret or valid identifier.

The combination of Flask’s lightweight request handling and Dynamodb’s key-value access can unintentionally expose these differences, especially when error handling or logging introduces additional timing noise or when conditional logic around try/except around get_item or query creates divergent paths. For example, returning a generic 401 for both missing users and invalid credentials is important, but the server must still execute a constant-time verification routine regardless of whether the user exists in Dynamodb.

Real-world attack patterns mirror those in the OWASP API Top 10 and CWE timing-related weaknesses: an attacker iterates over possible tokens or usernames while measuring response times. In CI/CD pipelines using the middleBrick GitHub Action, such vulnerabilities can be flagged when scans detect unauthenticated endpoints that exhibit timing-sensitive behavior across multiple probes.

To illustrate a vulnerable pattern in Flask with Dynamodb, consider this example that should be avoided:

import boto3
from flask import Flask, request, jsonify
import hmac
import hashlib

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

@app.route('/login', methods=['POST'])
def login():
    data = request.get_json()
    username = data.get('username')
    password = data.get('password')
    resp = table.get_item(Key={'username': username})
    item = resp.get('Item')
    if not item:
        # Early return on missing user introduces timing difference
        return jsonify({'error': 'Invalid credentials'}), 401
    # String comparison is not constant-time
    if item['password'] != password:
        return jsonify({'error': 'Invalid credentials'}), 401
    return jsonify({'ok': True}), 200

In the above, the early if not item branch leaks existence via timing. Even if the final comparison uses hmac.compare_digest, the path divergence before it can be detectable. A safer approach ensures the same control flow regardless of whether the user exists, as shown in the remediation section.

Remediation focuses on ensuring constant-time behavior for verification steps and avoiding early branching based on sensitive data. In Flask with Dynamodb, this means performing a read for the user key regardless of existence and using constant-time comparison for any secret material. Avoid conditional password checks and ensure error paths do not introduce timing differences.

Use a pattern that always hashes the provided password candidate with the stored salt/key material and compares in constant-time. Below is a concrete, secure example:

import boto3
from flask import Flask, request, jsonify
import hmac
import hashlib
import os

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

def verify_password(stored_key_material, provided_password):
    # Use stored key material (e.g., a salted hash or HMAC key) to verify
    expected = hashlib.pbkdf2_hmac('sha256', provided_password.encode('utf-8'), stored_key_material['salt'], 100000)
    return hmac.compare_digest(expected, stored_key_material['derived_key'])

@app.route('/login', methods=['POST'])
def login():
    data = request.get_json()
    username = data.get('username')
    password = data.get('password')
    try:
        resp = table.get_item(Key={'username': username})
        item = resp.get('Item')
        # Always perform a computation even if item is missing to keep timing consistent
        dummy_key = os.urandom(32)
        dummy_salt = os.urandom(16)
        if item:
            verify_password(item, password)
        else:
            # Run the same verification routine with dummy data to normalize timing
            verify_password({'salt': dummy_salt, 'derived_key': dummy_key}, password)
    except Exception:
        # Handle errors without revealing which step failed
        pass
    # Always return a generic response
    return jsonify({'error': 'Invalid credentials'}), 401

This approach ensures that the server’s execution time does not reveal whether the username exists in Dynamodb. The verify_password function uses hmac.compare_digest for constant-time comparison of derived keys. Even when the user is absent, the code path includes a comparable amount of work using dummy key material, reducing timing leakage.

For token-based authentication, you can fetch the user’s stored key material by a non-sensitive identifier (e.g., a public user ID) and apply the same constant-time verification. If using API keys, store a hashed version in Dynamodb and compare using hmac.compare_digest without branching on key presence.

When integrating with the middleBrick CLI or Dashboard, you can validate that your endpoints no longer exhibit timing-sensitive behavior by running repeated scans and reviewing the findings. The Pro plan’s continuous monitoring can help detect regressions, and the GitHub Action can enforce that new commits do not reintroduce early-exit patterns in authentication flows.

Finally, always enforce transport-layer encryption and validate input to prevent secondary side-channels. The MCP Server enables rapid scanning from your IDE so you can iterate on fixes and confirm that remediation changes do not introduce new timing anomalies.