2

I help maintain a webserver that users use. They store data on our server. Most of the data is not sensitive, but some of it is highly sensitive. So, it seems like we want to encrypt it so that if someone compromises our server, they will only find encrypted data. However, to serve up the data to users on the website, the code is essentially like (pseudocode)

encryptedFile=getEncryptedFile();
decryptedFile=decrypt(encryptedFile);
serve up decrypted file

So, if our server is compromised, what is to stop the bad actor from finding this code and just running the decryption algorithm on their own? It seems like I am missing some step on how to prevent an attacker from finding the decryption key even if the server is compromised.

Essentially it boils down to: If I as a sysadmin creating the decryption system for the website can encrypt/decrypt files, what is to stop the hacker who compromises my server with root level access from the doing the same thing?

  • 1
    How does the decryption method get the key for decrypting the file? For example, is the decryption key stored immediately with the encrypted data, or is it on a separate subsystem, or is it derived from user input? You get different benefits depending on how the key is stored. – Nat Apr 6 '17 at 23:45
  • 1
    you shouldn't be able to decrypt them; use a pbkdf or e2e. – dandavis Apr 7 '17 at 5:05
  • Many of these sites pass the encryption key as a GET parameter. This way, neither the server (probably) nor an attacker can decrypt the data. – Awn Apr 9 '17 at 5:39
1

I don't know what decrypt() does, but you probably mean your OS-specific cryptography API. On Windows, this is protected with your account password. If the data gets downloaded or stolen, it will be much harder to read, even knowing you password. When your server is rooted, all bets are off, this just obfuscates it.

0

There's really two ways that one would encrypt all the data stored on a server:

  1. Using a backed which encrypts the data in some way, ie. Any sort of vault that locks unlocks etc. If you don't automate the unlocking, or require some sort of authentication for every call to retrieve data and if this is not automated, then you should be able to force the ability to access your data away from the server (for example if only a client key could decrypt the response then you're safe because you can't decrypt it and therefore neither can an attacker

    1. Using something like LUKS to encrypt the server. This is a similar approach to the above but the initial unlock is basically just going to be booting the server.

Ideally you would always encrypt the disks so that your data can't be compromised by anyone with access to the server.

Depending on your role in serving sensitive data (ie. Do you own it?) Then it's probably worth also forcing clients to authorise their own access by either providing the keys as part of the request or providing the keys as part of their local application in order to decrypt the data you return.

Really, except for the case where a client needs to not only authenticate to access your system, but they also need to know some other secret to decrypt the data once they retrieve it (where the decryption key is not stored on the server, but is unique to each client), if someone gets root access to the box while it's online you're pretty much able to consider all the data compromised.

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.