If there is one technology that can alleviate the impact of security breaches, it’s encryption — but you have to do it right
Encryption should be at the heart of every product or service that stores any kind of customer data. Several other security measures are necessary too, but when they fail — as often they do — you would want your customer data to be encrypted. It’s that simple.
Most symmetric encryption schemes have three inputs: the data being encrypted, a randomly generated IV (initialization vector), and finally, the encryption key itself. The IV itself need not be a secret, but you need to make sure it is randomly generated. The key of course must be kept secret. However, in many encryption implementations, the cryptography and the key protection are woefully inadequate.
Here are some of the top mistakes developers make when encrypting data.
Mistake No. 1: Keys are not protected
I’ve seen a number of cases where the key is simply hard coded in the source code — bad idea! In other cases, I’ve seen instances where the key is thrown into a separate properties file — again, bad idea. A copy of the offending source code is all that’s needed for someone to get hold of these keys.
Another common mistake is to colocate the keys on the same server as the data itself. This means once the attacker has access to the server, he has access to keys as well as the data. Make sure there are enough degrees of separation between keys and data.
Symmetric crypto algorithms (like AES) depend on one simple fact: keys being kept secret. Don’t jeopardize your data by failing to protect your keys.
Mistake No. 2: Keystore is not protected
A keystore is a specialized file meant for storing keys (similar to Keychain in OS X). It can be used to store both asymmetric and symmetric keys.
If you are using a keystore (as opposed to hard coding keys as explained earlier), you are already doing better. The keystore file allows setting up of passphrases for the keystore itself and for individual keys stored in the keystore. Some keystores come with a default password (say, “changeit” or “changeme”) — change these passwords. Use strong passphrases to protect the keystore, and use every method made available by your OS to put access controls against this file. This is to ensure that the keystore file is not accessible to the attacker. Once the keystore file is accessible to the attacker, he is likely to download it and attempt to brute force the passphrase and steal the keys.
Mistake No. 3: Custom or weak crypto
Don’t invent your own crypto or use existing ones in nonstandard ways. Also, don’t use crypto well past its heyday (for example, DES). Go with key lengths that make sense for your use case.
Peer reviews are a good idea for any code, but they are a must for crypto code. Find an expert, and get them to do a close examination. Even if all you’re doing is standard encryption and decryption, additional sets of eyes are essential. (All the libraries have their own idiosyncrasies.) At SecureDB, we are done with a couple of rounds of peer reviews already, and more code reviews are on the way.
Everyone makes mistakes, even very good programmers. It’s nothing to be ashamed of. But get your crypto code reviewed.
Mistake No. 4: Old libraries
We all use one library or another to implement crypto: OpenSSL, Bouncy Castle, libraries built into Java or C#, and so on. Your OS may come with a specific version of the library. The tendency is to use the version that’s built in. However, easiest is not usually best.
Each year, new attacks are discovered against both crypto algorithms and their implementations. Keeping your library up to date helps ensure that you are protected from these attacks. When it comes to crypto, leave nothing to chance. Make a note of the version number and check to see if any newer versions are available.
Mistake No. 5: One key for everything
It’s not unusual to find one key being used to encrypt all the data. For example, I’ve seen developers encrypt five fields (columns) of a database using the same key. Though this is generally OK, there is no reason not to encrypt those columns using separate keys. Your key management overhead for managing one key and five keys is pretty much the same. You may as well use a different key for each column. Anything you can do to make life harder for attackers is a good development.
It is also not good to use the same key for different functions. Do not use the same key for both AES encryption and HMAC (hash message authentication code), for example. If you ever need multiple keys based on the same secret, you can always use a key derivation method.
Keys to better encryption
When valuable customer data is at stake, it’s worthwhile to put in the required effort to ensure that a foolproof encryption system is in place. Encryption should be indecipherable and impossible to break for hackers. But building this can pose a significant challenge to app developers.
To help developers, SecureDB has built easy and affordable APIs that offer enterprise-grade encryption as a service. Using these APIs, developers can enable encryption — complete with key management, high performance, low latency, security analytics, and backups — in a matter of minutes.
For developers implementing their own encryption, the devil is in every detail. Be sure to use the latest libraries, protect those keys and keyfiles, and most important, get your crypto code reviewed. It’s far better that a team member or consultant find the weakness in your cryptography than an attacker.