Introducing Transaction and Instruction hashing

The Scenario:

A nefarious user gets access to the database and changes account details or amounts for payments to be made. The Authorisers may not initially pick up that the changes have been made and allow a corrupted payment to be made. 

This has a big impact on business as payments could be erroneously made and they are very difficult if not impossible to undo. 

The Solution:

Verify that the transaction entered or the instruction created have not been tampered with during its progression through the system. 

The Motivation for the Chosen Implementation:

Hashing was chosen as the implementation since it could be implemented without undue risk to existing implementations and it could be done in a way that is entirely secure. 

Hashing is lightweight since it only requires the generation and validation of the hash at key points in the process. It does not require any changes to CentralPark's existing process only the addition of a few columns on existing tables to track the hash. This means that there is no impact on the data and structures of the data, reducing the risk of impacting existing clients' data. 

Creating the hash itself is very efficient and fast and since transaction and instruction data is already being stored the overhead of storing a few extra fields is minimal. 

An added security feature of hashing is that the "key" used in creating the hash is stored within the code, making the computing of hashes very difficult to reverse engineer since the hash does not depend solely on the data visible in the database. 

The Actual Implementation:

When a transaction enters the system via an import or a manual capture, various details of the transaction (including  specifically the account number and amount) are used to compute a unique hash value using a SHA-256 hashing algorithm. This hash is stored along with the transaction. 

Before a transaction is legitimately edited from the front end, the stored hash is validated to verify that the transaction has not been tampered with. Once the legitimate edit is done a new hash is generated for the newly set values. The edit process is logged in CentralPark's history of that transaction. 

At the point of instruction creation the transaction used to create the instruction has its hash validated. This ensures that the transaction was not tampered with as it was processed through the system. The resulting instruction is created along with a hash of its values. This is an 'atomic' step (1 step process) in which the transaction is validated and the instruction and its hash are created. 

Finally, before the instruction is incorporated into an Instruction Document, to be sent to the bank the instructions to be used in the document are all validated against their hashes to confirm that they were not tampered with. 

A comprehensive list of tests were done to validate the integrity of the hashing implementation. Embedded below is a document that describes the tests carried out. These tests were run in an attempt simulate what a user may do to try to push through an invalid transaction. 

The Exceptions:

If a hash validation fails for a transaction or instruction, the running process will be aborted as a failure and the offending transactions or instructions will be logged in an error table. Exceptions can then be viewed via a new screen in the Admin menu called Hash Validation Failures.

The Performance:

Numerous tests were done on batches from 10 - 50000 - 200 000 transactions that were Imported and processed through to an Instruction Document being created. The performance degradation in labs tests was approximately 12% on batches of 50 000 and 6% on Batches of 200 000.