Rainbow Table Attack in Express with Dynamodb

A rainbow table attack leverages precomputed hash chains to reverse cryptographic hashes, typically targeting password storage. In an Express application using DynamoDB as the user store, the risk arises when passwords are hashed without a unique, high-entropy per-user value (a salt). If identical passwords across users produce the same hash, an attacker who obtains the DynamoDB table can use a rainbow table to map hashes back to plaintext passwords. This is common when the application uses a fast, unsalted algorithm like unsalted SHA-1 or MD5, or a low-work factor algorithm such as unsalted SHA-256 for passwords stored in DynamoDB items.

DynamoDB itself does not introduce the vulnerability; the exposure comes from how the application hashes and stores credentials before writing them to the table. For example, an Express route that computes a hash of the user-supplied password and saves it without a salt allows an attacker who reads the DynamoDB item to perform offline cracking using a rainbow table. The stateless, key-value nature of DynamoDB means there is no built-in protection against bulk reads, so if the table is compromised (for instance, due to misconfigured IAM policies or a leaked backup), the attacker can retrieve hashes and use a rainbow table to identify weak passwords. This aligns with the OWASP API Top 10 A07:2021 – Identification and Authentication Failures, and relevant real-world patterns such as credential stuffing when reused passwords are found via rainbow tables.

An example of a vulnerable Express route writing unsalted SHA-256 hashes to DynamoDB:

const crypto = require('crypto');
app.post('/register', (req, res) => {
  const { username, password } = req.body;
  // Vulnerable: unsalted, fast hash — susceptible to rainbow table attacks
  const hash = crypto.createHash('sha256').update(password).digest('hex');
  const params = {
    TableName: 'Users',
    Item: {
      username: { S: username },
      password_hash: { S: hash }
    }
  };
  docClient.put(params, (err, data) => {
    if (err) { return res.status(500).send('Error'); }
    res.status(201).send('User registered');
  });
});

In this scenario, the same password always yields the same hash, and if the Express app does not enforce strong password policies or use a salt, an attacker can leverage a precomputed rainbow table to recover credentials from the DynamoDB table. The risk is compounded when the application also lacks rate limiting on authentication endpoints, permitting offline attacks at scale.

To mitigate rainbow table attacks when using Express with DynamoDB, store passwords using a salted, slow key derivation function such as Argon2id or bcrypt. A unique salt per user ensures that even identical passwords result in distinct hashes, rendering precomputed rainbow tables ineffective. The following examples show secure registration and login flows using the bcrypt library with DynamoDB.

First, install the library:

npm install bcrypt aws-sdk

Secure registration with salt and hashing:

const bcrypt = require('bcrypt');
const AWS = require('aws-sdk');
const docClient = new AWS.DynamoDB.DocumentClient();

app.post('/register', async (req, res) => {
  const { username, password } = req.body;
  try {
    // Generate a salt and hash the password
    const saltRounds = 12;
    const hash = await bcrypt.hash(password, saltRounds);
    const params = {
      TableName: 'Users',
      Item: {
        username: username,
        password_hash: hash
      }
    };
    await docClient.put(params).promise();
    res.status(201).send('User registered');
  } catch (err) {
    res.status(500).send('Error');
  }
});

Secure login with constant-time comparison:

app.post('/login', async (req, res) => {
  const { username, password } = req.body;
  const params = {
    TableName: 'Users',
    Key: { username: username }
  };
  try {
    const data = await docClient.get(params).promise();
    if (!data.Item) { return res.status(401).send('Invalid credentials'); }
    const storedHash = data.Item.password_hash;
    const match = await bcrypt.compare(password, storedHash);
    if (match) {
      res.status(200).send('Authenticated');
    } else {
      res.status(401).send('Invalid credentials');
    }
  } catch (err) {
    res.status(500).send('Error');
  }
});

Additional DynamoDB hardening steps include:

• Enforce a strong password policy in Express (minimum length, mixed character classes) to reduce the effectiveness of any offline attack.
• Ensure the DynamoDB table uses encryption at rest (AWS-managed KMS keys) to protect stored hashes if the backup or table is accessed improperly.
• Apply least-privilege IAM policies so the Express service role can only perform required DynamoDB actions (e.g., dynamodb:PutItem for registration, dynamodb:GetItem for login) and cannot scan or export the full table.
• Add rate limiting on authentication endpoints in Express to slow down online guessing attempts, complementing the offline protections provided by salted hashes.

These measures align with the remediation guidance provided by middleBrick’s security checks, which map findings to frameworks such as OWASP API Top 10 and provide prioritized remediation steps without claiming to automatically fix issues.