Password Spraying in Fiber with Cockroachdb

Password spraying is an authentication attack where an adversary attempts a small number of common passwords against many accounts, rather than many passwords against a single account. When a Fiber application uses Cockroachdb as its backend, the interaction between HTTP request handling, session management, and database queries can unintentionally aid an attacker by revealing whether a username exists and by enabling high-rate attempts across endpoints. The exposure typically arises from predictable account enumeration, missing or weak rate limiting, and verbose error messages that differ between valid and invalid users.

In a typical Fiber route, an attacker may send POST /login with a known username and a password from a spray list. If the application performs a Cockroachdb query such as SELECT id, password_hash FROM users WHERE email = $1 and the row does not exist, the query returns empty. How this outcome is handled matters: returning a generic failure message is important to avoid account enumeration, while returning distinct errors (e.g., user not found vs. invalid credentials) can leak account validity. Moreover, if the application includes per-user delays or captchas only for certain conditions, the spray can adapt to bypass these protections.

Cockroachdb’s strong consistency and distributed nature can inadvertently affect timing and error patterns. Queries that involve secondary indexes on email or username may exhibit slightly different latencies depending on whether the index lookup succeeds, which an attacker with careful timing measurements might exploit to infer existence. Additionally, transaction retries due to serialization or contention can produce different HTTP responses if error handling is not uniform, further leaking information. These subtle differences, combined with a lack of global rate limiting across the authentication route, make the Fiber + Cockroachdb stack a target for automated spraying tools.

To detect this pattern, middleBrick runs unauthenticated checks across the attack surface, including authentication and rate limiting assessments. In a scan of a Fiber API backed by Cockroachdb, findings may highlight inconsistent response behavior for valid versus invalid users, missing account lockout or delays, and endpoints without proper rate controls. Each finding includes severity, a description of the observed behavior, and remediation guidance tied to frameworks such as OWASP API Top 10 and PCI-DSS.

Remediation focuses on making authentication behavior uniform, enforcing rate limits, and ensuring that database interactions do not reveal account existence. The following examples show how to implement secure login handling in Fiber with Cockroachdb using prepared statements and consistent responses.

Uniform response and parameterized queries

Always return the same HTTP status and body shape for authentication failures, regardless of whether the username exists. Use parameterized queries to prevent injection and ensure stable behavior.

const fiber = require('fiber');
const { Pool } = require('cockroachdb'); // or a compatible driver

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

app.post('/login', async (req, res) => {
  const { email, password } = req.body;
  const client = await pool.connect();
  try {
    // Use a parameterized query; avoid string concatenation
    const result = await client.query('SELECT id, password_hash, locked_until FROM users WHERE email = $1', [email]);
    const user = result.rows[0];

    // Always perform the same password comparison work when possible
    const delayUntil = user ? user.locked_until : null;
    if (delayUntil && Date.now() < new Date(delayUntil).getTime()) {
      return res.status(403).json({ message: 'Authentication failed' });
    }

    // Use a constant-time comparison helper for password hashes
    const match = user ? await verifyPasswordConstantTime(password, user.password_hash) : false;

    // Same response shape regardless of user existence
    if (!match) {
      return res.status(401).json({ message: 'Authentication failed' });
    }

    // Successful login logic (session/token creation)
    return res.status(200).json({ message: 'Authenticated', userId: user.id });
  } catch (err) {
    // Log the error internally, but return generic message to client
    console.error('Auth error:', err);
    return res.status(500).json({ message: 'Authentication failed' });
  } finally {
    client.release();
  }
});

Global rate limiting and retries

Apply rate limiting at the Fiber middleware level to cap requests per IP or API key, and ensure retries in Cockroachdb do not produce distinguishable responses.

const rateLimit = require('async-ratelimiter');

const limiter = rateLimit({
  db: pool,
  limiter: 'fixed',
  duration: 60_000,
  max: 30, // max 30 requests per minute per key
});

app.use('/login', async (req, res, next) => {
  const key = req.ip;
  const allowed = await limiter.get(key);
  if (!allowed) {
    return res.status(429).json({ message: 'Too many requests' });
  }
  next();
});

Within Cockroachdb transactions, avoid conditional logic that changes response timing significantly. Keep retries deterministic and ensure transaction errors are mapped to the same generic failure response.

Account lockout and monitoring

Implement incremental delays or temporary lockouts after repeated failures for a given user, but ensure that the existence of the account is not revealed by these states. middleBrick can monitor endpoints for authentication anomalies and report findings tied to compliance mappings.