Keeping secrets can be hard for many people, but sometimes it's even harder for software. It's difficult to think of many modern programs that don't deal with secret data such as usernames, passwords, credit card numbers, and even email addresses in one way or another. Why just to write this blog post I had to log in to my weblog using a secret password after connecting to my wireless network with a WPA password after logging in to Windows using yet another password. Passwords and other sorts of secret data are used in all sorts of software, so it should concern you, as it does me, that many programs don't do a good job keeping your secrets. There's really no excuse for this lack of security since Windows XP and the .NET framework offer several relatively easy to use facilities for gathering credentials and securely storing secret data.

If you need to securely prompt for credentials, you can use the CredUIPromptForCredentials function in credui.dll to pop up the standard credentials dialog that IE and other programs use. Not only does this function provide a consistent UI and save you the trouble of creating your own dialog, it also can automatically store the credentials securely and skip prompting the user for them again later. I won't go into implementation detail here since Duncan Mackenzie has written an excellent MSDN article on exactly this topic.

If you need to securely store credentials or other secret data, you can use the Data Protection API (DPAPI) functions CryptProtectData and CryptUnprotectData in crypt32.dll. These functions can be used to encrypt any data (in the form of a byte array) using an encryption key automatically derived from your Windows password. The great thing about the DPAPI is that Windows does all the tricky key management for you. An application using the DPAPI can also optionally provide a byte array of entropy to keep other applications running under the same Windows account from accessing encrypted data. MSDN has an article that explains the details of using the DPAPI and it even includes sample C# code for a DPAPI wrapper class.

Finally, if you're waiting for Whidbey (.NET 2.0) to rid you of the need to dive into unmanaged code for security, you're mostly in luck. Whidbey provides a simple managed wrapper class called System.Security.Cryptography.ProtectedData for the DPAPI functions CryptProtectData and CryptUnprotectData. Another great addition to the framework is the System.Security.SecureString class. SecureString lets you handle sensitive strings by keeping them encrypted in memory and clearing them out of memory when no longer needed or when garbage collected. Unless I'm just overlooking it, the only thing I've mentioned that's missing in Whidbey is the ability to make use of the standard credential dialog.

As you can see, Windows XP and the .NET framework can help your software keeps users' secrets safe and secure. I hope these tips come in handy the next time you're considering hard coding an encryption key into your code or considering using XOR and/or base64 encoding to "encrypt" secret data.