Why HMAC is a Good Idea
September 29, 2014
When validating the integrity of messages sent between systems, it’s common to rely on Message Authentication Codes. These codes are a hashed value created using some or all the values within the message being transmitted and sent along with the message itself. On the receiving end, the same set of values are used to re-create the code. If the code received in the transmission matches the code that was generated by the server, then this guarantees1 that the data received has not been altered in any way during transmission.
That’s a mouthful. Let’s look at a brief example:
Given the following data2:
Using the MD5 hashing algorithm, available online here, the hash value for this message is:
Therefore, the payload sent to the server will be:
When the server receives this payload and generates an MD5 hash value of the Message, the same HMAC value should be calculated.
Even a minor change to the message, such as the capitalization of a single letter, will significantly alter the HMAC value. For instance:
Therefore, our server can say with high confidence that the message has not been altered after its creation by the sender application.
There is a potential risk that the payload could be re-sent multiple times to the server, as the payload does not contain any time-sensitive information. The server, recognizing it as a valid message (from an integrity standpoint), would simply process it successfully and move on.
To mitigate this risk, include a time-stamp within the payload as well as within the HMAC’s input data.
This time, our hashing algorithm will use the concatenation of the Message and Send Time as input and result in the following hash value:
Finally, our payload sent to the server will be:
Our server, concatenating the Message and Send Time in the same manner, will generate the same HMAC value. This solution helps mitigate the risk of a particular message being repeatedly sent to the server by having the server compare the current time versus the Send Time value received on the message, expiring it after a brief period of time. The server has high confidence that the Send Time value has not been altered after the payload was generated by the application code, as shown in the first example.
During initialization, the software would register itself with the server and include the hosting domain. The server would then validate the domain against one of the pre-registered domains and respond with a unique token value associated with that domain.
This unique token would then be included in all subsequent requests made by the application so the server could ensure no conflicts exist. If configured so that unique tokens are not known to the client application until the point of registration (initialization), your system can revoke and re-generate tokens as needed (such as the case if a token were compromised.)
The payload has been slimmed down for simplicity:
Given an unlimited amount of resources (including time), any security solution can be deconstructed and/or circumvented, but the key is the effort required. By constructing sufficient barriers, if a solution is ever breached, the hope is that it is breached well beyond the period of usefulness for the information that is acquired.
1: In theory, the same hash value could be generated using different input values, but the likelihood of this is very low.
2: (c) Willard C. Smith & Jeffrey Townes, UNIVERSAL MUSIC-Z TUNES LLC, (ASCAP)
Stay up to date with our email updates!