DPAPI Storage Options

Troubleshooting Tips

LANGUAGES: All .NETLanguages

ASP.NET VERSIONS:1.0 | 1.1

DPAPI Storage Options

Should you store your keys in a user store or a machinestore?

By Don Kiely

The Data Protection API (DPAPI) Microsoft has includedwith versions of Windows starting with Windows 2000 is a great way to take careof one of the biggest problems with encryption: how and where to store theprivate keys used to encrypt data. As a part of Windows itself, DPAPI stronglyencrypts the keys and stores them in either of two places: a user store or amachine store. Which you choose has significant impacts on the security of thekeys and their usability with some kinds of applications, particularly ASP.NETapps.

When you use the DPAPI user store, the keys are stored aspart of the user's data. This makes user storage by far the most secure of thetwo options, not because the encryption or protection is any better, butbecause only one user of the particular machine can decrypt the data. A bitmore specifically, only a particular user's apps can get at the data. This isbecause the key for creating the master key (which I discussed in CanYou Keep a Secret?) uses the user's security credential, typically a hashof the login password. But if the user was authenticated by Windows usinganother credential from, say, a smart card, DPAPI can use that credential aswell. This means that only that user can get at the data because only thesingle user will have the correct credential to extract and use the correct keyfor the data.

The DPAPI machine store is just as secure as a user storein 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 securein that all apps on a machine share a key so that, in theory, any user on thatmachine can decrypt the data. Each individual app can still use entropy as partof the encryption, however, a kind of salt is used in encrypting the data. Youhave to know the entropy to decrypt the data, however, which once again raisesthe issue of how you can safely protect and store the entropy for laterdecryption.

The key to using a user store is that it requires a profileon the machine, which means that there has to be a logged-in user under whichthe application runs. While that sounds great - and is, for many kinds ofapplications - it causes a problem for some server applications. Such asASP.NET. Particularly ASP.NET!

The problem is that ASP.NET doesn't cause a user profileto load. Of course not! You don't have to have a user logged in to respond to arequest for an ASP.NET page. If you're familiar with the Win32 API you mightthink that you can just call the LoadUserProfile API function and have a userprofile 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 forASP.NET and other server applications? Fortunately not, but it takes some extrawork to implement. I'll go into detail in a column in the very near future, butif 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 atthe other DPAPI articles in the table of contents on the left side of thatpage.

On the other hand, maybe a machine store is okay for aserver app, as long as the server is locked down and secure. But only yourapplication requirements can tell you for sure.

Don Kiely is seniortechnology consultant for Information Insights, a business and technologyconsultancy in Fairbanks, Alaska. E-mail him at mailto:[email protected].