Credential Stuffing in Axum with Cockroachdb

Credential stuffing is an automated brute-force technique that relies on lists of breached username and password pairs. When an Axum API backed by Cockroachdb lacks adequate rate control and does not enforce per-user login throttling, attackers can iterate through credentials at high volume with minimal detection risk.

In a typical Axum service using Cockroachdb, user credentials are stored in a table such as users with columns like id, email, and password_hash. If the login handler performs a simple lookup by email and then compares a hash without additional protections, an attacker can send thousands of requests per minute to the authentication endpoint. Because Cockroachdb is strongly consistent and distributed, it will reliably serve each authentication query, but it does not inherently prevent rapid, malicious requests. Without application-level rate limiting or adaptive challenges, the Axum endpoint effectively becomes an open proxy for credential testing.

The vulnerability is amplified when authentication endpoints do not differentiate between unknown users and incorrect passwords. Returning distinct responses for "user not found" versus "invalid password" allows attackers to enumerate valid accounts. Even if Axum uses secure password hashing (e.g., Argon2id), the absence of request-level throttling, captchas, or suspicious behavior detection enables high-throughput attempts. Because the scan tests authentication mechanisms as an unauthenticated attacker, such misconfigurations are observable as findings in the Authentication and BOLA/IDOR checks.

Credential stuffing in this stack also intersects with data exposure risks. If error messages from Cockroachdb or Axum leak stack traces or query details, attackers gain insight into schema and timing characteristics that aid automation. For example, a database constraint violation might surface detailed messages rather than a generic error, effectively turning the API into a side channel. The scanner’s Authentication and Data Exposure checks are designed to surface these distinctions without relying on authenticated access.

Remediation focuses on reducing the attack surface available to credential stuffing in Axum while preserving correctness with Cockroachdb. The following patterns assume an Axum handler receiving JSON such as { "email": "[email protected]", "password": "raw" }.

1. Constant-time authentication flow

Ensure the handler always performs the same steps regardless of whether the email exists. Fetch a user row by email; if absent, still run a slow hash to prevent timing discrimination.

use axum::{routing::post, Router};
use cockroach_client::Client;
use std::net::SocketAddr;
use argon2::{Argon2, PasswordHash, PasswordVerifier};

async fn login_handler(
    axum::Json(payload): axum::Json,
    db: &Client,
) -> Result<impl IntoResponse, (StatusCode, String)> {
    // Always fetch a row; if missing, use a dummy record to keep timing consistent
    let row = db
        .query_opt(
            "SELECT id, password_hash FROM users WHERE email = $1",
            &[&payload.email],
        )
        .await
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    let stored_hash = match row {
        Some(r) => r.get<String>("password_hash"),
        None => // Dummy hash for constant-time behavior
            "$argon2id$v=19$m=65536,t=3,p=4$c29tZXNhbHQ$RdescudvJCsgt3ub+b+dWRWJTmaaJObG".to_string(),
    };

    if let Err(e) = Argon2::default().verify_password(payload.password.as_bytes(), &PasswordHash::new(&stored_hash).map_err(|_| (StatusCode::UNAUTHORIZED, "auth error"))?) {
        return Err((StatusCode::UNAUTHORIZED, "Invalid credentials".to_string()));
    }

    // Proceed with session creation
    Ok((StatusCode::OK, "Authenticated"))
}

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

#[tokio::main]
async fn main() {
    let db = cockroach_client::Client::new("postgresql://user:pass@host:26257/db?sslmode=require").unwrap();
    let app = Router::new().route("/login", post(login_handler));
    let listener = tokio::net::TcpListener::bind("0.0.0.0:3000").await.unwrap();
    axum::serve(listener, app).await.unwrap();
}

2. Schema and queries for Cockroachdb

Define a users table with a unique constraint on email and store Argon2id hashes. Use parameterized queries to avoid injection and ensure that constraints are enforced deterministically across nodes.

-- Cockroachdb DDL for users table
CREATE TABLE users (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    email STRING UNIQUE NOT NULL,
    password_hash STRING NOT NULL,
    created_at TIMESTAMPTZ DEFAULT now()
);

-- Example parameterized query in Axum (via cockroach-rs or similar driver)
async fn get_user_by_email(db: &Client, email: &str) -/> Result<Option<User>, sqlx::Error> {
    let user = sqlx::query!(
        "SELECT id, email, password_hash FROM users WHERE email = $1",
        email
    )
    .fetch_optional(db)
    .await?;
    Ok(user.map(|r| User {
        id: r.id,
        email: r.email,
        password_hash: r.password_hash,
    }))
}

3. Rate limiting and anomaly detection

Apply request-level throttling at the Axum layer to limit attempts per source IP or per user identifier. Combine with Cockroachdb-side instrumentation to detect bursts that indicate automated attacks.

use axum_extra::extract::RateLimit;

let app = Router::new()
    .route("/login", post(login_handler))
    .layer(RateLimit::new(|_req: &Request| async { 5, std::time::Duration::from_secs(60) }));

4. Secure error handling

Avoid leaking Cockroachdb-specific messages. Return generic errors and log detailed issues server-side for investigation without exposing them to the client.

// Bad: exposes DB constraint details
// Good: generic message with structured logging
let result = db.query(...).await;
if let Err(e) = result {
    tracing::error!(error = %e, "login query failed");
    return Err((StatusCode::INTERNAL_SERVER_ERROR, "Unable to process request".to_string()));
}

5. Compliance-aware logging

Ensure that authentication events are recorded with sufficient context for audits, but avoid storing raw passwords or sensitive PII in logs. Map findings to OWASP API Top 10 A07:2021 and relevant regulatory controls.