Dictionary Attack in Actix with Basic Auth

A dictionary attack against an Actix web service that uses HTTP Basic Authentication relies on two conditions: the endpoint being publicly reachable and the absence of effective rate limiting or account lockout. In this scenario, an attacker submits a large list of username and password pairs against the Actix endpoint, measuring response times and status codes to infer valid credentials. Because Basic Auth transmits credentials in an encoded (not encrypted) format unless protected by TLS, passive network observers can also capture the authorization header if TLS is misconfigured or downgraded.

Actix web applications often expose authentication routes that do not enforce per-user rate limits, allowing rapid, sequential guesses. If the application returns different HTTP status codes or response bodies for existing versus non-existing users, the attacker gains valuable feedback that accelerates the dictionary search. The absence of multi-factor authentication or adaptive throttling further amplifies risk. Even with TLS, weak passwords are vulnerable to offline cracking once the hash or encoded token is intercepted.

The 12 security checks in middleBrick run in parallel and include Authentication testing, which probes for weak credential enforcement and excessive submission attempts. During a scan, middleBrick submits a curated list of credentials against the Actix Basic Auth endpoint without authentication, observing response behavior to detect indicators of dictionary attack susceptibility. Findings include whether the service reveals user existence via timing or message differences, whether rate limiting applies at the user or IP level, and whether credentials are protected in transit. middleBrick maps these observations to the OWASP API Top 10 and relevant compliance frameworks, providing prioritized findings with severity ratings and remediation guidance.

In an unauthenticated black-box scan, middleBrick can identify whether an Actix Basic Auth implementation leaks information through timing variances or inconsistent error messages. This helps security teams understand whether a dictionary attack could be practically executed and which controls—such as uniform response times, account lockout, or CAPTCHA—should be introduced to reduce the attack surface.

Remediation focuses on reducing information leakage, enforcing rate limits, and ensuring credentials are always transmitted over TLS. Below are concrete Actix examples that implement constant-time comparison, uniform responses, and request-rate throttling to mitigate dictionary attack risks.

use actix_web::{web, App, HttpResponse, HttpServer, Responder, middleware::Logger};
use actix_web::http::header::HeaderValue;
use std::collections::HashMap;
use std::time::Duration;
use actix_web::middleware::errhandlers::ErrorHandlers;
use actix_web::error::ErrorUnauthorized;
use std::sync::{Arc, Mutex};

// In-memory attempt tracking (for demonstration; use Redis in production)
struct LoginState {
    attempts: Mutex>>,
    max_attempts: u32,
    block_duration_secs: u64,
}

async fn basic_auth_handler(
    credentials: actix_web::web::Header<actix_web::http::Authorization<actix_web::http::headers::authorization::Basic>>,
    login_state: web::Data<Arc<LoginState>>,
) -> impl Responder {
    let creds = credentials.into_inner();
    let user = creds.user_id();
    let pass = creds.password();

    // Constant-time check stub: in real code, use a constant-time comparison
    let is_valid = validate_user_constant_time(user, pass);

    // Record attempt
    let mut attempts = login_state.attempts.lock().unwrap();
    let now = std::time::Instant::now();
    attempts.entry(user.to_string()).or_default().push(now);

    let user_attempts = attempts.get(user).unwrap();
    let recent: Vec<_> = user_attempts
        .iter()
        .filter(|&t| now.duration_since(*t) < Duration::from_secs(300))
        .copied()
        .collect();

    if recent.len() > login_state.max_attempts as usize {
        return HttpResponse::TooManyRequests()
            .insert_header(("Retry-After", login_state.block_duration_secs.to_string()))
            .finish();
    }

    if !is_valid {
        // Uniform response to avoid user enumeration
        return HttpResponse::Unauthorized()
            .insert_header(("WWW-Authenticate", "Basic realm=\"secure\""))
            .finish();
    }

    HttpResponse::Ok().body("Authenticated")
}

fn validate_user_constant_time(user: &str, pass: &str) -> bool {
    // Replace with secure password verification (e.g., argon2, bcrypt)
    // Use constant-time comparison for secrets to avoid timing leaks
    let stored = get_stored_hash(user);
    // Dummy comparison: in production, use a crate like subtle::ConstantTimeEq
    stored == pass
}

fn get_stored_hash(_user: &str) -> String {
    // Retrieve hash from secure storage
    "expected_hash".to_string()
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let login_state = Arc::new(LoginState {
        attempts: Mutex::new(HashMap::new()),
        max_attempts: 5,
        block_duration_secs: 300,
    });

    HttpServer::new(move || {
        let state = login_state.clone();
        App::new()
            .wrap(Logger::default())
            .wrap(
                ErrorHandlers::new()
                    .handler(actix_web::http::StatusCode::UNAUTHORIZED, |err| async move {
                        HttpResponse::Unauthorized()
                            .insert_header(("WWW-Authenticate", "Basic realm=\"secure\""))
                            .body("Authentication failed")
                    }),
            )
            .app_data(web::Data::new(state))
            .route("/protected", web::get().to(basic_auth_handler))
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}

This example demonstrates how to enforce per-user attempt tracking, return uniform error messages to prevent user enumeration, and apply throttling to raise the cost of a dictionary attack. For production, store password hashes using a dedicated algorithm (e.g., Argon2id) and use a shared cache for attempt tracking across instances. middleBrick’s Authentication check can verify that such controls are present by observing whether the service enforces rate limits and whether responses leak user information.