Password Spraying in Aspnet with Cockroachdb

Password spraying is an authentication attack that attempts a small number of common passwords across many accounts to avoid account lockouts. In an ASP.NET application backed by CockroachDB, the interaction between the application’s identity logic, the database’s consistency and transaction behavior, and the attacker’s low-rate probing can expose or amplify weaknesses.

When an ASP.NET app uses a SQL-based user store such as CockroachDB, the typical flow is: retrieve the user record by username or email, verify the password hash, and sign in. If the app does not enforce per-user rate limits or global request throttling before the database query, an attacker can send many login requests with different usernames and a single common password. Because each request performs a SELECT on the users table, the absence of effective rate limiting allows the spray to proceed undetected.

CockroachDB’s serializable isolation and distributed nature can inadvertently facilitate low-and-slow spraying. Under serializable transactions, each login attempt may run a consistent read that does not immediately reveal whether the username exists; timing differences and error handling may disclose existence through subtle variations in response. If the application leaks whether a username exists (for example, different messages for “user not found” vs “password incorrect”), an attacker learns valid accounts and can focus spraying on them, reducing the number of attempts needed.

Moreover, if the ASP.NET app uses ORM or raw SQL without parameterized queries, crafted inputs may lead to unexpected query behavior or information leakage. Insecure handling of authentication tokens or session identifiers after login can extend the impact of a successful spray. Because CockroachDB provides strong consistency, a sprayed credential that accidentally matches can lead to immediate access across replicas, and the distributed transaction logs may retain evidence of the probing pattern useful to defenders for later analysis.

To detect this attack surface with middleBrick, a scan can exercise the login endpoints (including OpenAPI specs if available) and evaluate whether authentication controls, input validation, and rate limiting are present. The scan checks for indicators such as missing account lockout or delays, weak password policies, and whether the app’s error messages differentiate between user existence and credential correctness. These checks map to findings in Authentication, Input Validation, and Rate Limiting, and findings include severity and remediation guidance without claiming to fix the issues.

Remediation focuses on reducing information leakage, enforcing rate limits, and using safe database access patterns. Below are concrete examples for an ASP.NET Core app using CockroachDB with Npgsql.

1. Use parameterized queries and avoid leaking user existence

Always use parameters for username lookup and return a uniform error message.

using var cmd = new NpgsqlCommand("SELECT id, password_hash FROM users WHERE email = @email", conn);
cmd.Parameters.AddWithValue("@email", email);
using var reader = await cmd.ExecuteReaderAsync();
if (!await reader.ReadAsync())
{
    // Do not reveal whether the user exists
    await SignInAsync("unknown", failure: true);
    return;
}
var storedHash = reader.GetString("password_hash");
if (!Verify(password, storedHash))
{
    await SignInAsync(email, failure: true);
}

2. Enforce per-user and global rate limiting

Apply rate limiting before database calls to reduce spray impact. Example using a memory-based policy; in production consider a distributed store if you run multiple instances.

// In Startup.cs or Program.cs
builder.Services.AddRateLimiter(options =>
{
    options.GlobalLimiter = PartitionedRateLimiter.Create<HttpContext, string>(_ =>
        RateLimitPartition.GetSlidingWindowLimiter(
            partitionKey: "auth_global",
            factory: _ => new SlidingWindowRateLimiterOptions
            {
                PermitLimit = 30,
                Window = TimeSpan.FromMinutes(1),
                SegmentsPerWindow = 4
            }));
});

// In the login endpoint
[HttpPost("login")]
public async Task<IActionResult> Login(LoginModel model)
{
    var allowed = await _limiter.TryAcquireAsync(HttpContext, cancellationToken: CancellationToken.None);
    if (!allowed.Results.Any(r => r.HasToken))
    {
        return StatusCode(429, "Too many attempts");
    }
    // Proceed with authentication
}

3. Use constant-time comparison and secure password storage

Avoid early exits that leak timing information. Use a constant-time compare for hashes when feasible and prefer a strong KDF such as bcrypt or Argon2.

// Example using BCrypt.Net-Next
string hash = BCrypt.Net.BCrypt.HashPassword(password, BCrypt.Net.BCrypt.GenerateSalt(workFactor: 12));
bool verified = BCrypt.Net.BCrypt.Verify(password, hash);
// Always run verification to avoid timing leaks; do not return early on user-not-found

4. Ensure CockroachDB client resilience and safe retries

Configure timeouts and retries to prevent abuse via slow connections. Use context timeouts to bound request duration.

var csb = new NpgsqlConnectionStringBuilder
{
    Host = "localhost",
    Username = "root",
    Password = "",
    Database = "appdb",
    SslMode = SslMode.Disable,
    CommandTimeout = 15,
    Pooling = true,
    MaximumPoolSize = 100
};
await using var conn = new NpgsqlConnection(csb.ConnectionString);
await conn.OpenAsync(cancellationToken);

5. Validate and normalize input

Normalize emails and reject malformed input before database interaction to reduce edge-case behavior.

var email = model.Email?.Trim().ToLowerInvariant();
if (!EmailRegex().IsMatch(email))
{
    return BadRequest("Invalid email");
}

6. Monitor and audit authentication patterns

Log failed attempts with usernames (if available) and source IPs without exposing sensitive data. Correlate logs to identify spray patterns. middleBrick can help by scanning your OpenAPI spec and runtime behavior to highlight missing rate limits and weak authentication controls.

7. Apply principle of least privilege for DB roles

Ensure the application database user has only the permissions needed (e.g., SELECT on users for authentication). Avoid using a highly privileged account for routine login queries.