Developers often ask me how they can safely store secret information when building secure systems. A secret is any data known only to one or more valid computers, users, or applications. Examples include passwords, keys to decrypt other data, and so on. The short answer to their question is they can’t; the long answer is the subject of this article.

Sometimes You Don’t Need to Store the Secret
If you store a secret only to verify that another entity also knows the secret, then you probably don’t need to store the secret itself. Instead, you can store a “verifier,” which often is the hash value of the secret. For example, if an application needs to verify that a user knows a password, you can compare the hash value of the secret the user entered with the hash value of the stored secret. In this case, the secret itself is not stored by the application and thus presents less risk—if attackers break into the system, they cannot retrieve the secret itself.

To make things a little more difficult for an attacker, you can also “salt” the hash value. A salt is a random number that is added to the hash value to stop pre-computed dictionary attacks, making an attempt to recover the original secret extremely expensive. The salt is stored with the hash value. Choosing a hash function is an important decision. Always use a cryptographically strong hash function, one that has been demonstrated to have no—or extremely low—collision chances. In other words, creating two data that compute the same hash value should be infeasible. The hash function de jour is SHA-1. MD5 has fallen somewhat out of favor as subtle vulnerabilities have been discovered in the algorithm.

Let’s look at the steps required to store the hash value of the secret and validate the secret.

1. Store the salted hash value.
• Get the secret you wish to protect (for example, a user’s password).
• Derive a random 128-bit number [use CryptGenRandom()], this is the salt.
• Run a hash function on the secret [use CryptCreateHash() and CryptHashData()].
• Add the salt to your hash value [use CryptHashData()].
• Store the salt and the hash value.
2. Verify that the user knows the secret.
• Get the secret from the user.
• Run a hash function on the secret [use CryptCreateHash() and CryptHashData()].
• Get the hash value and the salt from storage.
• Add the salt to hash value [use CryptHashData()].
• Compare the two salted hash values. If they are the same, then chances are the user knows the secret.

As you can see, you may be able to get away with not storing a secret, which is always preferable to storing one. But sometimes you must store the secret. So let’s look at secure ways of doing so.

The Safest Way to Store Secrets
The most secure way to store and protect secrets is to get input from a user. This input can be used as the key to encrypt and decrypt the protected data. In other words, the secrets are protected with data held in a user’s head; they are not persisted.

However, storing secrets this way can often become unusable for most users. The more items of information (number of passwords) you make them remember, the more likely they are to use the same password over and over, which reduces the system’s security and usability, and increases complexity.

Now let’s turn our attention to the more complex issues of the error-prone method: storing secrets without prompting for user-defined keys.

The Easiest Case—Windows 2000Storing secrets on Windows 2000 is straightforward. To store data for a logged-on user, use the data protection APIs (DPAPI), CryptProtectData(), and CryptUnprotectData(). These functions encrypt/decrypt data using a key derived from the user’s password. Only a user with logon credentials matching those of the encrypter can decrypt the data. In addition, decryption usually can be performed only on the computer where the data was encrypted. However, a user with a roaming profile can decrypt the data from another computer on the network. CryptProtectData() also adds a keyed integrity check (called a MAC, or Message Authentication Code) to the encrypted data to guard against data tampering.

To store data for a system component or service, you also can use LSA secrets [LsaStorePrivateData() and LsaRetrievePrivateData()]. LSA secrets should be used only by services that store service-specific secrets on the machine, not user-specific or per-user secrets. This is because LSA will store a total of only 4,096 secrets per system. Of these 4,096, the system reserves half for its own use.

A Somewhat Easy Case—Windows NT 4Windows NT 4 does not have DPAPI, but it does have CryptoAPI and Access Control Lists (ACLs). Encrypt the data you wish to secure with a key you derive by calling CryptGenRandom(), store the key in a resource that can be ACL’d (such as the Registry), and define an ACL on the resource—one that allows only your application to read it. A typical ACL contains only Creator/Owner Full Control and Administrators Full Control. If you are really paranoid, place an audit ACE (SACL) on the resource too.

You can also use LSA secrets [LsaStorePrivateData() and LsaRetrievePrivateData()], as previously discussed in the Windows 2000 section.

A Note About LSA Secrets: Administrators can still view secrets protected by LSA using tools such as LSADump2.exe from BindView, if they have physical access to the computer.

The Rest of the Windows FlavorsWindows 95, Windows 98, Windows ME, and Windows CE 3.0 all have cryptographic functionality built-in in the form of CryptoAPI, but none has ACLs, and by inference they have no notion of identity. Saving secret data in a resource such as the Registry or a file is easy, but where do you store the key used to encrypt the data? In the Registry also? How do you secure that?!This is a difficult problem. You need to know a couple of things before trying to tackle it:

1. You can hide secrets on these platforms, but they will be much easier to find than on Windows NT 4 or Windows 2000. In short, if the data being secured is high-risk (such as medical data) then consider Windows 2000 unless you are getting a key from a user or an external source to encrypt and decrypt the data.
2. When using these platforms, you could derive the key by calling CryptGenRandom(). Then you could store this key in the Registry and encrypt it with a key derived from something held on the device, such as a volume name, a device name, a video card name, and so on. (I bet you wish Intel had stuck with shipping their Pentium III serial numbers now, don’t you?) Your code can read the “device” to get the key that unlocks the Registry key. Of course if any of these should change, the data is lost!

It is important to realize that none of this is secure, but it may be secure enough for the data you are trying to protect. It is important to notify your users that an application stores secrets on a best-effort basis.

A good practice no matter which platform you’re working on is to make use of what’s available. Leverage the operating system. If your app works on all Windows platforms (Windows 2000, WinNT, Win9x and WinCE), then use the capabilities of the OS; don’t use the lowest common denominator.

Coding Secrets
When handling secret information in your code, you should minimize the time it is in cleartext (i.e., not encrypted). This reduces the risk of the secret leaking out to a paging file. Once you have used the secret in your code, overwrite the buffer with bogus data using, say, memset(). Many theories exist about how best to “scrub” unused data, but the following C/C++ code snippet should suffice:

void ScrubBlob(void *b, DWORD cb) {    for (int i=0; i < 7; i++) {        memset(b,0xFF,cb); // all 1's        memset(b,0x00,cb); // all 0's        memset(b,0xAA,cb); // 10101010        memset(b,0x55,cb); // 01010101    }    ZeroMemory(b,cb);}

One Last Tip
If your application includes sample applications or sample code, do not install them by default. Over the years, many systems placed on the Internet have shown themselves to be vulnerable because their sample applications, which were included by default, had vulnerabilities in them.