Periodically people ask me about hashes and why the use of a salt value with a hash is recommended. Let’s have a look at this topic in our last blog for 2011!
The use of a secure hashing algorithm is common in business applications. It has a variety of uses in the areas of authentication, data integrity, and tokenization. A hash method is sometimes called one-way encryption, but this is a bit of a misnomer. It is true that you can’t reverse the result of a hash operation to recover the original value (thus it is one-way), but it is not formally an encryption method. This one-way property of hash methods is what makes them so useful. You don’t have to worry about sending a hash value across a network in the clear as it can’t be reversed. (At ease you crypto people, I know about the developing security concerns about SHA algorithms; more on that later).
While there are a number of hash algorithms available in the public domain, most security professionals recommend the use of the SHA-2 family of routines. I find that most people now use the SHA-256 algorithm when they want to create a one-way hash of some data, although the more secure SHA-512 method is being used more frequently. Older methods such as MD5 and proprietary hash methods should not be used in modern applications due to security concerns. With SHA-256 and SHA-512 we have a really good method for doing one-way hashes.
So why do some security professionals recommend the use of a salt value with hashes, and what is salt?
The term salt refers to a one-off value that is difficult to guess. In practical application, a random number is generally used for a salt value. For the sake of this discussion, we will assume that a salt value is a random number.
By adding a salt value to some data before hashing it, you make it more difficult to guess the original value. Notice that I didn’t say you make it easier to reverse! For all practical purposes, you can’t reverse a hash value. But a clever attacker might guess at the original value and perform a dictionary or brute force attack on a hashed value. How can that be?
Well, take the example of your banking PIN code. It might be 4 or 5 digits in length. From the point of view of modern computers, that is a really small set of numbers to test against a SHA-256 algorithm. Only 9,999 values for a 4-digit banking PIN code. That is going to take less that a second to run through all of the possibilities. So this is where a salt value can come in handy. If you are creating a hash value of very small bit of data, you can append a salt value to the original data and make it really hard to attack that hash value. And that’s why using salt with your hashes is often a recommended security practice.
By the way, even though credit card numbers are only 16 digits in most cases, that is still a small number in computational terms. And once you account for BIN codes and LUHN check digits, credit card numbers are effectively smaller than 16 digits. This is why PCI and other regulations require or recommend the use of salt with hashes.
If you do use a salt value with a hash, you have to take care to protect the salt value from loss. You should take as much care about protecting the salt value as you take with encryption keys. If someone knows the salt value you’ve lost your advantage. Also, you should be sure to use a salt value that is large enough to provide good security. A 128-bit salt value is adequate for most business applications.
As I hinted at above, there have been some developments in attacks against the SHA-2 family of hash algorithms. I don’t think these attacks rise to the level of a practical concern in business applications, but the professional cryptographic community is hard at work on new hash methods. I think you should continue to use SHA-256 with confidence, but you should salt that hash for added protection!