Securing Variables with Hashes

By Flib

Category: Security

Using hashes to detect user tampering

The problem

Often, scripts need to send data in the url. The problem with doing this is that users may tamper with data possibly resulting in security problems.

In this article, I show you how to use hashes to secure GET variables and other data.

The Solution

Hashes

Hash functions such as MD5 and SHA1 are fairly simple in concept, they are essentially a little black box that when you input a number in one end, a fixed size random looking number is output at the other end. MD5 uses 128bits to store this output value, frequently encoded into a 32 character hexadecimal number. SHA1 on the other hand uses 160bits which is often encoded as 40 character hexadecimal number.

Collisions are rare with hash functions, but not unheard of. A collision is where two different inputs result in the same output. The normal place this is often seen is in large password databases, where many users all choose the same password. To get around this a salt is used.

Salts

A salt is a random string that is prepended or appended to the input of the hash function and stored along side the resulting hash. This means that some of the attacks that are used to look for matching hashes and by extension the original input to the hash function.

Using salts to protect variables

If we use something similar to:

Where aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d is the SHA1 hash of 'hello'. We can check the url for validity by doing exactly the same when we receive the next request. This alone will filter out most of the casual people who try to change things to see what else they can make a site do. This isn't enough however to deter an advanced hacker.

If we generate a random salt every time we start a new session and store it in the session, then we can use the salt to protect the checksum. A hacker doesn't know the salt and as such can't generate a valid checksum to match a server generated one.

This isn't a perfect solution, since users can still see what variables are being passed, however short of doing encryption on the variables, anything else will simply be a token effort. (Although if your heart is set on the idea of obscuring the data further, base64 encoding is a good starting point.)

Encryption is rather pointless here for same server communication, since if you don't want the user to be able to see the data, keep it server-side and just pass a reference to it over the URL. It performs the same function but doesn't put the data at risk. For multiple server communication, it may be a necessary evil, although a separate server->server communication would probably be a better option. Again the user doesn't get to see the sensitive data as it travels a different route. (Paypal IPN uses this technique and is pretty secure)