Encryption has made itself famous lately by helping bad guys hide secrets from good guys. If the most powerful supercomputers in the world can't break the mathematical laws of encryption, how can the FBI, NSA and CIA decipher the terrorist communications they intercept?

But there's a flip-side to this question that rarely gets discussed:

If encryption is so unbreakable, why do businesses and governments keep getting hacked?

If terrorists can download an app from the app store that uses encryption to protect their chat messages from the NSA, why couldn't the US Office of Personnel Management, The Home Depot, Target, JPMorgan and Citi Bank (just to name a few) use the same encryption to protect their customer data from hackers? Why do these data breaches keep happening when unbreakable encryption is readily available?

The answer is simple: almost everyone is doing encryption wrong.

There has been an explosion of new healthcare, financial and government applications over the past few years resulting in more and more cryptography being added to backend applications. In more cases than not, this crypto code is implemented incorrectly, leaving organizations with a false sense of security that only becomes evident once they get hacked and end up in the headlines.

“But my company is different,” you might be thinking. “Our engineers are brilliant.” Unfortunately, even the brightest software developers are usually not security experts. Security experts are mostly found in IT. They're system administrators, pen testers and CISOs; they're not writing code (unless you count scripts written to break into a system).

Software developers are really good at figuring things out; just look at StackOverflow – a massive community of developers helping each other solve challenging problems. So they're not likely to admit to having limited expertise when tasked with something they haven't done before. “I can figure it out,” is a common mantra of a good software developer. I should know … I've been coding since I was eight and I say this all the time.

Unfortunately, when it comes to implementing encryption correctly—you don't get a second chance. While a typical developer mistake might cause an error on a web page, a mistake in your data security pipeline can leave all of your sensitive data at risk. Worst of all, you won't find out about the mistake for months or even years until your organization gets hacked. And by then, it's too late.

“Our application is PCI compliant. So our data is secure,” is another misconception that leads to data breaches. Sure, HIPAA, PCI, CJIS and other regulatory compliance rules require that your sensitive data be protected. But they don't go into much detail about how you should do that. Some don’t even specifically mention encryption at all.

There are a lot of ways to get data security wrong and these regulatory guidelines don't hold your hand to make sure you get it right. Even worse, many development teams adding encryption to their code call it a day once they achieve the minimum security needed for a regulatory checkmark. This “checkmark” mentality toward data security is dangerous.

With the growth of cloud computing more and more server-side applications have moved from server rooms to data centers spread across the globe run by the likes of Amazon, Microsoft and Google. These tech giants are investing hundreds of millions of dollars in cybersecurity to position themselves as “THE” secure cloud. All of this leads a lot of organizations to assume that any data stored by these providers is ironclad. This is a risky assumption.

The physical infrastructure powering most cloud providers is secure and some even offer encryption options. However, they always recommend that developers encrypt their sensitive data before storing it in the cloud. Amazon Web Services (AWS) even includes the diagram below to stress that data encryption is the customer’s responsibility, not theirs:

AWS Shared Responsibility Model (credit: AWS)

As you can see, a massive amount of data security responsibilities are shouldered upon you. And this is true of any cloud provider.

Protecting your sensitive data with low-level encryption solutions such as disk or file encryption can seem like a tempting one-click-fix. However, many organizations rely solely on these solutions which is downright dangerous.

For starters, disk encryption only kicks in when the server is turned off. While the server is on, the operating system goes about decrypting sensitive data for anyone who is logged in…including the bad guys.

Moving one level up to file encryption, you run into a popular feature called SQL Transparent Data Encryption (TDE) used to encrypt Microsoft and Oracle database files with a single click of a switch. Just like disk encryption, however, this security feature is complely bypassed by a hacker who manages to login to your database. Only the file that stores your database on the physical drive is encrypted so, unless Tom Cruise is rappelling into the data center to steal your physical drive, this isn't going to give you much protection.

Take a look at this Wikipedia list of cryptographic algorithms. Now take a look at the different block cipher modes to choose from. Here's a StackOverflow post on which mode to use with AES. Are we having fun yet??? The point is, there are a lot of variations for a developer to choose from when being asked to “encrypt our sensitive data please.”

A common question I get when telling a developer about Crypteron's encryption and key management platform is, “doesn't every application framework come with an encryption library?” Sometimes I just ask them to take a look at the documentation for mcrypt, the encryption library for PHP. Spoiler: it's not pretty. There is a lot of misleading information on the Internet and A LOT of ways to get it wrong:

• Using random numbers that are not cryptographically secure (or, in the case of the Sony PS3 hack, a constant)
• Using AES-ECB mode for data larger than 128 bits
• Reusing an Initialization Vector (IV) multiple times which can nullify the entire encryption process itself
• Using deterministic encryption to make sensitive data searchable without factoring for dictionary attacks.

These examples are just a small snapshot of the vast number of encryption pitfalls. It’s OK if you don’t understand them – most developers don’t either.

I've saved the biggest mistake for last. Failure to handle key management properly is, hands down, the most common way that sensitive data ends up in the hands of hackers even if it was encrypted correctly. This is the equivalent to buying the best lock in the world and then leaving the key under the doormat. If hackers get your encrypted data and your encryption key, it's game over. Let's go over some key management failures.

Storing the key under the mat

Let's assume that all of your sensitive data is now encrypted and signed properly. Where do you put your encryption key? Some common choices:

• In the database - BAD
• On the file system - BAD
• In an application config file - BAD

Don't forget, we have to assume that the hackers have already broken into your database and application server so you can't store your key there. But most developers do.

Leaving the key unprotected

Even once you find a separate place to store the key, you're still not done because hackers might break in there too. So you need to encrypt your encryption key itself with another encryption key, typically called a Key Encryption Key (KEK), which you then need to store in an entirely different location. For even more security, you can go one level higher and secure your KEKs with a Master Encryption Key and a Master Signing Key. Developers rarely add this many layers of encryption. But they should.

Fetching the key insecurely

Even with three layers of encryption protecting your data, there is still the challenge of transferring the key to your app securely. Ideally this involves authentication between your app and the key management server as well as delivery over an encrypted connection…a fourth layer of encryption. There are also performance considerations such as securely caching the key in memory which can be tricky. These complexities are easy to get wrong.

Using the same key for all your data

Do you use the same key for your house, your car and your office? Of course not. So why would you use one encryption key for all of your sensitive data? You should break up your data into multiple security partitions each with its own encryption key. This is a challenge since it requires you to intelligently determine which key to fetch every time you encrypt and decrypt data. So most developers skip this step.

Never changing the key

Everyone knows that it's a good idea to change the locks every once in awhile and the same is true for encryption. This is called key rotation and it's not trivial. It requires maintaining multiple versions of each encryption key and matching it to the corresponding version of encrypted data. In certain cases, you should migrate your existing data from the old key to the new key…which is even more complicated. So again, most developers skip this step entirely and never change their encryption keys.

This article isn't meant to be all doom-and-gloom. In fact, it's just the opposite. People are starting to become desensitized to all of the data breaches that keep happening. There is a new sense that getting hacked is inevitable and no data is ever safe. But that's not the case. It IS possible to perform encryption correctly and drastically decrease your chances of getting hacked. If we learn from our mistakes, educate ourselves on data security, and avoid reinventing the wheel, then encryption can be our strongest ally in the fight against hackers.

https://www.crypteron.com/blog/the-real-problem-with-encryption/ - 6 encryption mistakes that lead to data breaches