173: HMAC: Keyed Hashed Message Authentication Code.

How do you stop an attacker from just changing a hash? In the previous episode, I explained how hashes give you the best error detection even when under a direct attack. But the best hash function by itself is not enough. This episode will explain step by step how an attacker can defeat simple attempts to protect data and what you can do about it. Make sure to listen to the full episode where I describe how another hash creates something called an HMAC and how it can be used to prevent length extension attacks. Or you can also read the full transcript below. Transcript In the previous episode, I explained how hashes give you the best error detection even when under a direct attack. But the best hash function by itself is not enough. This episode will explain step by step how an attacker can defeat simple attempts to protect data and what you can do about it. Let’s start with this scenario: You’re designing a game that allows a player to login and then issue instructions to a central server that tell the server where to move the player’s character. If you were playing this game, would you want your opponents to be able to issue commands as if the commands came from you? Not only would the game be unfair, nobody would want to play anymore once the vulnerability became known. So you need to design the game server so it won’t accept any false or malicious commands from other players. If you’re only worried about detecting accidental errors made during transmission of the instructions as the messages travel to the server computer, then you could use a hash. Just create a hash of each instruction and send that along with each instruction. The server can then perform the same hash, compare them, and ask for the instructions to be retransmitted if the computed hash doesn’t match the hash that was sent. This means that your game must remember commands for at least a short while in case they need to be sent again. There are things you can do that would allow the server to sometimes correct an error on its own without asking for the data to be sent again. That’s a whole other topic and I’ll explain error correction in a future episode. The problem with sending a simple hash is that an attacker can send commands intended to disrupt another player’s character. All that attacker has to do is send a command that causes the other character to jump off a cliff and the attacker wins the game. The server accepts the command because it has a valid hash and therefore could not possibly have been accidentally changed during transit. How do we fix this? One of the most important things to realize about security is that there are boundaries that define what’s trusted vs. everything else outside of the boundary that’s not trusted. At some point, something has to be trusted or you might as well go back to designing a single user game that can only be played on a single computer. Then if that user wants to cheat, no problem. The game will quickly become boring though. There’s very little you can do by trying to add security to the player’s computer. It has to be considered outside of the security boundary and therefore a source of possible attacks. Alright, so back to the game design. Maybe your first thought is to add a MAC or a message authentication code instead of a simple hash. A MAC is really nothing more than a hash of some secret key along with the message. The hash function doesn’t have to change and produces the same type of output. Just adding a key to the message results in a different hash value. So where does this key come from? It has to come from the server because that’s inside the trusted zone. In other words, without realizing it, when players agree to play your game, what they’re actually saying is that they agree to trust your server to make sure that the game is fair. They’re not going to trust some other player’s computer.