Brute Force Attack in Feathersjs with Cockroachdb

A brute force attack against a FeathersJS service backed by CockroachDB exploits two factors: predictable or missing account lockout logic in the application layer, and the scalability and strong consistency characteristics of CockroachDB that can amplify rapid request patterns. FeathersJS is a framework that typically exposes REST or real-time endpoints backed by services and hooks. If authentication endpoints (for example, a login or password reset flow) do not enforce per-identifier or per-IP rate limits, an attacker can submit many credentials guesses without effective throttling.

When FeathersJS uses CockroachDB as the data store, the backend may query user records by username or email using strongly consistent reads. CockroachDB’s serializable isolation and distributed nature ensure that these queries are accurate and up-to-date across nodes, but they do not inherently limit request velocity. Without application-level protections—such as exponential backoff, account lockout after N failures, or CAPTCHA challenges—an attacker can iterate over passwords or use credential lists more aggressively than a system with built-in throttling would allow.

The attack flow often starts with a reconnaissance step: the attacker enumerates valid usernames or email addresses by observing differences in response messages or timing when querying the authentication endpoint. In FeathersJS, this can happen if error messages are not uniform (e.g., ‘user not found’ vs. ‘incorrect password’). Once the attacker identifies valid accounts, they can focus brute force attempts on those identities. Because CockroachDB supports high throughput and low-latency reads under load, the backend may respond quickly to each guess, enabling rapid trials without obvious delays that would otherwise slow down an attacker.

Additionally, if FeathersJS services expose a password reset or token verification endpoint that relies on predictable tokens or does not enforce one-time-use and short lifetimes, an attacker can brute force token values. CockroachDB’s consistent replication means that token state updates (such as invalidation after use) are reliably propagated, but if the token space is small or not sufficiently random, the backend may validate tokens faster than an attacker would be able to guess them in a offline scenario, increasing the feasibility of online guessing.

Real-world patterns mirror known issues in the OWASP API Security Top 10, particularly under ‘Broken Authentication’ and ‘Excessive Authentication Attempts’. A concrete example is a login route that does not incorporate rate limiting or account lockout, and relies only on transport-layer security. Even with TLS, the absence of request throttling at the FeathersJS service layer leaves the system vulnerable to online credential stuffing or targeted password guessing against CockroachDB-backed user stores.

Remediation focuses on adding application-level controls around authentication flows while keeping CockroachDB as the reliable backend. You should enforce rate limiting per identifier and per IP, introduce account lockout with exponential backoff, standardize error messages, and ensure token-based flows include one-time use and short expiration times. The following examples assume a typical FeathersJS service structure with hooks and a CockroachDB adapter such as Sequelize or a direct client.

Rate limiting and uniform error responses

Implement a hook that tracks attempts by username and IP, returning the same generic message regardless of whether the username exists. A simple in-memory store or Redis can be used; the example below shows the hook logic without storing state details.

// feathers-hooks-common/rate-limit-login.js
const rateLimit = new Map();

function isRateLimited(key, limit = 5, windowSec = 60) {
  const now = Date.now();
  const entry = rateLimit.get(key) || { count: 0, resetAt: now + windowSec * 1000 };
  if (now > entry.resetAt) {
    entry.count = 0;
    entry.resetAt = now + windowSec * 1000;
  }
  if (entry.count >= limit) return true;
  entry.count += 1;
  rateLimit.set(key, entry);
  return false;
}

// Usage in a before hook
function loginRateLimitHook(context) {
  const { email } = context.data;
  const ip = context.params.ip || 'unknown';
  const identifier = email || ip;
  if (isRateLimited(`login:${identifier}`, 5, 60)) {
    throw new Error('Too many attempts. Try again later.');
  }
  return context;
}

module.exports = { loginRateLimitHook };

Account lockout with exponential backoff using CockroachDB

Store lockout metadata in CockroachDB so that it persists across restarts and nodes. The schema can include fields like failed_attempts, locked_until, and last_attempt_at. On each login, update these fields transactionally.

-- CockroachDB schema (PostgreSQL-compatible)
CREATE TABLE accounts (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  email STRING UNIQUE NOT NULL,
  password_hash STRING NOT NULL,
  failed_attempts INT DEFAULT 0,
  locked_until TIMESTAMPTZ NULL,
  last_attempt_at TIMESTAMPTZ
);

// Example hook using a Sequelize-like client for CockroachDB
const { Sequelize, DataTypes } = require('sequelize');
const sequelize = new Sequelize('postgres://user:pass@host:26257/db?sslmode=require');

const Account = sequelize.define('Account', {
  email: { type: DataTypes.STRING, allowNull: false, unique: true },
  passwordHash: { type: DataTypes.STRING, allowNull: false },
  failedAttempts: { type: DataTypes.INTEGER, defaultValue: 0 },
  lockedUntil: { type: DataTypes.DATE, allowNull: true },
  lastAttemptAt: { type: DataTypes.DATE, allowNull: true }
}, { timestamps: false });

async function checkAccountLock(email) {
  const account = await Account.findOne({ where: { email } });
  if (!account) return null; // treat uniformly
  const now = new Date();
  if (account.lockedUntil && account.lockedUntil > now) {
    return 'locked';
  }
  return account;
}

async function recordFailedAttempt(email) {
  await sequelize.transaction(async (t) => {
    const account = await Account.findOne({ where: { email }, transaction: t });
    if (!account) return;
    const newAttempts = account.failedAttempts + 1;
    const lockUntil = newAttempts >= 5 ? new Date(Date.now() + 15 * 60 * 1000) : null;
    await account.update({
      failedAttempts: newAttempts,
      lockedUntil: lockUntil,
      lastAttemptAt: new Date()
    }, { transaction: t });
  });
}

// FeathersJS before hook using the above
const { checkAccountLock, recordFailedAttempt } = require('./account-store');

async function authBruteHook(context) {
  const email = context.data.email;
  const account = await checkAccountLock(email);
  if (account === 'locked') {
    throw new Error('Account temporarily locked.');
  }
  // proceed with password verification; on failure call recordFailedAttempt(email)
  return context;
}

module.exports = { authBruteHook, recordFailedAttempt };

Secure token flows for password reset

Ensure reset tokens are long, random, single-use, and expire quickly. Store a hash of the token in CockroachDB, and invalidate after use.

-- Reset tokens table
CREATE TABLE password_reset_tokens (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  account_id UUID REFERENCES accounts(id),
  token_hash STRING NOT NULL,
  expires_at TIMESTAMPTZ NOT NULL,
  used BOOLEAN DEFAULT FALSE
);

// Token generation and verification example
const crypto = require('crypto');
function generateResetToken() {
  return crypto.randomBytes(32).toString('hex');
}

async function createResetToken(accountId) {
  const token = generateResetToken();
  const tokenHash = crypto.createHash('sha256').update(token).digest('hex');
  await Account.update({ where: { id: accountId } }, {
    // store hashed token and short expiry
  });
  return token; // send to user via email
}

async function verifyResetToken(accountId, token) {
  const tokenHash = crypto.createHash('sha256').update(token).digest('hex');
  const record = await ResetToken.findOne({
    where: {
      accountId,
      tokenHash,
      used: false,
      expires_at: { [Op.gt]: new Date() }
    },
    transaction: t
  });
  if (!record) throw new Error('Invalid or expired token');
  await record.update({ used: true }, { transaction: t });
  return true;
}

By combining these patterns—rate limiting, uniform error handling, persistent lockout state in CockroachDB, and secure token lifecycle—you reduce the effectiveness of brute force attacks against FeathersJS services while preserving the scalability and consistency benefits of CockroachDB.