Dictionary Attack in Fiber with Dynamodb

A dictionary attack in a Fiber application that uses DynamoDB typically arises from insecure authentication or user enumeration logic. When login or password-reset endpoints accept user-supplied identifiers (such as email or username) and query DynamoDB without proper safeguards, the application may leak existence information through timing differences or error messages. For example, an endpoint like /login that performs a GetItem on a users table keyed by email can exhibit measurable latency when the row exists versus when it does not, enabling an attacker to iteratively guess valid emails using a wordlist. If the API also returns distinct messages for "user not found" versus "incorrect password," the attacker learns which identifiers are valid.

DynamoDB patterns can inadvertently support or amplify dictionary attack surface. If your application queries by non-partition key attributes (e.g., using a Global Secondary Index on email) without enforcing strict rate limits or using case-insensitive constant-time comparison, the enumeration becomes easier. In a black-box scan, these behaviors are observable as inconsistent response times or differing HTTP status codes across requests. This maps to common OWASP API Top 10 risks such as excessive data exposure and broken authentication. The issue is not DynamoDB itself but how the application interacts with it through unauthenticated or weakly protected endpoints.

Consider an endpoint that accepts an email parameter and performs a query against a DynamoDB table:

// Risky login handler in Fiber (Node.js)
app.post('/login', async (req, res) => {
  const { email } = req.body;
  const params = {
    TableName: 'users',
    Key: {
      email: email.toLowerCase().trim()
    }
  };
  const data = await dynamoDb.get(params).promise();
  if (!data.Item) {
    return res.status(404).json({ message: 'User not found' });
  }
  // password comparison omitted for brevity
  res.json({ message: 'Proceed with password check' });
});

If the Key does not match the table’s primary key structure or if a GSI is used, the query may fall back to a less efficient scan or produce errors that an attacker can probe. Without rate limiting or masking of user existence, a dictionary attack becomes practical: an attacker iterates through common emails, observing response codes and timing to infer valid accounts.

In the context of middleBrick’s 12 security checks, a dictionary attack scenario involving Fiber and DynamoDB would be flagged under Authentication and BOLA/IDOR checks. The scanner tests unauthenticated endpoints for user enumeration via timing and response differences, and it checks whether IAM policies and table design minimize exposure. Findings include severity ratings and remediation steps rather than attempting to fix the service, consistent with middleBrick’s role as a detection and reporting tool.

To mitigate dictionary attack risks when using Fiber with DynamoDB, focus on making authentication paths indistinguishable regardless of whether a user exists and reducing opportunities for enumeration. Below are concrete, DynamoDB-oriented code examples for a safer login flow.

1. Use a constant-time comparison for password checks and avoid leaking user existence. Always perform a key-based lookup with a placeholder response when the user is not found, and ensure the response time remains similar.

// Safer login handler in Fiber (Node.js)
const crypto = require('crypto');

// Dummy item for constant-time comparison
const dummyItem = { passwordHash: crypto.randomBytes(64).toString('base64') };

app.post('/login', async (req, res) => {
  const { email, password } = req.body;
  const emailKey = email.toLowerCase().trim();
  const params = {
    TableName: 'users',
    Key: {
      email: emailKey
    }
  };
  const data = await dynamoDb.get(params).promise();
  const realItem = data.Item;

  // Constant-time comparison to avoid timing leaks
  const candidateHash = realItem ? realItem.passwordHash : dummyItem.passwordHash;
  const candidateSalt = realItem ? realItem.salt : 'fixedsaltplaceholder';

  // Use a slow, constant-time hash comparison (e.g., pbkdf2 with many iterations)
  const hash = crypto.pbkdf2Sync(password, candidateSalt, 100000, 64, 'sha512').toString('base64');
  const isValid = timingSafeEqual(Buffer.from(hash), Buffer.from(candidateHash));

  // Always send the same generic message
  if (!isValid) {
    return res.status(401).json({ message: 'Invalid credentials' });
  }
  res.json({ message: 'Login successful' });
});

function timingSafeEqual(a, b) {
  if (a.length !== b.length) return false;
  let result = 0;
  for (let i = 0; i < a.length; i++) {
    result |= a[i] ^ b[i];
  }
  return result === 0;
}

2. Enforce rate limiting at the API and DynamoDB level to slow down iterative guesses. Use a token-bucket or sliding-window approach, and consider conditional writes to prevent excessive request bursts.

// Simple in-memory rate limiter for Fiber (example; use Redis in production)
const rateLimitWindowMs = 15 * 60 * 1000; // 15 minutes
const maxAttempts = 5;
const attempts = new Map();

app.post('/login', (req, res, next) => {
  const ip = req.ip;
  const now = Date.now();
  const record = attempts.get(ip) || { count: 0, start: now };

  if (now - record.start > rateLimitWindowMs) {
    record.count = 0;
    record.start = now;
  }
  record.count += 1;
  attempts.set(ip, record);

  if (record.count > maxAttempts) {
    return res.status(429).json({ message: 'Too many requests' });
  }
  next();
}, async (req, res) => {
  // Proceed to DynamoDB lookup as shown above
});

3. Design DynamoDB tables and GSIs to avoid exposing sensitive attributes as keys where possible. If you must support lookups by email, consider storing a normalized (e.g., hashed) version of the identifier as the partition key, and keep the raw email as an attribute. This reduces the risk of enumeration via query patterns.

// Example table design and query using a hashed identifier
const crypto = require('crypto');

function hashEmail(email) {
  return crypto.createHash('sha256').update(email.toLowerCase().trim()).digest('hex');
}

app.post('/login', async (req, res) => {
  const { email, password } = req.body;
  const emailHash = hashEmail(email);
  const params = {
    TableName: 'users',
    Key: {
      email_hash: emailHash
    }
  };
  const data = await dynamoDb.get(params).promise();
  const item = data.Item;

  if (!item) {
    // Use dummy hash to keep timing consistent
    const dummyHash = hashEmail('dummy@example.com');
    const dummyParams = { TableName: 'users', Key: { email_hash: dummyHash } };
    await dynamoDb.get(dummyParams).promise();
    return res.status(401).json({ message: 'Invalid credentials' });
  }

  // Perform constant-time password verification as shown earlier
  res.json({ message: 'Login successful' });
});

These DynamoDB-aware changes reduce the attack surface for dictionary attacks by minimizing timing leaks and ensuring that query patterns do not reveal valid identifiers. When combined with broader protections like rate limiting and secure password storage, they align with best practices for authentication security.