Side Channel Attack in Actix with Basic Auth

A side channel attack in Actix using Basic Auth exploits timing or behavioral differences in how authentication is handled, rather than breaking the cryptographic mechanism itself. Basic Auth encodes credentials in Base64 with no encryption; therefore, any observable difference in server response behavior—such as response time, error messages, or connection handling—can leak information about the validity of credentials.

In Actix, if an application performs credential validation in a non-constant-time manner, an attacker can measure response differences to infer whether a username exists or whether a password prefix is correct. For example, an implementation that returns 401 Unauthorized immediately for a missing Authorization header but performs a hash comparison for a present header introduces a timing discrepancy. An attacker can send many requests with malformed headers and observe latency to detect when the server proceeds to the password comparison stage. This becomes more practical when combined with other weaknesses such as missing rate limiting or logging that exposes request processing steps.

Another vector involves how Actix handles TLS termination and connection pooling. If a server reuses connections differently depending on authentication outcome, an attacker with the ability to observe network-level metrics (e.g., via shared hosting or co-located services) might infer authentication behavior. Although Actix does not inherently leak information, improper configuration—such as verbose logging of partial credentials, inconsistent error handling across authentication branches, or failure to use constant-time comparison for secrets—can create measurable side channels.

Consider an endpoint that parses the Authorization header and branches early when credentials are absent. The following unrealistic Actix-like pseudocode illustrates a vulnerable pattern:

async fn login_handler(req: HttpRequest) -> HttpResponse {
    let auth_header = req.headers().get("Authorization");
    if auth_header.is_none() {
        return HttpResponse::Unauthorized().body("Missing credentials");
    }
    let credentials = decode_basic_auth(auth_header.unwrap());
    // Non-constant-time comparison: early exit on username mismatch
    if !valid_user(&credentials.username) {
        return HttpResponse::Unauthorized().body("Invalid user");
    }
    if !verify_password(&credentials.username, &credentials.password) {
        return HttpResponse::Unauthorized().body("Invalid password");
    }
    HttpResponse::Ok().body("Authenticated")
}

An attacker observing timing can distinguish between a non-existent user (fast rejection) and a valid user with a wrong password (slower due to hash computation). This violates secure authentication design principles and can be discovered by a scanner such as middleBrick, which flags inconsistent error handling and missing constant-time protections as security findings.

To align with secure practices, applications should ensure that authentication paths execute similar steps regardless of input validity and avoid leaking information through timing, errors, or connection behavior. Middle-box protections like rate limiting and input validation help reduce the attack surface, but they do not replace the need for constant-time comparison and uniform error handling.

Remediation focuses on making authentication behavior deterministic and avoiding observable branching based on credential validity. The primary fixes are: (1) use constant-time comparison for secrets, (2) return uniform error responses and status codes, and (3) avoid logging or exposing partial authentication state.

In Actix-web, you can implement a constant-time comparison for the password verification step by using a cryptographic library that guarantees constant-time behavior. For Basic Auth, after decoding the credentials, treat the incoming password and the stored hash as opaque values during comparison. Below is a secure pattern that avoids early exits on user existence and uses constant-time verification:

use actix_web::{web, HttpResponse};
use data_encoding::BASE64;
use subtle::ConstantTimeEq;

async fn secure_login_handler(req: HttpRequest) -> HttpResponse {
    let auth_header = match req.headers().get("Authorization") {
        Some(h) => h,
        None => // Always return the same generic error and status
            return HttpResponse::Unauthorized()
                .header("WWW-Authenticate", "Basic realm=\"secure\"")
                .body("Authentication required"),
    };

    // Decode credentials; if malformed, respond generically
    let credentials = match decode_basic_auth(auth_header) {
        Ok(c) => c,
        Err(_) => return HttpResponse::Unauthorized()
            .header("WWW-Authenticate", "Basic realm=\"secure\"")
            .body("Invalid credentials"),
    };

    // Fetch stored hash in a way that does not leak user existence
    let stored_hash = match fetch_hashed_password(&credentials.username) {
        Some(h) => h,
        None => // Use a dummy hash to keep timing consistent
            stored_hash_for_dummy_user(),
    };

    // Constant-time password verification
    let verified = stored_hash.verify_constant_time(&credentials.password);
    if verified.is_ok() {
        HttpResponse::Ok().body("Authenticated")
    } else {
        HttpResponse::Unauthorized()
            .header("WWW-Authenticate", "Basic realm=\"secure\"")
            .body("Invalid credentials")
    }
}

fn decode_basic_auth(header: &HeaderValue) -> Result<Credentials, ()> {
    let decoded = BASE64.decode(header.as_bytes()).map_err(|_| ())?;
    let parts: Vec<str> = std::str::from_utf8(&decoded).map_err(|_| ())?.splitn(2, ':').collect();
    if parts.len() != 2 {
        return Err(());
    }
    Ok(Credentials {
        username: parts[0].to_string(),
        password: parts[1].to_string(),
    })
}

struct Credentials {
    username: String,
    password: String,
}

// Dummy hash for constant-time flow
fn stored_hash_for_dummy_user() -> PasswordHash {
    // Use a valid but non-matching hash to ensure timing consistency
    PasswordHash::new("$argon2id$v=19$m=65536,t=3,p=1$salt$expectedButWrongHash").unwrap()
}

Additional remediation steps include:

• Always set the WWW-Authenticate header on 401 responses to prevent information leakage about the authentication scheme.
• Log authentication attempts at an aggregated level without including raw credentials or partial secrets.
• Apply rate limiting at the Actix middleware level to mitigate brute-force attempts that could amplify side-channel observations.
• Ensure TLS is consistently used and that connection reuse does not depend on authentication outcome.

These changes reduce timing and behavioral variability, making it significantly harder for an attacker to infer credential validity through side channels. MiddleBrick scans can help identify inconsistent error handling and missing security headers that may otherwise facilitate such attacks.