DevDays: OpenHack and encrypting the encryption key

If you take a look at the code for the Open Hack application, you may notice that sensitive information is encrypted using an application specific encryption key, but the sensitive information in the registry is encrypted using the DPAPI functions.

Now you may wonder why OpenHack isn’t consistent about the way data is encrypted.

There are actually a couple of reasons why that is. First, OpenHack configures DPAPI to encrypt with a machine-specific encryption key. Consequently, you need to decrypt the encrypted data on the same it was encrypted. That’s quite a problem if you needed to swap out your server that encrypts the data, or if you are running in a load-balanced environment where multiple web servers share the same database.

If you opted for machine-specific DPAPI protection,
then you could not decrypt any data in the database that was encrypted by web server 1 and vice versa. If you do have to decrypt on different machines then DPAPI is not a good choice to encrypt your data. If you are thinking that you’re OK because you’re not running in a load balanced web site, then keep in mind that sometimes you’re forced to swap out severs because of hardware failure.

Let’s get back to OpenHack. If DPAPI isn’t always a good choice, then why does it use it at all? Well, think about what information OpenHack protects with DPAPI:

1) The database connection string. It’s no big deal if we need to change out machines. We know the connection string and can always re-create it.

2) Our(!) encryption string. This is where DPAPI is  a great choice. OpenHack encrypts the encryption key before it stores it in the registry… and to encrypt the encryption key it needs another encryption key. Now you’re stuck … because if you supply an encryption key (A) to encrypt the other encryption key (B), then where do you store that encryption key (A) so it’s safe from an attacker? If you encrypt using DPAPI, then you don’t need to supply an encryption key. DPAPI and the LSA will derive one for you. The derived key is specific to the machine, but that limitation is OK in this case. We know that only local applications read from the local registry and local applications have access to the machine specific DPAPI key.

So the OpenHack code demonstrates how to go about keeping your application’s data safe, because your encryption key is safe.


  • Nice post! Don't forget about the user store (instead of machine store) as another alternative to encrypting / decrypting data that spans a web farm.

  • Paul,

    Thanks for the note. There is one big caveat with the user store for the DPAPI key. You must have roaming profiles enablesd before you deploy the app AND the server for the roaming profile better be available 100%. Otherwise you can get yourself into a nasty situation that's hard to debug.

    Otherwise, user specific DPAPI would be a good solution.


Comments have been disabled for this content.