Message replay protection is a critical security feature, especially for mobile apps handling sensitive operations like financial transactions. It ensures that each message exchanged between the client (your app) and the server is unique and valid, preventing attackers from reusing intercepted messages to perform malicious actions.

If you’re building or maintaining an Android app, this is one security measure you don’t want to overlook. Let’s dive into what message replay protection is, why it’s essential, and how you can implement it effectively in your Android application using Kotlin.

What Is Message Replay Protection?

These days, most of us rely on wallet apps or banking apps for payments. In fact, many people in india— including me — barely carry any cash anymore! 😊 But here’s the thing: as we use these financial apps for transactions, we often overlook a potential risk. Imagine this: a malicious actor (like a hacker) intercepts a network request from your app that authorizes a fund transfer. If your app doesn’t have replay protection, the hacker could simply resend that same intercepted request and execute the transfer again — without you even knowing. You wouldn’t realize it until you notice how much money is gone. Scary, right?

Message replay protection prevents attackers from reusing old or intercepted messages to perform unauthorized actions. It works by using things like timestamps, random numbers (nonces), or sequence numbers to make each message unique. With replay protection in place, the server can spot the repeated message and reject it, keeping the communication secure.

Why Is It Important?

In the world of Android apps—particularly finance, e-commerce, or any domain dealing with sensitive data—security breaches can result in financial loss, legal troubles, and damaged user trust.
Implementing message replay protection:

• Safeguards transactions and sensitive operations.
• Ensures compliance with industry standards like PCI DSS (Payment Card Industry Data Security Standard).
• Bolsters your app’s reputation for security and reliability.

How Message Replay Protection Works

Message replay protection ensures that every message sent during communication is unique and cannot be reused by an attacker. Here’s how it typically works:

1. Nonces (Numbers Used Once): Unique identifiers, such as timestamps or random numbers, are attached to messages.
2. Server Validation: The server checks whether the nonce has been used before.
3. Rejection of Duplicates: If the same nonce is detected, the server rejects the message, thwarting the replay attempt.

Message Replay Protection Implementation

The core idea behind replay protection is to use unique identifiers and timestamps for every request. Here’s the typical flow:

1. Generate a unique nonce (number used once) for each message.
2. Include the nonce and a timestamp in the request payload.
3. Use a cryptographic hash to sign the request, ensuring the data isn’t tampered with.
4. On the server side:

• Validate the nonce to ensure it hasn’t been used before.
• Check the timestamp to confirm the message isn’t too old.
• Verify the cryptographic signature.

If any of these validations fail, the server rejects the request.

Without further delay, let’s implement message replay protection, step by step.

Using a Unique Request Identifier (Nonce)

A nonce (number used once) ensures every request is unique. The server validates this identifier to prevent duplicate processing.

import java.util.UUID

fun generateNonce(): String {
    return UUID.randomUUID().toString()
}

• UUID.randomUUID() generates a universally unique identifier.
• This identifier will accompany each request to the server.

Adding a Timestamp

A timestamp ensures requests are processed within a valid timeframe. The server compares the timestamp in the request to the current time.

fun generateTimestamp(): Long {
    return System.currentTimeMillis()
}

System.currentTimeMillis() gives the current system time in milliseconds. This timestamp is included in the request to verify freshness.

Creating a Secure Request

We’ll combine the nonce and timestamp to form a secure request payload.

data class SecureRequest(
    val data: String, // The actual request data
    val nonce: String,
    val timestamp: Long
)

fun createSecureRequest(data: String): SecureRequest {
    return SecureRequest(
        data = data,
        nonce = generateNonce(),
        timestamp = generateTimestamp()
    )
}

Here,

• SecureRequest is a data class containing:
  • data: The actual API payload.
  • nonce: Ensures uniqueness.
  • timestamp: Ensures the request is recent.

Validating Requests on the Server

On the server, we validate the nonce and timestamp.

Server-side Validation Steps

Nonce Validation

• Maintain a record of used nonces.
• Reject requests with duplicate nonces.

Timestamp Validation

• Calculate the time difference between the server time and the request timestamp.
• Reject requests older than a predefined threshold (e.g., 5 or 10 minutes).

