[This is the first article of a two-part series. For Part 2, click here.]
When storing highly sensitive data like passwords or other user credentials, the first thought that comes to mind, of course, is encryption. Typically, encrypting information is performed in one of two ways — symmetric or public/private key pair.
In symmetric encryption, both the encrypter and decrypter have access to the same key—the lock on your door at home is a symmetric lock andyou have a key to it that you guard closely. As long as someone doesn’t get a hold of your key, all is well, and your home is protected. However, if you need to give access to your home to someone else, you have to transport your key (or a copy) to the person before they can gain access. This becomes the weak link in symmetric encryption because interception of the key through overt or covert means can give intruders access potentially without you being aware of it.
In public/private key encryption, the problem of how to transport the key was solved through some ingenious mathematics called "one-way functions" or "hashes" (I recommend reading The Code Book, by Simon Singh for a thorough, understandable history of encryption, in general, and public/private key encryption, in particular). These functions take data and mutate it so that mathematically, it is next to impossible to ever get back to the original data, even if you know what the algorithm is that mutated the data in the first place. There are several algorithms available but one of the more secure and widely used ones is the Secure Hashing Algorithm (SHA), which comes in a variety of strengths—defined as the size of the message digest generated by the algorithm. SHA comes in 160, 256, 384, and 512-bit strengths. SHA was developed by the U.S. National Institute of Standards and Technology (NIST) and the U.S. National Security Agency (NSA). Older hashing algorithms such as MD5 (128-bit hash developed by RSA Data Security) offer less strength and there have been reports of weaknesses in some of the algorithms. Unless you have reason to do so, I suggest you stick with one of the SHA variants, the 160-bit hash being the most common.
The beauty of hashes using SHA is that we can use them for tasks outside of public/private key encryption. Specifically, if we need to store sensitive data and ensure that even if an attacker/intruder got a hold of the information they couldn’t decrypt it, the safest approach would be to generate a hash of the data and store the hash instead of the actual data. However, if we can’t decrypt a hash (or unhash the hash), then it follows that we can only use this technique when we want to perform comparisons on the data rather than have access to the plain-text original information. Password storage lends itself to this approach very well and is, in fact, how Windows stores user credentials on your machine or in the domain (if you login to a domain).
Essentially, the algorithm is as follows:
Hash original plain-text password using SHA Store hash Get password from user Hash password using SHA Load hashed password from storage Compare hashes If hashes are equal Then passwords are equal
Pretty slick since the passwords can be safely and accurately verified without worrying about exposing the actual password. In addition, by not storing the plain-text password, we ensure that even if our storage becomes compromised, the intruder won’t be able to unhash the hashed values due to the robustness of the SHA algorithm.
Here is some code that demonstrates creating the hash using the Win32 CryptoAPI:
int hashedstrsize = 20;
BYTE* hashedstr = NULL;
LPCSTR str = "a password;
HCRYPTPROV hCryptProv = NULL;
if (CryptAcquireContext(&hCryptProv, NULL, NULL, PROV_RSA_FULL,
CRYPT_VERIFYCONTEXT))
{
HCRYPTHASH hHash = NULL;
if (CryptCreateHash(hCryptProv, CALG_SHA1, 0, 0,&hHash))
{
if (CryptHashData(hHash, (BYTE*)str, (DWORD)strlen(str), 0))
{
DWORD len = sizeof(m_size);
if (CryptGetHashParam(hHash, HP_HASHSIZE, (BYTE*)&m_size,
&len, 0))
{
hashedstr = new BYTE[m_size];
len = m_size;
if (CryptGetHashParam(hHash, HP_HASHVAL,
(BYTE*)hashedstr, &len, 0))
{
// all is well and we have a hash..
}
}
clear();
CryptDestroyHash(hHash);
}
CryptReleaseContext(hCryptProv, 0);
}
Although CryptoAPI isn’t the most straightforward API to work with, you can see that the number of steps to properly hash a value is not too bad. One important thing to note is that the hashed value comes back as a 20-byte binary value—SHA always produces a 20-byte hash value regardless of the size of the password (or plain text). Keep this in mind when sizing your storage, particularly if you are using a relational database like SQL Server.
Mark M. Baker is the Chief of Research & Development at BNA Software located
in Washington, D.C.
Do you have a Windows development question? Send it to [email protected].
