AppSec Blog

Argument for Database encryption in web apps

I regularly get consulted on various web application security issues and defensive strategies. One of the recent "frequently asked questions" is around database encryption of web application. My answers to these kind of questions usually lead to awkward looking faces. I always start off asking more questions about the requirements, "Who are you trying to protect the data from?" and "What data are you trying to protect?" The answers to those questions are usually good indicator whether the person is on the right path or not.

In most cases, database encryption does not prevent the hacker from accessing the backend database via an application compromisse. The reasoning is very simple. If the web application needs to be able to access the data for normal operation and hackers are able to compromise the application, the hackers can essentially access the same data by controlling the applicaton (attacker owns the application). Encryption does not prevent a hacker to access the backend database if the hacker can control the application.

Some may argue that if the database encryption is per user based, then one user's compromise does not lead to compromise of another user's data. That is very valid but that usually requires authentication of the user to some backend pieces (or the database itself). Maybe authentication alone is sufficient for the security requirement? The database can provide access control based on user's identity so one user's compromise does not lead to access to other user's data.

You might think I am an anti-encryption person. The fact is - I am not. Encryption totally has its place for web application security reasons. Asymmetric encryption usage to protect data that is "one way" in nature is a good example. As a retail store trying to store the user's credit card details for recurring monthly payment, the data should be encrypted with asymmetric encryption so that the Web frontend can never read the data back but another party with another related key can. Also, there are numerous other scenario where encryption should be used, such as backup, protecting against rogue DB administrators and against physical theft of database machine.

I often recommend a threat risk assessment before deciding on the database encryption solution. That would allow you to quickly understand the threats that affect the web application and also possible countermeasures that can help protect against the threat. Due to the cost of deploying and maintaining database encryption, I am seeing very limited deployment of database encryption, most folks tend to turn to other alternatives for risk mitigation.

Encryption is a useful defensive technology that can help protect the web application but it is not a silver bullet, blindly deploying it may not address any threats that you are trying to mitigate. The managers and auditors tend to request these technologies to be deployed to defend against web application compromise after seeing another competitor getting compromised thru web application security flaws (eg. SQL injection). Encryption is likely not the best choice of defensive technology given the scenario.


Posted June 25, 2009 at 1:30 PM | Permalink | Reply

Dave Ockwell-Jenner

Great post, Jason. I, too, often get similar questions around the use of the great panacea known as encryption. In most cases, I find the implementation of traditional database segmentation and access controls to be better effective at preventing unauthorized access to data.
In nearly all web applications that I review, the web application has access to much more data than is needed for the application itself; often just ''hooking in' to an existing back-end data store. Enhancing the data access controls produces a ''bigger bang for the buck' than encryption, most of the time.
I have, however, seen a fairly cool use of encryption to provide cross-user access to data'' where the data in the database is essentially encrypted with a key specific to the user to whom that data ''belongs'. Not a specific database solution in use, just some nice planning up-front in the application.

Posted June 25, 2009 at 8:41 PM | Permalink | Reply

Nathan Christiansen

I am a crypto geek.
However, I completely agree with your post. It completely depends on the data you are protecting and whom you are protecting it from to consider data-at-rest encryption.
I have also seen necessary, and good encryption done so badly that there was no real security gain (except for database backup tapes).
For example, a company does enough transactions to require Level 2 PCI-DSS compliance making it required to encrypt credit card data in the database. The encryption is done using Oracle's built-in crypto libraries using Triple-DES (AES was not available at the time). The 192-bit Triple-DES encryption is good encryption. To protect the key, they put it in a wrapped Oracle package that included the encrypt and decrypt routines. By storing the key in the database, a simple SQL injection attack could reveal the plaintext credit card numbers. Fortunately the website did not have direct access to the database. It had access through an application proxy that eliminated SQL injection as well as not passing back full versions of credit card numbers. However, the in-house developed software for call center agents had no SQL injection protections.

Posted June 26, 2009 at 2:52 PM | Permalink | Reply

Joyce Chan

This is a great article. I'm interested in finding out more resources on this topic so I can implement db security correctly. Please comment more!

Posted June 27, 2009 at 3:43 PM | Permalink | Reply


I don't think that "Fortunately" is the word that you were looking for. There are always around tools such as Web Application Firewalls'' all that I have to do is obfuscate the sql injection in a way that said proxy/firewall does not recognize the patter-based attack but sql / one of the intermediary servers does.. and voila.. bypassed.
One should never accept a poor security control in lieu of another being in-place that allows for the aforementioned to be rubbish. If it's poorly designed and the keystore mechanism is insufficient and allows access to the keys and crypto routine, then REDO it or fail the audit IMHO''
What you describe sounds like a mechanism that was put in place by a developer and not a security professional. I often even see simple obfuscation in place of true crypto and it sickens me!
Anyway, getting off of my soapbox now.

Posted July 13, 2009 at 6:30 AM | Permalink | Reply

IT Training

Good Post. This one will be of great help for candidates who have recently got certifications in web applications. I would ask my candidates to visit your blog.

Post a Comment


* Indicates a required field.