fun isRequestValid(request: SecureRequest, usedNonces: MutableSet<String>, timeThreshold: Long = 5 * 60 * 1000): Boolean {
    // Check if nonce is already used
    if (usedNonces.contains(request.nonce)) {
        return false
    }

    // Check if timestamp is within the allowed range
    val currentTime = System.currentTimeMillis()
    if ((currentTime - request.timestamp) > timeThreshold) {
        return false
    }

    // Add nonce to used list after successful validation
    usedNonces.add(request.nonce)
    return true
}

Here,

• usedNonces: A set that keeps track of nonces already used.
• timeThreshold: Maximum allowed time difference (e.g., 5 minutes).
• If the nonce is already used or the timestamp is invalid, the request is rejected.

Secure Communication with HMAC

To further enhance security, sign the request using HMAC (Hash-based Message Authentication Code). This ensures that the request data cannot be tampered with.

import javax.crypto.Mac
import javax.crypto.spec.SecretKeySpec
import android.util.Base64

fun generateHmac(data: String, secretKey: String): String {
    val keySpec = SecretKeySpec(secretKey.toByteArray(), "HmacSHA256")
    val mac = Mac.getInstance("HmacSHA256")
    mac.init(keySpec)
    val hmacBytes = mac.doFinal(data.toByteArray())
    return Base64.encodeToString(hmacBytes, Base64.NO_WRAP)
}

• HmacSHA256: A hashing algorithm that ensures message integrity.
• SecretKeySpec: A key used to sign the
• request.Base64: Encodes the result for safe transmission.

Implementing Message Replay Protection in Android

Now, here’s how you can bring this concept to life in an Android app.

Client-Side Implementation

import java.security.MessageDigest  
import java.util.Base64  
import java.util.UUID  

fun createRequestPayload(data: String, secretKey: String): Map<String, String> {  
    val nonce = UUID.randomUUID().toString()  // Generate a unique nonce  
    val timestamp = System.currentTimeMillis()  // Current timestamp  
    val payload = "$data|$nonce|$timestamp"  

    // Create a cryptographic hash of the payload  
    val signature = hashWithHmacSHA256(payload, secretKey)  

    return mapOf(  
        "data" to data,  
        "nonce" to nonce,  
        "timestamp" to timestamp.toString(),  
        "signature" to signature  
    )  
}  

fun hashWithHmacSHA256(data: String, secretKey: String): String {  
    val hmacSHA256 = MessageDigest.getInstance("HmacSHA256")  
    val keyBytes = secretKey.toByteArray(Charsets.UTF_8)  
    val dataBytes = data.toByteArray(Charsets.UTF_8)  
    val hmacBytes = hmacSHA256.digest(keyBytes + dataBytes)  
    return Base64.getEncoder().encodeToString(hmacBytes)  
}  

Server-Side Validation

On the server, you would:

1. Check that the nonce is unused. Store and track used nonces.
2. Verify the timestamp is within an acceptable window (e.g., 5 minutes).
3. Recompute the signature using the shared secret key and compare it with the one provided.

Integrating with Retrofit

To send the payload securely.

val requestBody = createRequestPayload("Transfer $100", "YourSecretKey")  

retrofitService.sendRequest(requestBody).enqueue(object : Callback<Response> {  
    override fun onResponse(call: Call<Response>, response: Response<Response>) {  
        if (response.isSuccessful) {  
            println("Request succeeded!")  
        } else {  
            println("Validation failed: ${response.errorBody()?.string()}")  
        }  
    }  

    override fun onFailure(call: Call<Response>, t: Throwable) {  
        println("Network error: ${t.message}")  
    }  
})  

Testing and Best Practices

Simulate Attacks

• Replay the same request multiple times and ensure the server rejects duplicates.

Use Secure Channels

• Always use HTTPS to prevent eavesdropping.

Keep Secrets Safe

• Store API keys and secret keys securely (e.g., Android’s Keystore).

Log Suspicious Activity

• Maintain logs for failed attempts to analyze potential attack patterns.

Conclusion

Securing your app isn’t just about writing good code—it’s about understanding and anticipating threats. Message replay attacks are a real danger, but with strategies like unique nonces, timestamps, and cryptographic validation, you can stay one step ahead.

By following the steps above, you’re not just protecting your users—you’re building trust and setting a standard for security in your apps.

Stay vigilant, keep learning, and code securely..!