Client-server interactions are prone to cyberattacks that can compromise the data exchanged. Let's understand two common attacks that can occur:

Man-in-the-Middle (MITM) Attack: The attacker secretly intercepts and potentially alters the communication between two parties who believe they are directly communicating. The attacker positions themselves between the two parties (for instance, an API consumer and a web server) and can eavesdrop on, modify, or even inject malicious content into the exchanged data.
Replay Attack: The attacker intercepts valid data transmissions (for instance, login credentials or authentication tokens) and maliciously retransmits them (or "replays" them) to trick the system into granting unauthorized access or executing a fraudulent transaction. The key aspect of a replay attack is that the attacker does not need to decrypt or alter the data—they simply capture and resend it.

How Nonces Help Prevent Replay Attacks

A nonce—short for 'number used once'—is a unique, one-time-use value the client generates for each request. It thwarts replay attacks by ensuring each message is unique, even if the same request is made multiple times.

When a client sends a request to a server, it includes the nonce in the request. The server checks the nonce's uniqueness against its temporary store of nonces; if it finds the nonce is new, it processes the request. Otherwise, it rejects the request, preventing the replay attack.

When we combine a nonce with a form of sequence number or timestamp, for example, our implementation asks for it to increase with each request, a message is not only unique but also time-sensitive.

How HMAC Helps Prevent MITM Attacks

Hash-based Authentication Codes (HMAC)—a cryptographic mechanism—helps prevent MITM attacks by ensuring the authenticity and integrity of the message being transmitted between two parties.

HMAC uses a shared secret key known only to the sender and the receiver. When sending a message, the sender computes the HMAC using the message and the secret key and transmits both the message and the HMAC.

The receiver, who also knows the secret key, recomputes the HMAC using the received message and compares it to the HMAC sent by the sender. If they match, it proves the message came from a legitimate sender (authentication) and was not tampered with (integrity). A discrepancy immediately exposes a tampering attempt and alerts the receiver to reject the message.

An attacker in the middle cannot forge a valid HMAC without knowing the secret key, preventing them from impersonating the sender. They only see the message and the resulting HMAC. Without the secret key, the attacker cannot reverse-engineer the HMAC to alter the message or generate new valid HMACs for fraudulent messages.

How HMAC and Nonces Work Together

HMAC alone does not protect against replay attacks. However, combined with a nonce, it becomes a highly effective way to prevent MITM and replay attacks. Merging both schemes ensures that each message is authentic, untampered, and unique. It works in the following way:

HMAC for Message Integrity and Authentication: Only the sender and receiver can compute the correct HMAC because they share the secret key, which ensures the authenticity of the sender and the message's integrity during transmission. However, an attacker could still capture a legitimate message and resend it with the same HMAC.
Nonce for Uniqueness and Freshness: The addition of a nonce to each request makes them unique. If a message is captured and replayed, it won't be accepted because the server detects the nonce reuse, preventing replay attacks.

Step-by-Step Process:

Client Sends Request with Nonce:
1. The client generates a nonce.
2. The client appends the nonce to the message.
3. The client computes the HMAC using the message, nonce, and a shared secret key.
4. The message, nonce, and HMAC are sent to the server.
Server Validates the Request:
1. Upon receiving the message, the server verifies whether the nonce has been used before.
2. If the nonce is new and valid, the server accepts the request.
3. Otherwise, the server rejects it as a replay attempt.
4. The server recomputes the HMAC using the received message, nonce, and shared secret key.
5. If the HMACs match, the server confirms the authenticity and integrity of the message.
6. If they don't match, the server rejects the message as an MITM attack.

How HMAC Drawbacks are Subdued

Despite HMAC's strengths in securing message integrity and authentication, it has limitations and potential drawbacks, which we can summarize as follows:

Key management: HMAC requires a shared secret key between the sender and receiver, posing challenges in securing key distribution and management.
No confidentiality: HMAC only ensures integrity and authentication, not encryption. The message itself is not encrypted, meaning an attacker could still read the content even if they can't modify it. HMAC must be combined with encryption algorithms if confidentiality is required.
Vulnerability to brute force and key exposure: If a weak key is chosen, for example, a short or easily guessable key, the HMAC can be vulnerable to brute force attacks where an attacker tries different keys until they find the correct one. It is also susceptible to key exposure. If the secret key is leaked or compromised in any way, HMAC becomes entirely insecure because an attacker with the key can forge valid HMACs.
Hash function dependence: Security risks exist when the implementation uses weak or compromised hash functions. HMAC is only as strong as the underlying hash function. If the hash function is compromised, then the HMAC can be vulnerable to collision attacks.
Performance overhead: Computational and performance costs can be a consideration in high-throughput or resource-limited environments. While HMAC is computationally efficient, it still adds overhead due to the hashing process. HMAC internally hashes the message twice—once with an inner key and once with an outer key. This double hashing makes it more secure but also more resource-intensive compared to single-hash algorithms.
Lack of native replay attack protection: HMAC alone does not prevent replay attacks. Mitigating these attacks requires additional mechanisms to prevent message resending.

However, when we combine HMAC with proper practices such as secure key management, the addition of nonces, robust hash functions, and long enough strong keys, HMAC remains a robust, trustable method for message integrity and authentication.

Summary

HMAC prevents MITM attacks by providing authentication (ensuring the message comes from a legitimate sender) and integrity (detecting any changes to the message). It makes it impossible for an attacker to forge or modify messages without knowing the secret key. When combined with nonces the uniqueness of each message can be guaranteed, preventing the replay of previous valid messages. Together, they provide a robust defense against attackers trying to intercept or replay valid messages.