Dictionary Attack in Express with Cockroachdb

A dictionary attack in an Express API that uses CockroachDB typically arises from weak authentication endpoints combined with predictable usernames and improperly rate-limited login routes. When login logic performs direct SQL checks such as SELECT * FROM users WHERE email = $1 without constant-time comparison or account lockout, an attacker can iteratively submit common credentials and observe differences in timing or response messages. CockroachDB, while strongly consistent and resilient to infrastructure failures, does not inherently prevent application-layer brute-force behavior; the database faithfully executes queries, and if the Express route does not enforce rate limiting or secure password verification, the attack surface remains open.

Insecure implementations might concatenate user input into SQL strings or use naive parameterized queries that still allow rapid attempts because there is no per-IP or per-account throttling. For example, an endpoint like /api/login that returns 401 for unknown users but 400 for known users with bad passwords can leak user enumeration information. An attacker can compile a list of emails (from public sources or data breaches) and run a dictionary attack against the Express route, relying on CockroachDB to serve each query quickly. Without additional controls such as exponential backoff, captcha, or multi-factor authentication, the combination of Express routing, CockroachDB as the backend, and weak credential policies makes successful automated dictionary attacks feasible.

Another vector involves password reset or account confirmation flows where tokens are predictable or time-limited checks are inconsistent. If the Express app issues a token and stores it in CockroachDB with a short expiry but does not enforce rate limits on verification attempts, attackers can brute-force tokens or iterate through common passwords by checking token validity responses. The framework’s middleware stack (body parsing, CORS, cookie settings) may inadvertently expose timing differences or error messages that aid attacker refinement. Therefore, securing this stack requires coordinated protections at the API layer, database query patterns, and authentication policy, rather than relying on CockroachDB alone to mitigate abuse.

To reduce dictionary attack risk, enforce rate limiting and secure password handling in Express routes that interact with CockroachDB. Use constant-time comparison for credentials and avoid leaking user existence through status codes or timing differences. Below are concrete code examples that demonstrate a hardened login flow with parameterized queries and basic rate control.

const express = require('express');
const { Pool } = require('pg');
const rateLimit = require('express-rate-limit');
const bcrypt = require('bcrypt');

const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
});

const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 5,
  message: { error: 'Too many attempts, try again later' },
  standardHeaders: true,
  legacyHeaders: false,
});

const app = express();
app.use(express.json());
app.post('/api/login', loginLimiter, async (req, res) => {
  const { email, password } = req.body;
  if (!email || !password) {
    return res.status(400).json({ error: 'Missing credentials' });
  }
  try {
    const result = await pool.query(
      'SELECT id, email, password_hash, locked_until FROM users WHERE email = $1',
      [email]
    );
    const user = result.rows[0];
    const now = new Date();
    if (!user || user.locked_until && new Date(user.locked_until) > now) {
      // Use same delay and generic message to prevent timing-based enumeration
      await bcrypt.hash(password, 10);
      return res.status(401).json({ error: 'Invalid credentials' });
    }
    const match = await bcrypt.compare(password, user.password_hash);
    if (!match) {
      // Optionally increment failed attempts in CockroachDB
      await pool.query(
        'UPDATE users SET failed_attempts = COALESCE(failed_attempts, 0) + 1, locked_until = CASE WHEN (failed_attempts + 1) >= 5 THEN $1 ELSE locked_until END WHERE id = $2',
        [new Date(Date.now() + 30 * 60 * 1000), user.id]
      );
      return res.status(401).json({ error: 'Invalid credentials' });
    }
    // Reset failed attempts on success
    await pool.query('UPDATE users SET failed_attempts = 0, locked_until = NULL WHERE id = $1', [user.id]);
    return res.json({ id: user.id, email: user.email });
  } catch (err) {
    return res.status(500).json({ error: 'Internal server error' });
  }
});

app.listen(3000, () => console.log('API listening on port 3000'));

For password storage, prefer bcrypt with appropriate work factor and avoid storing plaintext secrets in CockroachDB columns used for indexing in an unsafe manner. If you use multi-region configurations, ensure that transactions affecting authentication state are routed with appropriate follower reads and consistency expectations to avoid stale checks that could weaken lockout logic.

Additionally, apply layered protections such as CAPTCHA after repeated failures and consider using secure, HTTP-only cookies for session management rather than embedding tokens in URLs. These steps complement the database-side security by reducing the likelihood of successful dictionary attacks against the Express + CockroachDB stack.