Dictionary Attack in Actix with Hmac Signatures

A dictionary attack against an Actix service that uses Hmac Signatures typically targets the portion of the application that derives or validates the signature using a shared secret. In this setup, clients compute an Hmac (for example, HmacSHA256) over a canonical string that often includes a timestamp and a nonce, and send the signature in a header. If the server does not enforce strict replay and rate controls on the signature-verification path, an attacker can automate requests with slightly altered inputs (e.g., incremental timestamps or nonces) and observe whether responses differ in ways that leak information about signature validity.

In Actix, a common pattern is to compute the signature on the client and verify it on the server using a shared secret. If the server endpoint does not uniformly handle invalid, missing, or malformed signatures—and instead returns distinct errors or data exposure based on signature correctness—an attacker can use these differences to perform a dictionary attack. They may submit many candidate secrets or replay intercepted requests with modified parameters to guess the key or to learn which usernames or IDs are valid. The risk is compounded when the timestamp window is generous or nonces are not strictly single-use, because captured requests can be replayed within the allowed time frame. Without proper input validation and rate limiting, the unauthenticated attack surface includes the signature verification logic, which can be probed at scale.

Consider an endpoint that accepts X-API-Timestamp, X-API-Nonce, and X-API-Signature. If the server computes its own Hmac over the received timestamp and nonce using the candidate secret and compares it to the client-supplied signature, differences in server-side behavior (timing differences, distinct error codes, or varying response content) can be measurable. A dictionary attack in this context does not require breaking the Hmac algorithm; it exploits implementation gaps around signature validation, replay handling, and response uniformity. The attack surface includes endpoints that accept these headers and do not enforce strict, constant-time verification and anti-replay mechanisms.

Remediation focuses on making signature validation resilient to probing: enforce a strict timestamp window, use constant-time comparison, enforce single-use nonces where feasible, and apply rate limiting to the verification path. Below are concrete Actix-web patterns that address these concerns.

Example 1: Secure signature verification with timestamp and constant-time comparison

use actix_web::{web, HttpResponse, Result};
use hmac::{Hmac, Mac};
use sha2::Sha256;
use std::time::{SystemTime, UNIX_EPOCH};

// Shared secret should be stored securely (e.g., from environment/secrets)
static SECRET: &[u8] = b"super-secret-key-32-bytes-long-12345678";

type HmacSha256 = Hmac;

/// Verify that the timestamp is within an acceptable window (e.g., 5 minutes).
fn is_timestamp_valid(ts: u64) -> bool {
    let now = SystemTime::now()
        .duration_since(UNIX_EPOCH)
        .map(|d| d.as_secs())
        .unwrap_or(0);
    const ALLOWED_DRIFT_SEC: u64 = 300;
    ts + ALLOWED_DRIFT_SEC >= now && ts <= now + ALLOWED_DRIFT_SEC
}

/// Constant-time comparison to avoid timing leaks.
fn verify_signature(secret: &[u8], data: &str, received_sig: &str) -> bool {
    let mut mac = HmacSha256::new_from_slice(secret).expect("HMAC can take key of any size");
    mac.update(data.as_bytes());
    let computed = mac.finalize().into_bytes();
    // Use constant-time comparison (subtle::ConstantTimeEq via hex/encoding crates in real use).
    // For illustration, we compare lengths and use ==; in production, use a constant-time compare.
    let received = hex::decode(received_sig).unwrap_or_default();
    subtle::ConstantTimeEq::ct_eq(&computed[..], received.as_slice()).into()
}

async fn protected_route(
    timestamp: web::Query>,
    headers: actix_web::http::HeaderMap,
) -> Result {
    let ts_str = match timestamp.get("ts") {
        Some(t) => t,
        None => return Ok(HttpResponse::BadRequest().body("missing ts")),
    };
    let ts: u64 = match ts_str.parse() {
        Ok(v) => v,
        Err(_) => return Ok(HttpResponse::BadRequest().body("invalid ts")), // Avoid leaking why
    };
    if !is_timestamp_valid(ts) {
        return Ok(HttpResponse::Unauthorized().body("invalid timestamp"));
    }

    let nonce = match headers.get("X-API-Nonce") {
        Some(v) => v.to_str().unwrap_or(""),
        None => return Ok(HttpResponse::Unauthorized().body("missing nonce")),
    };
    let signature = match headers.get("X-API-Signature") {
        Some(v) => v.to_str().unwrap_or(""),
        None => return Ok(HttpResponse::Unauthorized().body("missing signature")),
    };

    // Build canonical string exactly as the client does (e.g., "ts=12345&nonce=abc").
    let canonical = format!("ts={}&nonce={}", ts, nonce);
    if !verify_signature(SECRET, &canonical, signature) {
        return Ok(HttpResponse::Unauthorized().body("invalid signature"));
    }

    // At this point, signature and timestamp are valid. Proceed with business logic.
    Ok(HttpResponse::Ok().body("access granted"))
}

Example 2: Enforce replay protection using a nonce cache and rate limiting

use actix_web::{dev::ServiceRequest, Error};
use std::collections::HashSet;
use std::sync::{Arc, Mutex};

// Simple in-memory nonce cache; in production use a fast, TTL-backed store.
struct NonceCache(Arc>>);

impl NonceCache {
    fn new() -> Self {
        NonceCache(Arc::new(Mutex::new(HashSet::new())))
    }

    fn mark_used(&self, nonce: String) -> bool {
        let mut set = self.0.lock().unwrap();
        if set.contains(&nonce) {
            false
        } else {
            set.insert(nonce);
            true
        }
    }
}

/// Middleware-like check to reject reused nonces and apply rate limits per key.
async fn validate_request(
    req: &ServiceRequest,
    nonce_cache: &NonceCache,
) -> Result<(), Error> {
    let headers = req.headers();
    let nonce = match headers.get("X-API-Nonce") {
        Some(v) => v.to_str().unwrap_or("").to_string(),
        None => return Err(actix_web::error::ErrorUnauthorized("missing nonce")),
    };
    if !nonce_cache.mark_used(nonce) {
        return Err(actix_web::error::ErrorUnauthorized("reused nonce"));
    }
    // Apply rate limiting on a per-client identifier extracted from the request,
    // e.g., an API key in a header, to limit guesses in dictionary attacks.
    // This is a placeholder for your rate-limiting logic (token bucket / sliding window).
    Ok(())
}

Additional operational practices reduce dictionary attack risk: rotate shared secrets periodically, store secrets outside source code, and ensure verification logic does not branch on signature correctness in a way that produces distinguishable responses. Combine these code-level changes with infrastructure-level protections such as connection throttling and anomaly detection to make dictionary probing ineffective.