Password Spraying in Actix with Jwt Tokens

Password spraying is an authentication attack where a single common password is tried against many accounts. When an Actix web service uses JWT tokens for session management, spraying can still occur at the login endpoint before a token is issued. If the endpoint does not enforce per-account rate limiting or progressive delays, an attacker can iterate through a list of common passwords across a list of known usernames without triggering account lockout. Because JWTs are typically issued after successful credential validation, the absence of robust throttling allows an attacker to harvest valid usernames and eventually obtain a legitimate token through iterative guesses.

In an Actix-based API, this risk is pronounced when authentication routes are public and JWT issuance relies only on static validation of credentials. Attackers can automate requests with minimal concurrency to avoid obvious traffic spikes, especially when the application lacks instrumentation for abnormal login patterns. Even if JWTs carry short lifetimes and are rotated on refresh, the initial authentication path remains a target. The absence of adaptive challenges or suspicious-behavior detection means that credential spraying can continue until a weak password is found, leading to account compromise and token misuse.

Another contributing factor is the exposure of username enumeration through timing differences or response messages. If an Actix handler reveals whether a username exists based on response time or content, attackers can refine their password lists per username. Combined with JWTs that embed identity claims, leaked tokens from other sources can be replayed if the signing keys or token handling are misconfigured. Therefore, the combination of password spraying-prone endpoints and JWT-based authentication in Actix expands the attack surface by enabling token generation from compromised accounts.

To mitigate password spraying in an Actix service that issues JWT tokens, implement per-account rate limiting, progressive delays, and strict input validation. Use middleware to track failed attempts by username and source IP, introducing increasing backoff before allowing further attempts. Ensure that authentication responses do not disclose username existence, and issue tokens only after all checks pass. Below are concrete code examples for an Actix web application that demonstrate secure JWT handling alongside anti-spraying measures.

First, define your claims and token utilities with strong algorithms and short expirations:

use jsonwebtoken::{encode, Algorithm, EncodingKey, Header, Validation, decode, DecodingKey, TokenData};
use serde::{Serialize, Deserialize};

#[derive(Debug, Serialize, Deserialize)]
struct Claims {
    sub: String,
    email: String,
    exp: usize,
}

fn create_token(claims: &Claims) -> String {
    encode(
        &Header::new(Algorithm::HS256),
        claims,
        &EncodingKey::from_secret("your_strong_secret_key".as_ref()),
    ).expect("failed to create token")
}

fn validate_token(token: &str) -> TokenData {
    decode::(
        token,
        &DecodingKey::from_secret("your_strong_secret_key".as_ref()),
        &Validation::new(Algorithm::HS256),
    ).expect("failed to validate token")
}

Second, add authentication route logic with rate limiting and constant-time comparison to avoid enumeration:

use actix_web::{post, web, HttpResponse, Result};
use std::collections::HashMap;
use std::sync::{Arc, Mutex};
use std::time::{SystemTime, UNIX_EPOCH};

struct AuthState {
    failed_attempts: Mutex>>,
    // key: username, value: list of timestamps (seconds)
}

async fn check_rate_limit(state: web::Data>, username: &str) -> bool {
    let now = SystemTime::now().duration_since(UNIX_EPOCH).unwrap().as_secs();
    let mut attempts = state.failed_attempts.lock().unwrap();
    let timestamps = attempts.entry(username.to_string()).or_default();
    // keep only last 5 minutes
    timestamps.retain(|&t| now - t < 300);
    if timestamps.len() >= 10 {
        return false;
    }
    timestamps.push(now);
    true
}

async fn verify_credentials(username: &str, password: &str) -> bool {
    // Use a constant-time comparison for password verification in real code
    // Placeholder: integrate your user store and password hashing
    false
}

#[post("/login")]
async fn login(
    body: web::Json,
    data: web::Data>,
) -> Result {
    let username = &body.username;
    let password = &body.password;

    if !check_rate_limit(data.clone(), username).await {
        return Ok(HttpResponse::too_many_requests().json("rate limit exceeded"));
    }

    if verify_credentials(username, password).await {
        let claims = Claims {
            sub: username.clone(),
            email: format!("{}@example.com", username),
            exp: (SystemTime::now().duration_since(UNIX_EPOCH).unwrap().as_secs() + 3600) as usize,
        };
        let token = create_token(&claims);
        Ok(HttpResponse::Ok().json(serde_json::json!({ "token": token })))
    } else {
        // Do not reveal whether username exists
        Ok(HttpResponse::unauthorized().json(serde_json::json!({ "error": "invalid credentials" })))
    }
}

Finally, enforce global throttling and monitoring in your Actix server setup to complement per-route defenses:

use actix_web::{App, HttpServer, middleware::Logger};

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let auth_state = Arc::new(AuthState {
        failed_attempts: Mutex::new(HashMap::new()),
    });

    HttpServer::new(move || {
        App::new()
            .app_data(web::Data::new(auth_state.clone()))
            .wrap(Logger::default())
            .service(login)
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}

These examples show how to combine JWT issuance with concrete protections against password spraying in Actix. By limiting attempts, standardizing responses, and shortening token lifetimes, you reduce the effectiveness of spraying while maintaining secure authentication flows.