Troubleshooting Tips
LANGUAGES: All .NET Languages
ASP.NET VERSIONS: 1.0 | 1.1
DPAPI Storage Options
Should you store your keys in a user store or a machine store?
By Don Kiely
The Data Protection API (DPAPI) Microsoft has included with versions of Windows starting with Windows 2000 is a great way to take care of one of the biggest problems with encryption: how and where to store the private keys used to encrypt data. As a part of Windows itself, DPAPI strongly encrypts the keys and stores them in either of two places: a user store or a machine store. Which you choose has significant impacts on the security of the keys and their usability with some kinds of applications, particularly ASP.NET apps.
When you use the DPAPI user store, the keys are stored as part of the user's data. This makes user storage by far the most secure of the two options, not because the encryption or protection is any better, but because only one user of the particular machine can decrypt the data. A bit more specifically, only a particular user's apps can get at the data. This is because the key for creating the master key (which I discussed in Can You Keep a Secret?) uses the user's security credential, typically a hash of the login password. But if the user was authenticated by Windows using another credential from, say, a smart card, DPAPI can use that credential as well. This means that only that user can get at the data because only the single user will have the correct credential to extract and use the correct key for the data.
The DPAPI machine store is just as secure as a user store in terms of the strength of the encryption, but now DPAPI uses a single, machine-specific key for all applications on that machine. This is less secure in that all apps on a machine share a key so that, in theory, any user on that machine can decrypt the data. Each individual app can still use entropy as part of the encryption, however, a kind of salt is used in encrypting the data. You have to know the entropy to decrypt the data, however, which once again raises the issue of how you can safely protect and store the entropy for later decryption.
The key to using a user store is that it requires a profile on the machine, which means that there has to be a logged-in user under which the application runs. While that sounds great - and is, for many kinds of applications - it causes a problem for some server applications. Such as ASP.NET. Particularly ASP.NET!
The problem is that ASP.NET doesn't cause a user profile to load. Of course not! You don't have to have a user logged in to respond to a request for an ASP.NET page. If you're familiar with the Win32 API you might think that you can just call the LoadUserProfile API function and have a user profile available that way. But that function requires admin privileges to run, something you most certainly don't want to do with a Web app.
So, does that mean you can only use machine stores for ASP.NET and other server applications? Fortunately not, but it takes some extra work to implement. I'll go into detail in a column in the very near future, but if you want to read ahead, check out the Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT09.asp) article in the Patterns & Practices section on MSDN. And be sure to look at the other DPAPI articles in the table of contents on the left side of that page.
On the other hand, maybe a machine store is okay for a server app, as long as the server is locked down and secure. But only your application requirements can tell you for sure.
Don Kiely is senior technology consultant for Information Insights, a business and technology consultancy in Fairbanks, Alaska. E-mail him at mailto:[email protected].
