Ensuring Data Integrity Between a Client and Server

In my last post, I talked about how to secure a Flash high score board. One of the steps included SSL. Several people immediately mentioned that they don't have access to SSL. To that end, I'm putting together this little post to explain how it can be done without it.

In the case of a high score board entry the data itself isn't secure. You just need to make sure it hasn't been modified. It doesn't matter if someone sniffs the HTTP data as long as they can't change it, right? To that end, there is no need to go overboard with a true encryption system when you can simply use a "digital signature" to get the same result. Basically, the client will "sign" the data and the server will verify that the signature and data match.

Most digital signature techniques can get pretty complicated and involve using public/private key pairs. In our case, we are going to get the same effect with a ghetto approach. We are going to use a "cryptographic hash" to do this. A cryptographic hash function will take a block of data and turn it into a fixed length "fingerprint". The results of a hash function are reproducible. This means that it's output will always be the same for a given input. Another property of a good hash function is that a tiny change in the input will produce a dramatic change in the output.

For the sake of this discussion, we will use MD5 as the hash of choice. There are better ones (like SHA1) but MD5 is supported by just about every language out there and is pretty simple. For example, PHP, JavaScript, ActionScript 1, ActionScript 3, and Java.

Now we need to apply our hash function to the data itself. Say you need to submit a new score for user "Mike" with a value of "12345". The easiest approach is to simply concatenate those together and run the hash, IE "Mike12345" results in "3658279626b5ed3cd137bef212640144". Then you take the name, score, and hash and send it all to the server. The server duplicates the process to generate a hash and compares them. If the hash from the client matches the hash on the server then the data came across unmodified. If the hashes fail to match, you fail the submission. Nice and simple.

You're not quite done though. If you stop here, you are still vulnerable to someone hacking the data. They could look and guess what you are doing (or inspect the SWF code) and duplicate the hash by hand, submitting a fake score. The way to prevent this is to append one more piece of data before you generate the hash. Specifically, a pass phrase or key.

For the sake of argument, lets say you pass phrase is "password". You take the name, score and pass phrase and come up with this "Mike12345password". When you hash it, you get "a0501c5f1276af9b5be999b980a1e18a". Notice how this is totally different then the previous hash? Then, you send the same data to the server as before; name, score, and hash. The server knows the password already and attempts to duplicate the hash. If it can, the score submission is good.

If you obfuscate your SWF, this might be good enough. The problem is that the password itself is contained in your SWF file and the enterprising hacker might decompile the SWF to figure it out. If this occurs, that will be able to easily duplicate the process and create the hash. The solution to this is for another blog post I'll do in a day or two.

As you can see, each layer of security makes things that much harder for the hacker. While some of this seems complicated, much of it only needs to be created once and then reused as needed. A little library could be created that hides all these details from the developer and makes things nice and clean. If someone is interested in doing this, post a comment. I'd be willing to help out if there is interest. Have fun!