1

I work with asp.net core 1 and I will introduce an encrypted storage of user data. These data must not be accessible to the database administrator but only for users with a passphrase.

I thought of using:

  1. IdentityServer to ensure the authentication. (With TLS).
  2. Encrypt user data with a symmetric key. (can i use TDE? is possible hiding the key to administrators? )
  3. Encrypt the symmetric key with the passphrase.
  4. Save only a hash of the passphrase.

Brute-force attacks by administrators may recover the data?

It could be better?

  • Where should the encryption-decryption occur? Client-side or server side? If it is client-side, system admins can neither access nor recover data, it it is server side, they could intercept the keys, and/or the decrypted data exchanged with the clients. Not really easy but possible... – Serge Ballesta Jan 31 '17 at 13:32
  • @SergeBallesta At first I thought to encrypt the client side using the library: Stanford JavaScript Crypto Library. I later read that it was still necessary to use TLS / SSL so I decided to do it server side. There is no way to make that data not accessible? – Sergio Jan 31 '17 at 14:25
  • What are your plans for when a user forgets their passphrase? If you store only the hash of the passphrase, it will become non recoverable. Correct? – Limit Jan 31 '17 at 14:32
  • @Limit Correct, in this case the administrator will remove the hash from the database so the system allows the user to generate the passphrase. The system when a user logs see if there is the passphrase if it is not allows you to create it. – Sergio Jan 31 '17 at 15:05
  • But that would make the data non recoverable. Don't you think? – Limit Jan 31 '17 at 15:06
1

If you want the data to be absolutely inaccessible by administrators, then unencrypted data can never hit the servers they control. Additionally, the decryption key can't be on the server either, since if it was, a malicious administrator could grab both the encrypted data and the key, and decrypt it.

So, what options do you have?

  1. Client side encryption. If the end user encrypts data using a key which is never sent to the server, and the encrypted data is sent to your server, there is no way for the administrator to decrypt it, but the user can download and decrypt, as long as they have the key. It would be better to encrypt with a key derived from a password than from the password itself, just from a key length perspective - this is nothing uncommon though.

    The problem you have with this, if you're worried about administrators trying to access data, is that they can presumably modify the encryption code sent to the client, if you're using JS - they've got access to the server. It wouldn't be particularly hard to encrypt the data twice, once with the user key and once with a key known to the admins. You can prevent tampering in transit (that's why you've got SSL enabled), but the admin that can edit the site contents can probably edit any checksums used to preserve the integrity of the client side code too.

  2. Require that the user encrypts before sending. If the end user uses a third party encryption application, your admins can't do anything about it, other than brute force, which should be difficult. However, it does reduce your service to a file store, which might not be acceptable.

  3. Spread the risk. Have a server which serves the encryption routines to the client, which is managed by company A. Have a server which receives encrypted data and stores it, which is managed by company B. Have the rest of the web application on a server managed by company C. End user receives encryption code from server A, which is presumably unmodified, since the admins of that server never see the encrypted data, and can't modify the code without breaking checksums which are served from server C. Their computer encrypts with the client side key (which is never sent anywhere), and sends the data to server B.

    The admins from A can't tamper with the encryption, or where the data is sent unless they collaborate with the admins from C. The admins from C can modify where the data is sent, or send incorrect encryption routines, but B can report if they're not getting any data. The admins from B would have to get either admins from C to pass them the key, or the admins from A to modify encryption routines to gain access.

    Now, this seems like a very complicated scenario, but that just shows how much power the server admins have - by definition, they've got access to read and modify pretty much anything.

You basically get into a trade off between ease of maintenance and security - option 1 is easy to maintain, since you have full control of the server from a single point. Option 3 is difficult, since you have to co-ordinate any changes between multiple administrators, but makes it really difficult for any individual one to get hold of the data. Whether it's worth that effort depends on the data being stored.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.