18

I am encrypting and decrypting my database data from my web applications API. If my web server is compromised, what is to keep someone from using that same method to retrieve the data?

For example, say I have a PHP application on my web server that does the database encryption/decryption. If the web server is compromised, what prevents someone from having access to the key and decrypting the data.

The problem isn't language specific, the problem is storing a key that the web application can use but still be secure from someone who has administrative access to the server.

Improve this question
1
  • Could you please edit your question, it is bit unclear. Can't understand the meaning of "what is to keep". Also what is "that same method" - encryption algorithm?
    – anonymous
    Nov 19, 2010 at 22:03

5 Answers 5

Reset to default
5

When I've done this I've moved the encryption away from the web server altogether. Basically I've had the following scenario

  • A database server which stores the encrypted data
  • A web server which runs the application and stores/retrieves encrypted data
  • A crypto server which performs the encryption and decryption and which is locked down

Basically the web server calls a web service on the crypto server, which is only available on an internal network and says "Here's some data, and the type of the data". The crypto server makes a decision on key size, key expiry etc. based on the type of the data, encrypts it with a new symmetric key and salt and passes back a binary blob plus a key identifier. The crypto server then stores the key in it's own SQL database, but protects it with an X509 cert first, which only the crypto service has access to - so if you manage to access the database remotely it's useless as you'd still need OS access to get the X509 cert to decrypt the keys, and in any case the data is held elsewhere.

The crypto server admin passwords are held in a the "break box" where it takes two separate people to combine their parts to get the password.

This means developers don't have to worry about what algorithms to use, or secure key storage as it's taken care of by the crypto server, and you can update the algorithms used as your process changes or new rules come out without having to update anything other than the crypto server. Only the process running the web application can call the crypto server, normal user accounts, or even administrator accounts cannot. Database administrators who can see the web database only see encrypted data and cannot access the keys either.

Even if the web server is compromised it's still limited in what it can do, call the crypto server to get keys, and then call the data storage database to get the data the keys refer to. Hard to do if the compromise is just the ability to run arbitrary code, without knowing how these things happen or where the servers lie on the internal network.

Of course if the compromise is a rooting, and the attacker can grab your code and impersonate processes, well all bets are off - but that's always going to be the case.

Improve this answer
1
  • Note that this is potentially vulnerable to confused deputy attack. If the web server is compromised or the admin untrustworthy, the attacker can still use the crypto server to encrypt/decrypt anything. The only remedy here is that you can make auditable log record of all encryption/decryption event in the cryptoserver.
    – Lie Ryan
    Dec 6, 2016 at 2:00
7

The answers here are good (both @blowdart and @Tate), but the important thing to take into account, is that if your website is compromised, it's gameover as far as security is concerned - you've been pwned.

The malicious takeover code can do any thing your site can, including accessing your code, running process, database, etc. That means, no matter how you do your encryption, no matter where you put your key, they can get to it and decrypt your data too. Whatever you try, its just obscurity, at best - and worst case, they can just let YOUR code do the hard decryption work and just intercept it afterwards.

Improve this answer
5

The best resource available in my opinion right now regarding all things database security is Securosis' paper:

Understanding and Selecting a Database Encryption or Tokenization Solution
This paper includes descriptions of major database encryption and tokenization technologies, a decision tree to help determine which type of encryption is best for you, and example use cases drawn from real world deployments. If you are considering any database encryption or tokenization project, this paper should save you hours of research and architecture development time.

http://securosis.com/research/publication/understanding-and-selecting-a-database-encryption-or-tokenization-solution/

Direct link to PDF: http://securosis.com/reports/Securosis_Understanding_DBEncryption.V_.1_.pdf

Improve this answer
1
2

First, this is an extremely tough problem. The basic issue is that if your web application has sufficient knowledge to decrypt the data, then if it is hijacked it will have sufficient information to decrypt the data. You really have to start there. This means a couple things.

  1. If you trust your application to decrypt the data, then if it is taken over, it can decrypt all the data.

  2. If you do not trust your application to decrypt the data, then it is probably going to be trusted with some set of plain text.

One option is to have a service between your application and the database which handles the encryption and decryption. This can be designed so that two people need to work together to store the keys in memory, but even if that is not the case, you still get some defence in depth. If your web application is taken over, it only gets access to what the decryption service can get it, and so mitigation can be a part of that strategy. An attacker then would have to compromise your decryption/encryption service for access to raw data (defence in depth at work).

(To be honest, I tend merge this encryption/decryption service with the database, but books could be written on how to do this securely for any given RDBMS and it is not a simple solution.)

Improve this answer
1

Pretty good answers on this thread. This basically comes to two main issues namely the encryption method as well as the encryption key storage.

I have worked for a DB encryption vendor and worked on a number of similar projects deploying our solution D'Amo. We usually encrypted data at the DB level depending on the DB type but in a case like this one we install an encryption/decryption Security Agent(module) on the web server which can be monitored remotely to configure enc/dec policies to be followed during operation.

Our general advice is to store the keys in a separate, dedicated Key Management Server(KMS) which we could also provide.Some customers even took an extra step to ask us or buy from a 3rd party company a Hardware Security Module (HSM) for key management. Since our solution is column based, there were different keys for each encrypted column. Also the communication between the Security Agent and the KMS needs to be secured to avoid MITM attack when the Security Agent is getting the keys from the KMS.

Disclosure: I am an engineer at Penta Security Systems Inc.

Improve this answer
1
  • Just a note, Stack Exchange requires that you disclose your affiliation when posting links to something you call "our". i.e. it requires to add a note like: "Note: I work for pentasecurity.com". If SE would not do that it would be full of spam :)
    – grochmal
    Dec 6, 2016 at 1:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .