Encryption, buzzword, not a silver bullet for protecting data on your servers.
In order to determine how encryption fits into server data protection, consider 4 encryption components on the server side: passwords, tables, partitions and inter-tier socket communications.
In these 4 components of a application / database server encryption policy, note that some countermeasures are required (for example one-way hashes of passwords, while other such as encrypting specify table columns may or may not be relevant to a particular application).
1. Encrypted password storage
You must encrypt passwords. It’s surprising to me how many Web sites don’t bother encrypting user passwords – See cases Universal Music Portugal where e-mail addresses and clear-text passwords are dumped on Internet.
What is more surprising is the confusion between encryption and hashing.
Don’t use AES for encrypting passwords in your MySQL or Oracle or MS SQL database. You’ll end up storing the AES key somewhere in the code and an attacker or malicious insider can read the key by opening up one of your application DLLs in Notepad++ and read that key in a jiffy and breach your entire MySQL database with a single SELECT statement.
Database user passwords should be stored as MD5 hashes, so that a user (such as a DBA) who has been granted SELECT access to the table (typically called ‘users’) cannot determine the actual password. Make sure that different instances have different salts and include some additional information in the hash.
If you use MD5 encryption for client authentication, make sure that the client hashes the password with MD5 before sending the data on the network.
2. Encrypt specific database table columns
The PostgreSQL 9.1 pgcrypto module allows certain fields to be stored encrypted. This is especially useful if some of the data is sensitive for example in the case of ePHI where the Web application needs to comply with the CFR 45 Appendix A Security rule. The client software provides the decryption key and the data is decrypted on the server and then sent to the client. In most cases the client (a database driver in an MVC application such as Ruby on Rails or CakePHP or ASP.NET MVC is also a server side resource and often lives on the same physical server as the database server. This is not a bad thing.
3. Encrypt entire data partitions
Encrypting entire data partitions has its place.
On Linux, encryption can be layered on top of a file system using a ”loopback device”. This allows an entire file system partition to be encrypted on disk, and decrypted by the operating system. Many operating systems support this functionality, including Windows.
Encrypting entire partitions is a security countermeasure for physical attacks, where the entire computer is stolen. Research we did in 2007 indicated that almost 50% of large volume data breaches employed a physical attack vector (stealing a notebook at a hotel checkin desk, hijacking a truck transporting backup tapes to Iron Mountain and smash and grab jobs where thieves know the rent-a-cop walkaround schedule and break in and steal desktop computers.
On the other hand, once the volume is mounted, the data is visible.
4. Encrypt socket communications between server tiers
SSL has it’s place, although SSL is not a silver bullet countermeasure for Microsoft Windows vulnerabilities and mobile medical devices vulnerabilities as I wrote here, here and here.
SSL connections encrypt all data sent across the network: the password, the queries, and the data returned. In database client-server connections, relational database systems such as PostgreSQL allow administrators to specify which hosts can use non-encrypted connections (host) and which require SSL-encrypted connections (hostssl). Also, clients can specify that they connect to servers only via SSL. Stunnel or SSH can also be used to encrypt transmissions.
“You must encrypt passwords.”
The biggest example of why encryption is a buzzword and not a silver bullet. Rather than encrypting password, you should consider storing passwords as a hash based on both the password and something else. For example, the simplicity of the APOP command as part of the POP-3 definition is the basis of what could be used. The result of the hash and something else should be used to generate the hash that is compared to the hash stored somewhere.
This concept is touched on in the paragraph regarding database user passwords. However, since there is a known weakness in MD5 hashes where it is possible for collisions, using a hashing algorithm like Secure Hash Algorithm (SHA)-128 would be a better choice.
Using hashes rather than encrypted passwords would reveal gibberish that would hamper cryptanalysis to those thinking these are encrypted passwords.
Further, anyone who stores any private information within one or two gateways (i.e., firewalls) from the public Internet gets what they deserve. No business would put their private assets in their lobby or close to the lobby. These assets would be protected behind several layers of defenses to prevent their physical access. Why do these companies think that the electronic world is any different and store passwords within their DMZ, close to their Internet front door?
Encryption can protect data from prying eyes, but why not prevent the eyes from seeing this information to begin with? Sure, it is easier to program these systems with passwords and other information readily available for the web server. But who said that security was supposed to be easy. Making it easy for the programmers also makes it easy for the hackers. Stop taking the easy way out and think about how to mitigate the risks beyond the limits of access controls and encryption.