Using HMAC to protect web-requests from forging

2010-12-15T22:06:00.019+02:00

In this article I will try to demonstrate, how a simple combination of cryptographic primitives (hashing and basic XOR encryption) — HMAC, can be used to construct a primitive (single request) message authentication protocol, which is useful to control, who can access a personalized web service without a need to fully authenticate a user, when requirements allow for some specific issues associated with it.

Why authenticate?

Sometimes you don't want to let people "get any ideas" and tamper with the request data, forging requests you don't want to serve. One particular example is that you may want to give access to a service for a user, but neither you, nor the user, want to have another point of password entry in the system and you don't want any 3rd parties to get in the way. The user wants to just get whatever he needs by simply clicking on a link in an e-mail or IM and you want that only authorized users can do that.

This is a kind of problem I had to deal with last week. A web-application was set up to accept users' orders to perform a service for them (let's say, to write a summary about a news). A request would be tied to a pair: a user ID and a news ID. News ID specifies the news item for which the summary to be written for, user ID refers to the customer's account. Before the bright idea of authenticating such requests came to my mind, the requests would be thus structured like this:

http://some.address.net/app?UserId=31231&NewsId=12312434

But what will happen, if a 'nonconformist' user comes and decides to cause us some trouble, or a malicious 3^rd party gets to know about the unsecured service? If it's a common HTTP GET request with no prior authentication, it's pretty easy to substitute the numbers with something else — other numbers, or even arbitrary strings, something completely unexpected by the application. Even, if pairs of allowed user and news IDs are to be stored in a database, the result would be that an arbitrary 3rd party may guess such pairs and make an unsolicited request on that user's behalf. Not good! So, what do we do?

We need to authenticate the request. A usual, straightforward way is to ask the user for username, password and establish a secure session. But why create all the hassle for the user with entering the password yet another time, if the user is already authenticated in another realm and this order is ought to be just a simple one-off request?

HMAC used as intended

This is what message authentication codes (MACs), and hash-based MACs (HMACs) in particular, are invented for: to make sure messages are only supplied by the intended source, not a malicious 3rd party. By supplying the request with a cryptographically secure message authentication code, we can be sure the message cannot be tampered with (not in a reasonable amount of time and effort, at least). This is how it works:

First, let's identify the actors here. Alice — the message sender (in the example above this is the intended user); Bob — the message receiver (in my example it is the ordering server) and, finally, the tricky and mischievous Mallory trying to imitate Alice to fool Bob into accepting his (or her?) malformed messages.

Just generating a hash of the message will not work: Mallory can easily do that, too (and it's easy to guess, even if Mallory has no prior knowledge about the specific method being used to hash the messages). We need to somehow combine a secret code with the message, so that resulting hash will only match, if both the message and the secret code match.

Now, the secret can be any set of data (a timestamp XORed with a static byte array may even do the trick), the safety concerns are the same as with passwords and generally cryptographic key strengths — the longer and less predictable the key, the better. A rule of thumb is to use something that is genuinely random and cannot be guessed and is long enough, so that it would be infeasible to simply 'brute force' it.

So, why not just use a simple 'keyed hash' and concatenate the secret with the message and hash it with MD5? Because it is considered unsafe. HMAC is a keyed hash, too, but it's more robust, than a naïve implementation. More about it can be found in this article: "Stop using unsafe keyed hashes, use HMAC". HMAC is better, because it doesn't just hash the initial key-message pair, but it also hashes the resulting hash again with a part of the secret key. This way finding a collision for the resulting hash is not enough to break the code: the attacker would have to find a collision in the inner hash, which is potentially much more complex, than just finding a collision for a hash value. [HMAC Security]

HMAC computation is now part of many mainstream standard libraries and runtime environments, like .NET, Python, Java, so you don't have to implement the HMAC algorithm yourself (although it's quite simple), apart from using an existing API. I was using the C#/.NET System.Security.Cryptography API. It's very straightforward to use, so I will leave this as an exercise for you to figure it out.

Other scenarios, where HMACs may help

The example I presented in the beginning doesn't quite match the basic pattern, but it's just a variation of it. In that case Alice is my service, Bob is the service's intended user, authorized only for that particular service, and Mallory is an unintended 3rd party, completely unauthorized to use the service.

Alice generates a secret, stores it and generates and appends an HMAC to the URL; it then sends the URL to Bob, so Bob can get what he needs on Alice. That HMAC will also confine Bob's authorized actions to that particular service, e.g. if the URL is a link to an article named "Bob is Awarded 1st Place on Some Competition", he will only be able to access that, but not, say "Dick reports Bob cheating on Some Competition" (all names are coincidental, bla-bla-bla...). If that URL looked like this:

http://alice.articles.com/GetArticle?
id=1&user=Bob&auth=ceaeb2847bdd12d36ec355bea01f88b3abc1e58d

then if id=1 is substituted with id=2, for example, the HMAC will not be valid anymore and it will be too hard to forge. This will be true in the case with Mallory, too: unless Mallory enters the right HMAC along with the Id and user name used to generate the authentication code, his forged request's authentication will fail too.

Caveat

HMAC in the URL above becomes the 'password' and, thus, if the full URL used by Bob to access the service becomes known to Mallory, then the service will be accessible to him, too. An attack performed by Mallory in this case is called a replay attack. This is deliberately left so to keep the protocol simple (the actual request contains all the necessary data to both validate it and execute without need for any prior negotiation or data exchange). But because of that Bob must not be interested in sharing that link and must be aware of the risks associated with sharing the link.

Mallory may also get access to Bob's service access URLs by other means: due to mistakes in delivery software, human error or deliberate attacks on Bob's communication. So the services provided in this regard to Bob should not be so valuable to Mallory as to encourage him to attack Bob or his computers to gain access to his service links.

This problem can be reduced somewhat by adding a parameter to the message, which changes on every request and invalidates the message, once it's used. It doesn't solve this problem completely, though. Only a proper authentication protocol will overcome this issue.

This simple protocol is still useful though where the service provided to Bob is either too much specific to him (i.e. personalized and limited, but doesn't contain any sensitive data to raise privacy concerns), or is not very valuable to others alone (without something else only accessible to Bob in a properly authenticated realm, for example.

Conclusion