Using DPAPI / ProtectedData in a web farm environment with the User Store

Question

I was wondering if anyone had successfully used DPAPI with a user store in a web farm enviroment?

Because our application is a recently converted from 1.1 to 2.0 ASP.NET app, we're using a custom wrapper which directly calls the CryptUnprotect methods. But this should be the same as the ProtectedData method available in the 2.0 framework.

Because we are operating in a web farm environment, we can't guarantee that the machine that did the encryption is going to be the one decrypting it. (Also because machine failures shouldn't destroy our encrypted data).

So what we have is a serviced component that runs in a service under a particular user account on each one of our web boxes. This user is a set up to have a roaming profile, as per the recomendation.

The problem we have is that info encrypted on one machine can not be decrypted on another, this fails with the win32 error:

'Key not valid for use in specified state'.

I suspect that this is because I've made a mistake by having the encryption service running as the user on multiple machines, hence keeping the user logged in on more than one machine at the same time.

If this is the problem, how are other using DPAPI with the User Store in a web farm environment?

Humfrey

Hi, did you get the answer to this? I am having the same problem. – Bags

Answer 1

In a web farm environment, rather than using DPAPI to encrypt/decrypt your data directly, you would instead use it to encrypt the key that you later use to decrypt your protected data.

You would "install" the key onto each server as part of the deployment process. The installation script would need to run under the AppPool's identity, and could store the encrypted key either in an app.config file or in the registry.

The encrypted data itself could be stored in a central repository / database, so that it can be accessed by all servers in the farm. To decrypt the data, the web app would retrieve the encrypted key from where it was installed, use DPAPI to decrypt it, then use the result to decrypt data that comes from the central repository.

The downside is that the cleartext key might exist on the local disk for a short time during the initial install process, where it might be exposed to operations staff. You could add an extra layer of encryption, such as with the web.config machineKey, if that's a concern.

Alisiaalison

This is a bit stale, but I believe that you will still be able to "see" the key even if contained in the web.config and encrypted using aspnet_regiis. Your approach is what most people are looking for as there is no similar mechanism out-of-box in ASP.NET or the BCL. – Rabush

This is unfortunate, because one of the advantages of DPAPI is that it automatically expires the master key every 3 months, yet is able to decrypt previously encrypted data. msdn.microsoft.com/en-us/library/ms995355.aspx Quote: "This expiration prevents an attacker from compromising a single MasterKey and accessing all of a user's protected data." Using your own key if its is compromised, all your data is exposed. – Gallinule

Answer 2

The Microsoft poster is wrong. http://support.microsoft.com/default.aspx?scid=kb;en-us;309408#6

"For DPAPI to work correctly when it uses roaming profiles, the domain user must only be logged on to a single computer in the domain. If the user wants to log on to a different computer that is in the domain, the user must log off the first computer before the user logs on to the second computer. If the user is logged on to multiple computers at the same time, it is likely that DPAPI will not be able to decrypt existing encrypted data correctly."

It appears that DPAPI will not work in a farm setting. I think this is a rather large oversight on Microsoft's part and makes DPAPI almost useless for most enterprise applications.

Intimist

Answer 3

I just saw this. There is a way you can make this work, and that is to make sure the machines in the farm are in a domain, and use a domain account to encrypt and decrypt the data (ie; run the application under the domain account)

You cannot use DPAPI in the manner you want with local accounts because the key material is not exchanged between servers.

hope that helps!

Kujawa

Answer 4

Twelve years later . . . you can try using CNG DPAPI, which was meant to work in cloud environments that may or may not be load-balanced. From that link (in case it gets taken down):

Microsoft introduced the data protection application programming interface (DPAPI) in Windows 2000. The API consists of two functions, CryptProtectData and CryptUnprotectData. DPAPI is part of CryptoAPI and was intended for developers who knew very little about using cryptography. The two functions could be used to encrypt and decrypt static data on a single computer.

Cloud computing, however, often requires that content encrypted on one computer be decrypted on another. Therefore, beginning with Windows 8, Microsoft extended the idea of using a relatively straightforward API to encompass cloud scenarios. This new API, called DPAPI-NG, enables you to securely share secrets (keys, passwords, key material) and messages by protecting them to a set of principals that can be used to unprotect them on different computers after proper authentication and authorization.

In .NET Core this looks like

public void ConfigureServices(IServiceCollection services)
{
    services.AddDataProtection()
        .ProtectKeysWithDpapiNG();
}

Sauers