Is it generally a bad idea to encrypt database fields?
I work on a tiny company, it's literally me (the programmer) and the owner. The owner has asked me to encrypt several fields in a database to protect the customers data. This is a web application that helps law firms manage their data, so basically it stores persons and lawsuits information (who is being sued, why, for how much). He considers this sensitive information that should not be easily seen. His fear is "I don't want unauthorized people to see this information". Only other law firms could be interested in this data, so this shouldn't be as important as credit cards, for example.
I've read a lot about this on the web and I was thinking on simply using symmetric encryption on these fields, so that the performance isn't that bad. The key would be stored on the server. However, this thread on stackoverflow says this is a bad idea.
I don't understand how encrypting the fields and saving the key on server can be so useless. I don't fear the discs being stolen because they are on Amazon EC2. I'm no security expert, but in my opinion, if anything could go wrong, I'd say the database leaks. Even then, the important information would be encrypted. Now if the guy managed to even hack to my EC2 server, well, I guess then there would be little to no protection I could do to help this. As we are a tiny company, we only have one server doing everything, from serving the pages to storing the data.
My question is, considering we can only afford one server, is encrypting those fields with a symmetric key, which is saved on this server, ok?
"_He considers this sensitive information that should not be easily seen._" seen by who? Who should have access to this data? What is the threat model?
sorry, to clarify, he means people that can hack the system and gain illegal access to the system.
Have a look at: https://zerodb.com/ and https://en.wikipedia.org/wiki/Homomorphic_encryption
This is an old one, but I would like to add that you would do well with separating the encryption/decryption mechanism and the keys with the actual database for additional security. Also while encryption of sensitive data in a database, such as passwords does not solve all problems - its in some ways a basic requirement for decent security looking at the number of disasters with unsalted passwords or clear-text passwords. Many of those could have been mitigated by separation and encryption.
General comments. It sounds like it would be helpful for you and your boss to learn some basic security concepts, before proceeding. Security is a specialized field. You wouldn't ask a random person on the street to perform open-heart surgery on you; and you shouldn't expect an average software developer to know how to secure your systems.
I sense some misconceptions here. For instance, it sounds like your boss has equated security with cryptography. But this is a mistake. As Bruce Schneier has emphasized, Cryptography is not magic pixie dust that you can sprinkle on a system to make it secure. And as Roger Needham once famously said, If you think cryptography will solve your problem, either you don't understand cryptography, or you don't understand your problem.
When securing a computer system, one important concept is the threat model. This means you need to think carefully about what kinds of attacks and adversaries you are trying to stop, and what you aren't. A failure to think through the threat model clearly can lead to security theater: security mechanisms that look good on first glance, but actually are woefully inadequate in practice. Good security management often comes down to risk management: careful analysis of what are the most serious risks, and then devising strategies to mitigate or manage those particular risks.
It is also important to understand that security is a weakest-link property: the security of your system is only as strong as the weakest link. A vulnerability in any one part of the system can compromise the security of the entire system. This means that there's no one answer that's going to be sufficient to protect your system; instead, to defend your system, you have to get security right in a number of places.
Diving into details. It sounds like your goals are to prevent unauthorized disclosure of sensitive data. If so, you're going to need to focus on a number of items. There's no one simple magic silver bullet that is going to solve this for you; you are going to need to work on application security generally.
Let me suggest some things that should be priorities for you, if I've understood your goals correctly:
Application security. You need to start studying up on web application security. It doesn't matter how much crypto you throw at the problem; if an attacker can find a security hole in your application code, you are hosed. For background on web application security, OWASP has many excellent resources. Make sure you learn about the OWASP Top Ten, about XSS, SQL injection, input sanitization/validation, output escaping, whitelisting, and other concepts.
Access control. Your web application needs to have solid access controls, to ensure that one user of your system cannot access information of another user (without authorization). The details of this will depend upon the specifics of your particular system, so if you want additional help on this, you'll probably need to post a separate question with more details about your application and your current strategy for access control.
Authentication. Your web application will need a way to authenticate its users. The standard least-effort scheme is to just use a username and password. However, this has serious limitations in practice that are well-understood. If users choose their own passwords, they often choose poor passwords, and this can subvert the security of your system.
Secure software development lifecycle. You need to integrate security into the software development process. When you work out the software architecture, you should be thinking about the security requirements and performing threat modelling and architectural risk analysis. When writing code, you need to know about common implementation errors that can breach security and make sure to avoid them. After the software is built, you need to test its security and constantly evaluate how you are doing at security. When you deploy the software, your operations folks need to know how to manage it securely. Microsoft has some excellent resources on the secure software development lifecycle (SDL). See also BSIMM for more.
Security assessment. If you are concerned about security, I suggest having the security of your application assessed. A simple starting point might be to have someone perform a pentest of your web application, to check for certain kinds of common errors. This is by no means a guarantee of security, but sometimes it can help serve as a wakeup call if there are many major problems present. You might look at WhiteHat Security's services; there are also many others who will perform web pentesting.
If you are getting the sense that this is not a trivial undertaking, I apologize, but that is indeed the case. On the other hand, the good news is that there are a lot of resources out there, and moreover, you don't need to become an expert-level security guru: you just need to become familiar with some basic concepts and some common security mistakes in web programming, and that will take care of most of your needs.