7

I have a situation where my web application is going to be deployed on multiple web servers, and I'll be wanting to store some securely encrypted data on the DB servers (each web server has a DB server paired with it).

Now, what I was thinking of doing was implementing Encrypt and Decrypt library functions that utilize the AesManaged class. These would use an AES key that would be different for each server (we would generate a new one for each server on deployment) - that way, each server would be using a different key. We would then use SectionInformation.ProtectSection() to encrypt them in Web.config, so they were secure.

However, I've come accross the ProtectedData class. This hooks into the Windows DPAPI functionality and allows symmetric encryption and decryption. Now I'm wondering, is there any point in my using AesManaged with my own generated keys at all, or should I just encrypt and decrypt data using ProtectedData? What are the pros and cons of each?

Jez
  • 275
  • 1
  • 11
  • You just want to securely store the `Web.config` file on the disk and nothing more? – M'vy Mar 25 '15 at 08:18
  • No, I'll be wanting to store some encrypted data in a DB on each server. I've updated the question. – Jez Mar 25 '15 at 08:23
  • and your database doesn't support data encryption, or are you trying to store the data post encryption? – Jim B May 06 '15 at 15:20
  • 1
    @JimB This is doing the encryption at the domain services layer, because we're using a domain-driven design. We can't rely on a particular database, so no, we can't rely on the database supporting data encryption. – Jez May 06 '15 at 15:29
  • Ahh OK, so you are kinda stuck in that case. You might want to ask on stackoverflow, they still have folks using that model. – Jim B May 06 '15 at 15:32

2 Answers2

2

This is probably a little late but just as a recommendation for other people who stumble on this. For this type of problem I would always use ProtectedData over rolling your own implementation with AesManaged for two reasons. First, you don't need to deal with managing cryptographic keys with ProtectedData which is a hassle to do correctly. Second, there's a handful of security considerations that a developer needs to understand before hand-rolling their own crypto and even then there's a chance the developer could make a mistake and render the crypto useless. Why take the chance and risk a headache when a perfectly acceptable, already vetted, solution is already available?

Justin Moore
  • 769
  • 4
  • 9
0

As Justin referred, using your own keys and then manage them is a no go. That is why you have OS or language mechanisms to do this for you. In java you have local key stores protected by passwords. The cons of relying on the OS to protect your keys is that in case the underlying OS is corrupted in some way, you will probably lose those keys forever. Why won't you use RSACryptoServiceProvider with the CspParameters to create a store with your own keys?

Read: https://msdn.microsoft.com/en-us/library/tswxhw92.aspx

https://msdn.microsoft.com/en-us/library/f5cs0acs.aspx

I think this might help you. In this way you are not bounded to key choices of the OS and can keep your own keys safe away while protecting them locally on stores.

Stay safe ;)

BrunoMCBraga
  • 466
  • 4
  • 12