Brute Force Attack in Spring Boot with Hmac Signatures

A brute force attack against an API that uses Hmac signatures in Spring Boot focuses on the signature verification step. When a server derives an expected Hmac using a shared secret and compares it to the Hmac provided by the client, the server must do this comparison in a way that does not leak information about the secret or about per-request validity through timing or error handling. If the comparison is vulnerable to timing attacks, an attacker can infer correctness byte-by-byte and eventually recover enough information to mount online or offline brute force attempts against the secret or the signed payload.

Spring Boot applications often sign requests by including a timestamp, a nonce, and a signature header. If the server does not enforce constant-time comparison and does not enforce strict replay protections (e.g., rejecting old timestamps or reusing nonces), an attacker can systematically submit modified payloads and observe differences in response behavior. For example, a server that returns distinct error messages for malformed signatures versus valid-but-rejected requests effectively enumerates validity without needing the secret. Additionally, if the server validates the Hmac only after processing business logic, an attacker can force expensive operations on the server, turning a signature verification weakness into a resource-exhaustion vector.

Consider an endpoint that accepts an api_key, a timestamp, and a signature derived with HmacSHA256. If the implementation uses a non-constant-time comparison like String.equals() on the raw signature strings, subtle timing differences can be measured. An attacker can iteratively guess characters of the effective signing material or observe how long validation takes to infer when a partial signature matches. This can be combined with request size or behavior analysis to mount a practical brute force or side-channel attack against the Hmac scheme.

Another scenario involves missing or weak input validation on the signed fields. If an attacker can control parts of the signed payload and observes whether the server accepts or rejects the request, they may perform online brute force by iterating over plausible values (e.g., incremental IDs or predictable resource identifiers) while monitoring acceptance rates. Without rate limiting or request throttling, repeated submissions can be attempted quickly, increasing the likelihood of successful brute force against weak secrets or predictable nonces.

Even when Hmac signatures are correctly implemented, the surrounding protocol design can reintroduce risk. For example, if timestamps are accepted with a very large skew window, an attacker has more opportunities to guess valid signatures. Similarly, if nonces are not enforced as single-use or are predictable, replay attacks effectively become a form of brute force against the session or transaction. Therefore, securing the combination of Spring Boot, Hmac signatures, and brute force resistance requires strict constant-time verification, tight replay windows, and robust rate limiting.

To mitigate brute force and side-channel risks, implement Hmac verification using constant-time comparison and strict protocol controls. Below are concrete, working Spring Boot examples that demonstrate secure signature generation and verification.

First, define a utility for constant-time comparison to avoid timing leaks:

import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
import java.nio.charset.StandardCharsets;
import java.security.InvalidKeyException;
import java.security.NoSuchAlgorithmException;
import java.util.Base64;

public class HmacUtil {

    private static final String HMAC_ALGORITHM = "HmacSHA256";

    public static String calculateHmac(String data, String secret) throws NoSuchAlgorithmException, InvalidKeyException {
        Mac mac = Mac.getInstance(HMAC_ALGORITHM);
        SecretKeySpec keySpec = new SecretKeySpec(secret.getBytes(StandardCharsets.UTF_8), HMAC_ALGORITHM);
        byte[] hmacBytes = mac.doFinal(data.getBytes(StandardCharsets.UTF_8));
        return Base64.getEncoder().encodeToString(hmacBytes);
    }

    public static boolean safeEquals(String a, String b) {
        if (a == null || b == null) {
            return false;
        }
        if (a.length() != b.length()) {
            return false;
        }
        int result = 0;
        for (int i = 0; i < a.length(); i++) {
            result |= a.charAt(i) ^ b.charAt(i);
        }
        return result == 0;
    }
}

Use this utility in a Spring Boot controller or filter to verify incoming Hmac signatures safely:

@RestController
@RequestMapping("/api")
public class OrderController {

    private static final String SECRET = System.getenv("HMAC_SECRET"); // store securely
    private static final long TIMESTAMP_TOLERANCE_SECONDS = 30;

    @PostMapping("/orders")
    public ResponseEntity<String> createOrder(
            @RequestHeader("X-API-Key") String apiKey,
            @RequestHeader("X-Timestamp") String timestampHeader,
            @RequestHeader("X-Signature") String receivedSignature,
            @RequestBody String payload) throws Exception {

        long timestamp = Long.parseLong(timestampHeader);
        long now = System.currentTimeMillis() / 1000;

        // Reject requests with excessive clock skew
        if (Math.abs(now - timestamp) > TIMESTAMP_TOLERANCE_SECONDS) {
            return ResponseEntity.status(400).body("Timestamp out of tolerance");
        }

        // Recompute signature over timestamp + payload to bind time and content
        String dataToSign = timestamp + payload;
        String expectedSignature = HmacUtil.calculateHmac(dataToSign, SECRET);

        // Use constant-time comparison to prevent timing attacks
        if (!HmacUtil.safeEquals(expectedSignature, receivedSignature)) {
            return ResponseEntity.status(401).body("Invalid signature");
        }

        // Additional business logic here
        return ResponseEntity.ok("Order created");
    }
}

For broader protection, implement a once-per-request nonce cache and enforce rate limits to blunt brute force attempts. Also ensure that error messages do not distinguish between bad signature and other failures, and that response times remain consistent regardless of input validity. These practices align with the checks included in middleBrick scans, which can surface timing and validation issues in your OpenAPI/Swagger specs and runtime behavior.