3

I have an asp.net application, accessed by people over the internet using web browsers. It runs on a web server and it talks to a backend database.

Some of the users would like to use the application to store some private data. The requirements of this are:

1) Only the user who stored the data should be able to see it.

2) The developers/dbas should not be able to see the data.

3) If the web server and database server were compromised a hacker must not be able to decrypt the data.

So, it's obvious I'm going to have to encrypt this data. If I encrypt it there will be a key somewhere and probably a salt/IV. The question is where do I store the data which is used to perform the decryption? If I store it in the database or the web server then a developer, dba or hacker can access it and decrypt the data.

I think my ideal solution to this would be for the private key to be on the clients machine, that way they are entirely responsible for it. But I'm not sure of how to go about this with an asp.net web application.

I believe I can create a certificate which also stores a private key (PFX). The client companies could use group policy to deploy the certificate to their domain. But it is possible that the ASP.Net application can request the web browser to send the private key to it so that it can perform the decryption? Decrypting on the client would be best but other than creating something in javascript I don't see how this is possible.

Any advice welcome.

MusiGenesis
  • 74,184
  • 40
  • 190
  • 334
Beakster
  • 348
  • 1
  • 12

2 Answers2

2

Store the key in the mind of the user. Use any password/passphrase based key derivation algorithm you like. The standard is PBKDF2. The optimum choice of algorithm will depend on precisely what your security requirements and threat mode is. Ideally, that decision and the implementation should at least be reviewed by a security expert.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278
  • Thanks for the suggestion. This poses a couple of problems. Currently each user has a password and we store this as a salted SHA2 hash so we can verify it. Your solution would involve getting the user to enter their password each time they encountered private data, which would be an inconvenience. Also, if they forgot their password then the encrypted data would be lost. – Beakster Oct 12 '11 at 19:57
  • You can store the password on the user's system while he's using it, if you wish. You can implement key recovery if you wish. As I said, it all comes down to picking the best solution for your precise requirements. Hire a security expert to do that. (If only the user should be able to access the data, if the user dies, the data *should* be lost.) – David Schwartz Oct 12 '11 at 20:04
  • @DavidSchwartz What if the data is shared with another user that’s alive? – Ash Jun 17 '19 at 09:53
0

Is it possible that you deploy a ClickOnce application as a part of your solution? The ClickOnce could easily access the cert store on a local machine thus allowing you to perform client-side encryption.

Wiktor Zychla
  • 47,367
  • 6
  • 74
  • 106
  • Thanks for the suggestion... I don't think a ClickOnce application will work as we have to support platforms other than Windows. – Beakster Oct 12 '11 at 19:54