Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Storing Your Secret Data in Windows : Page 2

Although it is generally deemed bad practice, sometimes secrets simply have to be stored somewhere that is accessible to users and/or applications. This article outlines some of the best practices for storing secrets on various Windows platforms.


advertisement
The Easiest Case—Windows 2000 Storing 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 4 Windows 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 Flavors Windows 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.


Michael Howard is a program manager on the Windows 2000 security team. He is the author of Designing Secure Web-Based Applications for Microsoft Windows 2000 and has spoken about security-related issues at many events, including Microsoft Tech�Ed, Microsoft Professional Developer's Conferences, and numerous industry gatherings.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap