Dictionary Attack in Actix with Cockroachdb

A dictionary attack in an Actix-web service that uses CockroachDB typically arises from weak authentication endpoints and predictable user identifiers. When login or password-reset endpoints accept arbitrary usernames or email values without sufficient rate limiting or lockout, an attacker can systematically submit common credentials or leaked password lists against the service. Because CockroachDB is a distributed SQL database, connection pooling and latency characteristics may encourage developers to keep sessions or authentication state longer than intended, inadvertently aiding an attacker who can perform many attempts before detection.

In an Actix application, if route handlers directly interpolate user-supplied identifiers (e.g., /login/{username}) and perform SQL queries without strict input validation or query parameterization, the application may leak information through timing differences or error messages. CockroachDB’s SQL compatibility means that typical SQL injection or authentication bypass issues manifest not as direct injection, but as authentication logic flaws that facilitate dictionary attacks. For example, an endpoint that returns different HTTP status codes or response times for existing versus non-existing users enables username enumeration, which in turn supports focused dictionary attempts.

The 12 security checks in middleBrick highlight such risks by testing Authentication, BOLA/IDOR, and Input Validation concurrently. The scanner does not assume authentication; it probes unauthenticated endpoints to identify whether usernames can be enumerated and whether rate limiting is insufficient to deter rapid, automated guesses. With no agents or credentials required, middleBrick can surface a weak authentication surface in Actix services backed by CockroachDB within 5–15 seconds, providing severity-ranked findings and remediation guidance rather than attempting to fix the issues automatically.

Remediation centers on strict input validation, consistent response behavior, parameterized SQL queries, and robust rate limiting. The following examples show how to implement secure login handling in Actix with CockroachDB using the sqlx crate, ensuring that authentication logic does not expose enumerable usernames or succumb to dictionary attempts.

1. Use parameterized queries and avoid branching on username existence

Always use prepared statements with placeholders. Return the same generic response and HTTP status regardless of whether the username exists.

use actix_web::{post, web, HttpResponse};
use serde::{Deserialize, Serialize};
use sqlx::PgPool;

#[derive(Deserialize)]
struct LoginPayload {
    username: String,
    password: String,
}

#[derive(Serialize)]
struct LoginResponse {
    message: String,
}

#[post("/login")]
async fn login(
    pool: web::Data,
    body: web::Json,
) -> HttpResponse {
    let user: Result = sqlx::query(
        "SELECT id, password_hash FROM users WHERE username = $1",
    )
    .bind(&body.username)
    .fetch_optional(pool.get_ref())
    .await;

    match user {
        Ok(Some(_record)) => {
            // Perform constant-time password verification in application code
            // If invalid credentials, still return 200 with generic message
            HttpResponse::Ok().json(LoginResponse {
                message: "If the credentials are valid, you will be notified.".to_string(),
            })
        }
        Ok(None) => {
            // User does not exist — still return same generic response and status
            HttpResponse::Ok().json(LoginResponse {
                message: "If the credentials are valid, you will be notified.".to_string(),
            })
        }
        Err(_) => {
            // Do not expose DB errors; generic internal failure response
            HttpResponse::InternalServerError().json(LoginResponse {
                message: "Request failed. Please try again.".to_string(),
            })
        }
    }
}

2. Enforce rate limiting at the Actix-web layer

Apply per-username or per-IP rate limits to hinder automated dictionary attempts. This example uses a token-bucket approach with a Redis-backed store via actix-web-ratelimit.

use actix_web::middleware::Logger;
use actix_web::{App, HttpServer};
use actix_web_ratelimit::{RateLimit, RateLimitActor, MemoryStore};

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .wrap(Logger::default())
            .wrap(
                RateLimit::new(RateLimitActor::::new(10, 60)) // 10 requests per 60 seconds per identity
                    .identity(|req: &actix_web::HttpRequest| {
                        req.headers()
                            .get("X-Forwarded-For")
                            .and_then(|v| v.to_str().ok())
                            .map(ToString::to_string)
                            .unwrap_or_else(|| req.connection_info().realip_remote_addr().unwrap_or("unknown").to_string())
                    }),
            )
            .service(login)
    })
    .bind(("127.0.0.1", 8080))?
    .run()
    .await
}

3. Validate and normalize input before querying CockroachDB

Treat usernames as case-insensitive by storing and comparing normalized values. Reject inputs that do not match expected patterns to reduce noise in logs and authentication flows.

fn normalize_username(input: &str) -> String {
    input.trim().to_lowercase()
}

async fn validate_username(pool: &PgPool, raw: &str) -> bool {
    let username = normalize_username(raw);
    if !username.chars().all(|c| c.is_alphanumeric() || c == '_' || c == '.') {
        return false;
    }
    let count: (i64,) = sqlx::query_as("SELECT COUNT(*) FROM users WHERE username = $1")
        .bind(&username)
        .fetch_one(pool)
        .await
        .unwrap_or((0,));
    count.0 > 0
}

4. Secure password handling and account lockout policy

Store passwords using strong adaptive hashing (e.g., Argon2id). Implement account lockout or exponential backoff after repeated failures for a given normalized username, storing lockout state in CockroachDB with a TTL to avoid permanent denial-of-service.

// Example: record failed attempt with TTL
sqlx::query(
    "UPSERT INTO login_failures (username, attempts, expires_at) VALUES ($1, $2, NOW() + INTERVAL '15 minutes')",
)
.bind(&username)
.bind(attempts)
.execute(pool)
.await;

By combining these patterns — parameterized queries, consistent responses, strict input validation, and per-identity rate limiting — you reduce the effectiveness of dictionary attacks against an Actix service backed by CockroachDB. middleBrick’s scans can verify that these controls are present by checking Authentication, Input Validation, and Rate Limiting without requiring credentials or disrupting production traffic.