Brute Force Attack in Sails with Cockroachdb

A brute force attack against a Sails application using CockroachDB typically targets authentication endpoints where passwords are verified. In Sails, the default behavior for many developers is to rely on model methods and Waterline ORM queries without additional protections, which can lead to unsafe login patterns. When a login route such as POST /auth/login performs a lookup using a username or email and then compares passwords in an unthrottled loop, it exposes timing and error-difference channels that facilitate credential guessing.

With CockroachDB as the backend, these issues are not mitigated by the database itself. CockroachDB is a distributed SQL store; it does not inherently enforce rate limits or account lockouts. If Sails issues queries like User.findOne({ email: req.body.email }) and then conditionally checks the password, an attacker can iterate through usernames or passwords without triggering built-in protections. This becomes more pronounced when Sails is deployed in a horizontally scaled environment where in-memory rate limit stores are not shared across nodes, allowing attackers to parallelize attempts across instances.

The API security checks in middleBrick identify this risk under BFLA/Privilege Escalation and Rate Limiting. A scan can detect unauthenticated access to authentication-like endpoints, absence of account lockout, and missing exponential backoff. Even if the Sails app implements basic password hashing (e.g., bcrypt), unchecked request volume can still lead to successful online brute force attempts. The use of CockroachDB does not reduce this risk; in fact, its strong consistency and global distribution may inadvertently encourage developers to assume the database layer provides security controls it does not.

Consider a typical vulnerable Sails controller action:

module.exports.login = async function (req, res) {
  const { email, password } = req.body;
  const user = await User.findOne({ email });
  if (!user) {
    return res.unauthorized('Invalid credentials');
  }
  const match = await sails.helpers.passwords.compare(password, user.password);
  if (!match) {
    return res.unauthorized('Invalid credentials');
  }
  return res.ok({ token: await sails.helpers.jwt.create(user) });
};

This pattern leaks whether the email exists via different response times or messages and does not enforce rate limits per user or IP. An attacker with access to the endpoint can systematically attempt passwords, leveraging CockroachDB’s scalability to avoid connection-level throttles if the application does not implement its own controls.

Remediation focuses on reducing the attack surface for brute force attempts by introducing rate limiting, consistent error handling, and secure authentication flows. These measures should be implemented at the Sails application layer, independent of CockroachDB features, because the database does not provide account lockout or throttling.

1. Use a shared rate limiting store and enforce per-identifier throttling. With Sails, you can integrate a Redis-backed rate limiter and apply it in a policy that runs before authentication actions. This ensures that limits are respected across all instances and nodes.

2. Standardize responses to make timing and content indistinguishable between valid and invalid users. Always perform a constant-time password comparison when a user is found, and avoid early exits that depend on record existence.

3. Apply exponential backoff on repeated failures and consider introducing CAPTCHA challenges after a threshold to further slow automated attempts.

Below is a hardened Sails controller example that incorporates these principles. It uses a policy-managed rate limiter and consistent behavior regardless of whether the user exists.

// api/controllers/AuthController.js
const bcrypt = require('bcrypt');
const rateLimit = require('some-rate-limiter'); // e.g., ratelimit-flexible with Redis

module.exports.login = async function (req, res) {
  const { email, password } = req.body;
  const normalizedEmail = email ? email.trim().toLowerCase() : '';

  // Apply rate limiting by normalized email; this works across CockroachDB nodes
  const canProceed = await rateLimit.check({ key: `login:${normalizedEmail}`, limit: 5, window: 60 });
  if (!canProceed) {
    // Always return the same generic response and a fixed delay to mitigate timing leaks
    await new Promise((r) => setTimeout(r, 1000));
    return res.unauthorized('Invalid credentials');
  }

  // Fetch user; handle absence uniformly
  const user = await User.findOne({ email: normalizedEmail });
  const hashed = user ? user.password : await bcrypt.hash('dummy', 10);

  // Constant-time comparison regardless of user existence
  const match = await bcrypt.compare(password, hashed);
  if (!match) {
    // Optional: increment failed counter for monitoring
    return res.unauthorized('Invalid credentials');
  }

  // Successful login path
  return res.ok({ token: await sails.helpers.jwt.create(user) });
};

Define a policy to enforce the rate limit globally and attach it to the login route in config/policies.js:

// config/policies.js
module.exports.policies = {
  AuthController: {
    login: ['rateLimiterPolicy']
  }
};

By combining application-layer rate limiting with consistent response patterns, you reduce the feasibility of brute force attacks regardless of whether CockroachDB is used as the backend. middleBrick scans can validate that these controls are present and flag any endpoints that remain unthrottled or expose differing behavior for existing versus non-existing users.