Sometimes You Don t Need to Store a Secret

If you store a secret for the purpose of verifying that another entity also knows the secret, you probably don t need to store the secret itself. Instead, you can store a verifier, which often takes the form of a cryptographic hash of the secret. For example, if an application needs to verify that a user knows a password, you can compare the hash of the secret entered by the user with the hash of the secret stored by the application. In this case, the secret is not stored by the application only the hash is stored. This presents less risk because even if the system is compromised, the secret itself cannot be retrieved only the hash can be accessed.

What Is a Hash?

A hash function, also called a digest function, is a cryptographic algorithm that produces a different output, called a message digest, for each unique element of data. Identical data has the same message digest, but if even one of the bits of a document changes, the message digest changes. Message digests are usually 128 bits or 160 bits in length, depending on the algorithm used. For example, MD5, created by RSA Data Security, Inc., creates a 128-bit digest. SHA-1, developed by the National Institute of Standards and Technology (NIST) and the National Security Agency (NSA), creates a 160-bit digest. (Currently SHA-1 is the hash function of choice. However, NIST has proposed three new variations of SHA-1: SHA-256, SHA-384, and SHA-512. Go to csrc.ncsl.nist.gov/cryptval/shs.html for more information about these algorithms.)

Not only is it computationally infeasible to determine the original data by knowing just its message digest, but it s also infeasible to create data that will match any given hash. A good analogy is your thumbprint. Your thumbprint uniquely identifies you, but by itself it does not reveal anything about you.

Creating a Salted Hash

To make things a little more difficult for an attacker, you can also salt the hash. A salt is a random number that is added to the hash to eliminate the use of precomputed dictionary attacks, making an attempt to recover the original secret extremely expensive. A dictionary attack is an attack in which the attacker tries every possible secret key to decrypt encrypted data. The salt is stored, unencrypted, with the hash.

Creating a salted hash, or a verifier, is easy with Microsoft CryptoAPI (CAPI). The following C/C++ code fragment shows how to do this:

// Create the hash; hash the secret data and the salt. if (!CryptCreateHash(hProv, CALG_SHA1, 0, 0, &hHash)) throw; if (!CryptHashData(hHash, (LPBYTE)bSecret, cbSecret, 0)) throw; if (!CryptHashData(hHash, (LPBYTE)bSalt, cbSalt, 0)) throw; // Get the size of the resulting salted hash. DWORD cbSaltedHash = 0; DWORD cbSaltedHashLen = sizeof (DWORD); if (!CryptGetHashParam(hHash, HP_HASHSIZE, (BYTE*)&cbSaltedHash, &cbSaltedHashLen, 0)) throw; // Get the salted hash. BYTE *pbSaltedHash = new BYTE[cbSaltedHash]; if (NULL == *pbSaltedHash) throw; if(!CryptGetHashParam(hHash, HP_HASHVAL, pbSaltedHash, &cbSaltedHash, 0)) throw;

The complete code listing is available on the companion CD in the folder Secureco\Chapter 7\SaltedHash. Determining whether the user knows the secret is easy. Take the user s secret, hash it, add the salt to the hash, and compare the value you stored with the newly computed value. If the two match, the user knows the secret. The good news is that you never stored the secret; you stored only a verifier. If an attacker accessed the data, he wouldn t have the secret data, only the verifier, and hence couldn t access your system, which requires a verifier to be computed from the secret. The attacker would have to attack the system by using a dictionary or brute-force attack. If the data (passwords) is well chosen, this type of attack is computationally infeasible.

As you can see, you might be able to get away with not storing a secret, and this is always preferable to storing one.