6 encryption mistakes that lead to data breaches

The REAL problem with encryption:
you're doing it wrong!

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 [1], leaving organizations with a false sense of security that only becomes evident once they get hacked and end up in the headlines.

Mistake #1: Assuming your developers are security experts

"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.

Mistake #2: Believing that regulatory compliance means you’re secure

"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.

Mistake #3: Relying on cloud providers to secure your data

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.

Mistake #4: Relying on low-level encryption

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.

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.

Mistake #6: Getting key management wrong

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.

Strong data security IS possible

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.

7 thoughts on “6 encryption mistakes that lead to data breaches”

I find the advice given here to be incomplete. There are even more sinister mistakes you can make.

Encryption provides confidentiality, but not integrity. If your application just encrypts/decrypts data with AES-CBC but doesn’t include an authenticity check, I can replay a carefully-garbled ciphertext and decrypt your message one byte at a time.

Adding integrity to your encryption routine produces something called authenticated encryption; but watch out! There’s this thing called the Cryptographic Doom Principle (CDP) if you don’t do everything properly (encrypt then authenticate).

Then you have side-channels, such as timing attacks. Even if you implement Encrypt-then-MAC to avoid the CDP, if you aren’t comparing the message authentication codes in constant-time, an attacker can slowly build a valid MAC for their chosen ciphertext without knowing the HMAC key. This allows them to (albeit much more slowly) continue to exploit the padding oracle vulnerability alluded to above (the byte-at-a-time decryption).

Then you have to consider birthday attacks against random IVs, weak random number generators (such as OpenSSL’s non-thread-safe userland PRNG), cache-timing attacks against software AES, and a million other ways for a seemingly secure cryptosystem to provide zero security against a dedicated attacker.

Yaron Guezsays:

Hi Scott!
Thanks for commenting. I’m a fan of your Paragon Initiative blog. The confidentiality vs integrity issue is definitely an important distinction. Unfortunately, given the length of the article I decided to bundle that distinction into Mistake #5 since it involves using a mode that doesn’t offer authentication / tamper protection.

Sure Joel. First – the mandatory warning 😉 … we caution that until you’ve mastered the materials and have experimented by implemented a few security platforms, do not implement one for production use, securing data of any value. This is because there are many subtle things that weaken security. Simplified example: using an equality comparator (==) instead of a constant-time equality comparator (custom implementation) can weaken good cryptography. There are many other cases and you’re aware of all these only with sufficient mastery and experience. Even then implementations can have issues, requiring ongoing updates. (e.g. OpenSSL and Heartbleed).

With that disclaimer, here are some books, in order of recommendation:

If you’ve been put off by dense Math equations before, note that mathematical intuition can often take you far in understanding existing ciphers. Of course, when creating ciphers and proving their security, one does need deep math expertise and solid current experience. Happy reading.

Jeff Daviessays:

And the problem with the Verisign type approach where you have asymmetric encryption giving authentication to Organisational Root Certifiers and so no, is the problem that if a key is compromised, re-establishing trust is very expensive since most systems are not built with this possibility in mind.
The likelihood of an Organisational root certifier private key being broken is lower now that keys are so much longer, meaning brute forcing with custom hardware like ASICs is probably harder.
One Time Pad, patented in 1917 is the only secure way to exchange very important secrets. Better with a perfect random number generator. I’m actually quite heartened to see products like Yubico: https://www.yubico.com/ (I have no relationship of experience with them). Because it’s based on OTP, even if Yubiko usb key was intercepted and the codes extracted, unless the next yubico key is also intercepted, then trust is re-established. Note there is a client usb-key and server usb-key and the keystore code is run on a seperate microcontroller on the usb key by the looks of it.

anonymoussays:

Megan, Dsays:

Great read, but one suggestion. You failed to mention FPE or format preserving encryption. Using FPE, you can encrypt sensitive information, even while in use. So even a user that presented valid credentials would only see protected data.

This is the future of encryption. It allows for the adoption of a “least privilege” model. While not all data can be protected this way, the sensitive information (the stuff you read about being stolen) can be. Data at Rest is still important but you said it yourself, the chances of disk or complete array walking out of your data center are limited.

Recent blog posts

There is no secure perimeter anymore. Neither in your corporate network nor in your data center. Fight a winning battle armed with self-protecting data rather than a losing one trying to protecting the infrastructure.