Brute Force Attack in Koa with Cockroachdb

A brute force attack against a Koa application using CockroachDB typically targets authentication endpoints where usernames and passwords are verified. Because Koa is a minimalistic web framework without built-in rate limiting or account lockout, attackers can send many password guesses per second to endpoints such as /login. If the backend queries CockroachDB with a simple SELECT by username and then performs password comparison in application code, the database becomes a choke point for timing-based and online guessing attempts.

In this stack, risk is amplified when endpoints are unauthenticated or weakly rate-limited, allowing attackers to probe accounts without triggering defenses. CockroachDB, while resilient to outages and distributed by design, does not inherently prevent rapid query bursts from a single source; it will happily serve many login requests, each performing a row lookup and password hash verification. If the Koa server uses a slow hashing algorithm without work factor tuning, the backend may become a denial vector itself by consuming CPU under load. The combination therefore exposes both application-layer weaknesses (missing rate limiting) and database-layer concerns (resource saturation and potential for injection if input validation is weak).

Additionally, if session tokens or password reset tokens are predictable or leaked in logs, an attacker can pivot even without cracking the password. Because the scan category Rate Limiting is one of the 12 parallel checks run by middleBrick, findings related to missing or inconsistent throttling on authentication routes are surfaced with severity and remediation guidance. This highlights how an unauthenticated scan can detect whether login endpoints allow excessive guesses and whether responses leak information that aids online brute force campaigns.

Defending against brute force in this stack requires coordinated changes in Koa middleware and careful database interaction patterns. You should enforce rate limiting at the edge, avoid leaking user existence, and ensure database queries are resilient to injection and timing abuse. Below are concrete, realistic code examples using CockroachDB with the pg client in a Koa application.

1. Rate limiting and account protection

Use a sliding window rate limiter to restrict login attempts per identifier and IP. Store counts in CockroachDB with a TTL-like pattern using INSERT ... ON CONFLICT DO UPDATE so state survives restarts and remains consistent across nodes.

import Koa from 'koa';
import Router from 'koa-router';
import { Pool } from 'pg';

const app = new Koa();
const router = new Router();
const pool = new Pool({ connectionString: process.env.DATABASE_URL });

async function allowLogin(key) {
  const client = await pool.connect();
  try {
    const now = new Date();
    const windowStart = new Date(now.getTime() - 5 * 60 * 1000); // 5 minutes
    const res = await client.query(
      `INSERT INTO login_attempts (key, count_at) VALUES ($1, $2) ON CONFLICT (key) DO UPDATE SET count_at = login_attempts.count_at + 1, last_seen = $2 RETURNING count_at, last_seen`,
      [key, now]
    );
    const { count_at, last_seen } = res.rows[0];
    if (count_at > 10) {
      const diff = now - new Date(last_seen);
      if (diff < 5 * 60 * 1000) {
        return false; // blocked
      }
    }
    return true; // allowed
  } finally {
    client.release();
  }
}

router.post('/login', async (ctx) => {
  const { username, password } = ctx.request.body;
  const key = `login:${ctx.ip}:${username || 'unknown'}`;
  if (!(await allowLogin(key))) {
    ctx.status = 429;
    ctx.body = { error: 'Too many attempts' };
    return;
  }
  // Proceed with secure password verification
  ctx.body = { ok: true };
});

2. Safe user lookup and constant-time comparison

Always fetch a single row for the provided identifier, and use a constant-time comparison function to avoid timing leaks. Do not branch early based on user existence.

import bcrypt from 'bcrypt';

router.post('/login', async (ctx) => {
  const { username, password } = ctx.request.body;
  const safeUsername = (username || '').trim().slice(0, 256);

  const client = await pool.connect();
  try {
    const res = await client.query('SELECT id, password_hash FROM users WHERE username = $1 LIMIT 1', [safeUsername]);
    const user = res.rows[0];
    const hashed = user ? user.password_hash : await bcrypt.hash('dummy', 10);
    await bcrypt.compare(password, hashed); // constant-time regardless

    if (!user || !(await bcrypt.compare(password, user.password_hash))) {
      ctx.status = 401;
      ctx.body = { error: 'Invalid credentials' };
      return;
    }
    // Issue session token
    ctx.body = { ok: true };
  } finally {
    client.release();
  }
});

3. Prepared statements and injection safety

Always parameterize queries; never concatenate user input into SQL strings. With CockroachDB, use the $1, $2 style placeholders to ensure safe execution plans and avoid injection that could aid brute force via error messages or bypass logic.

const res = await client.query(
  'SELECT id, password_hash FROM users WHERE email = $1 AND disabled = $2 LIMIT 1',
  [email, false]
);

4. Defensive logging and token handling

Avoid logging raw passwords or full authentication payloads. Ensure session tokens are generated with strong entropy and stored with httpOnly and secure flags. Rotate tokens on privilege changes to limit lateral movement if an account is probed.

5. MiddleBrick alignment

By running middleBrick scans against your Koa endpoints backed by CockroachDB, you can detect whether authentication routes lack rate limiting, expose verbose errors, or show inconsistent throttling between user and IP dimensions. Findings include severity and remediation guidance aligned with common frameworks like OWASP API Top 10, helping you prioritize fixes without relying on the scanner to patch or block traffic.