Why You Should Avoid Sequential Transaction IDs in Payment App

As an increasing number of businesses shift to digital platforms, online payment software has become a critical component of many organisations. Payment software must be reliable, secure, and efficient, ensuring that transactions are processed accurately and efficiently. One key aspect of payment software is the transaction ID, which is used to uniquely identify each transaction.

While it may seem logical to use sequential transaction IDs, this approach can pose a significant security risk. Sequential IDs can be easily guessed or predicted by an attacker, which can lead to fraudulent transactions or other security breaches.

If an attacker is able to determine a valid transaction ID, they can potentially modify or create fraudulent transactions, causing significant financial losses.

Example

Attackers can modify transactions by using a technique called "transaction replay attack". In this type of attack, the attacker intercepts a legitimate transaction, records it, and then replays the same transaction multiple times with small modifications to the transaction data.

For example, let's say that a legitimate transaction has a sequential transaction ID of "1234". An attacker intercepts this transaction and replays it multiple times with sequential transaction IDs of "1235", "1236", and so on. Because the transaction IDs are sequential, the payment system may accept these transactions as legitimate, even though they are fraudulent.

Another example is a "man-in-the-middle" attack, where the attacker intercepts the communication between the client and the server and modifies the transaction data. The attacker can modify the transaction amount, the recipient's information, or other critical data, effectively redirecting the payment to a different account.

To prevent this type of attack, payment software should use random or pseudo-random transaction IDs. Random transaction IDs make it much more difficult for an attacker to guess or predict valid IDs, as they are not predictable.

When generating unique transaction IDs in a Spring Boot monolithic application, there are several best practices you can follow to ensure that your IDs are both unique and secure:

1. Use UUIDs: A UUID (Universally Unique Identifier) is a 128-bit number that is guaranteed to be unique across all systems and networks. You can generate UUIDs in your Spring Boot application using the java.util.UUID class.
2. Use a cryptographic hash function: You can also generate unique transaction IDs by hashing a combination of data that is unique to each transaction, such as the current time, a random number, or a user ID. You can use a cryptographic hash function such as SHA-256 to generate a fixed-length hash value from this data.
3. Combine multiple approaches: To further enhance the uniqueness and security of your transaction IDs, you can combine multiple approaches, such as using a UUID or hash function as the base ID and appending a counter value.

The best practices for generating unique transaction IDs in a Spring Boot microservice are similar to those for a standard Spring Boot application, with a few additional considerations:

1. Use a globally unique ID generator: In a microservice architecture, it's important to ensure that each microservice generates globally unique transaction IDs, even if multiple microservices are involved in processing a single transaction. One approach is to use a globally unique ID generator, such as Twitter Snowflake, which generates 64-bit IDs using a combination of timestamp, worker ID, and sequence number.

Bonus

When storing transaction IDs in a database, it's recommended to use a string data type instead of an integer data type. Here are a few reasons why:

1. Data length: The length of the transaction ID generated by tools like Twitter Snowflake or UUID can exceed the maximum value of an integer data type. In such cases, storing the transaction ID as a string will prevent data truncation.
2. Performance: When a database index is created on a string column, the database can perform faster string-based operations like "starts with," "contains," and "ends with." This is particularly useful when querying transaction data.
3. Unique constraint: When a database table has a unique constraint on a transaction ID column, storing the transaction ID as a string can help to avoid conflicts caused by colliding integer values. Since string values are unique by default, using a string column for transaction ID can make it easier to maintain uniqueness constraints.
4. Compatibility: some globally unique ID generators like UUID generate unique IDs in a string format. By storing transaction IDs as strings in your database, you can ensure compatibility with these ID generators and avoid any conversion or parsing issues.

Until next time!