6

We have a site, where a user will be saving extremely personal and sensitive data in our database.

We of course will need to be encrypting this data before it is stored in the database, and using SSL. It is an MVC application that will use form authentication. what is the best way to ensure that this data is encrypted from the time we save it until the time it is decrypted for display on their personal page.

We need to also ensure that it will be secure from even our developers and dba's working on the app.

What is the best way to handle this situation?

twal
  • 6,999
  • 17
  • 48
  • 58
  • What/who are you trying to protect the data from? – Lasse V. Karlsen Feb 07 '11 at 18:18
  • Anyone who might want to get it. Basically we just need to be able to ensure the users that they will be the only ones to ever see the data. (though I know it is impossible to guarantee it 100%, we need to get as close to it as possible) – twal Feb 07 '11 at 18:26
  • 3
    Then you basically need to encrypt with a key provided by the user at runtime. Of course, if the user loses that key (remember, it's users we're talking about), say bye-bye to the data. – Lasse V. Karlsen Feb 07 '11 at 18:27
  • 1
    Also remember that it will have a **high** cost. You won't be able to execute a simple search query, for instance (without decrypting all rows for all columns involved in the criteria that is). – rsenna Feb 07 '11 at 18:39
  • @twal: What did you end up doing? I am curious, I am in the same situation... – boggy Oct 27 '16 at 16:59

3 Answers3

3

SQL Server has some built-in encryption capabilities (dead link) encryption capabilities you might take a look at.

Adrian Thompson Phillips
  • 6,893
  • 6
  • 38
  • 69
Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
1

There is no way to keep a DBA out of the data unless you used a public key encryption and the end user would have to control this. If the end user lost their key, they would lose all their data.

You could have a separate database where you store the keys and your DBA wouldn't have access to this DB.

You would have to have two DBAs, one for the data and one for the keys.

This is assuming you don't trust your DBAs, but then you shouldn't have hired them.

If you trust your DBAs, then you let them have access to both DBs, but require that they have separate accounts so if one account gets compromised, they(hackers) wouldn't have access to everything.

Typically, in a well designed system, the DBA/Admins have separate accounts for their personal work and an elevated account for doing work.

I'm assuming the programmers only have access to a test environment. If they have access to the production environment, then they will have access to both the keys and the data.

Bengie
  • 1,035
  • 5
  • 10
  • We trust them, as mentioned we are just trying guarantee as much privacy as possible to the customer, I understand the situation I described is idealistic. Of course we understand in the end some people internally will have access to the data if they really want/need to get it. We are just trying to get as close to the ideal scenario as possible. These comments are helping greatly. Thank you – twal Feb 07 '11 at 19:04
0

Every Encryption has a key and the key is ( to get / not to get ) that key :) The best way is to set the key on web.config which you can do without any programming background

And I have seen a beautiful AES Encryption Algorithm implementation at StackOverflow. I would suggest you use that.

Community
  • 1
  • 1
naveen
  • 53,448
  • 46
  • 161
  • 251
  • Setting the key in web.config would allow developers to access the data, unless I'm missing something. – mxmissile Feb 07 '11 at 18:38
  • @mxmissile: Production web.config ≠ Development web.config. Also, production db ≠ development db. – rsenna Feb 07 '11 at 18:43
  • @mxmissile: let developer develop with a key they know. we could change it after deployment. – naveen Feb 07 '11 at 18:47
  • Encrypt your web.config if you store encryption keys in it: https://msdn.microsoft.com/en-us/library/bb986855.aspx – Verthosa Jan 24 '18 at 08:17