These are the Most Common Encryption Mistakes

In this modern age, some truly powerful internet security tools help us stay anonymous, private and keep powerful entities from prying into our business. Whether you are a user or the provider of a service, you should demand the best tools available.

Modern digital encryption is one of the pillars upon which the modern web is built. We rely on it for almost anything of importance on the web. It's become a robust, fast and effective way to minimize fraud and breaches of trust on the internet.

However, a tool like this is only as good as the person wielding it. The finest scalpel in the world might as well be a butcher's knife in the hands of an accountant, for example. Encryption too can be used incorrectly. There are various ways a mistake can compromise the security and benefits of encryption technology. Users should know about these issues so that they can hold providers to account. Providers should know about them because they shouldn't make these mistakes in the first place. Here are some of the most common encryption mistakes.

Rolling Your Own Algorithm

I'm going to let you in on a little secret: I have no idea how modern encryption algorithms actually work. I don't mean the general principles; those are just fine. I mean the low-down, dirty details of the mathematics that makes it all possible. It's not just because I barely scraped through high school algebra either. Cryptography is an incredibly complex field, and some of the very brightest people in the world are responsible for the industry-standard strong encryption technology widely used today.

Which means I'm 99.9% sure that your own cipher is probably not going to be better than the best, readily available encryption today.

If you are capable of doing it better, well, then you already know it and will probably make a fortune licensing the technology. From a consumer point of view, don't use a service that uses custom encryption as a rule.

Avoiding Zero-Effort Encryption

There are plenty of situations on the web where implementing basic encryption takes little or no effort, yet for some reason, the company or person in question doesn't bother switching it on.

The two most common examples are plain HTTP and FTP. The protocols we use for websites and file transfers respectively. Both of these have "secure encrypted versions" known as HTTPS and SFTP. Quite frankly HTTPS and SFTP should be standard these days. Browsers like Chrome and Firefox will warn you if a site is not using HTTPS right in the address bar.

In the case of HTTPS, the Electronic Frontier Foundation offers a browser extension called HTTPS Everywhere. This provides encryption to sites that have not implemented it. It's at best a band-aid and if you're running any sort of website you have no excuse for not implementing it.

Using Obsolete Encryption

Despite encryption algorithms being the product of incredibly smart people, eventually, someone will figure out a way to defeat them. It's not just "bad guys" who are trying to do this either. Security researchers are constantly looking for vulnerabilities in encryption so that they can help fix the problem before it is discovered in the wild.

Our internet routers are a good example. The current standard for encrypting the WiFi signal between your device and router is WPA2. Before this, we had WEP and WPA. Both of these are less secure and considered obsolete. They are included in modern routers in cases where there are compatibility issues, but cracking WEP is trivial these days.

Similarly, DES or Data Encryption Standard has been thoroughly cracked since the 90s. Now we have AES or Advanced Encryption Standard. Although there have been theoretical attacks developed to crack AES, there are no practical ways of doing it. So right now this is the gold standard. Although the KRACK attack warrants serious concerns.

In short, don't use encryption that has a practical crack available.

Not Using the Right Expertise

Coders are very smart people. They are amazing problem solvers and one of the most valuable resources we have in this digital world. That does not mean they know how to set up encryption properly with all the checks, balances, and fail-safes which should be in place.

If you want to set up a site or service on the web, pay for the services of security specialists who are certified to implement encryption solutions. Let them work with your developers to craft a secure solution. This is such a mission-critical aspect of any web service that you need to get it right. Too many companies with data breaches have had to admit that they didn't have the expertise to implement their data security correctly.

Doing Only the Minimum

There are various encryption and safety standards with lovely badges that you can slap on your site if you comply with their minimum standards. That makes your site look secure on paper and is a great marketing tool, but is it really enough? It's important not simply to stick slavishly to standards, but to get a good appraisal of your actual implementation. Security standards often don't speak to some of the specific issues mentioned on this page.

Messing Up the Configuration

Although it's easy to say that someone should use technologies like AES, it's not a fire-and-forget process. You need to choose the right algorithm for your use case. Then you need to make sure you choose the right modes and options for that algorithm. If you have a look at the configuration options for any modern encryption standard, you'll see pages of possibilities. If you don't know what they mean or when to use them, hire an expert. Misconfiguring your encryption technology may end up leaving things completely unprotected.

Not Pinning Certificates

Certificate pinning is a security measure designed to prevent so-called man-in-the-middle attacks. This type of attack happens when someone intercepts the security certificates between the two communicators. They substitute their own and can then decrypt the messages before sending them on again in an encrypted form.

Since most sites use a central authority to issue certificates, it provides a chance for hackers to compromise the process. "Root" certificate authorities are often trusted by default, but there are a lot of them, and they aren't all equally resistant to attack. If the weakest of them gets compromised, it could be used to defeat your encryption. Pinning your SSL certificate so that it only works with one of the largest, most reputable certificate authorities. Should that authority be compromised, you're still in trouble, but it reduces the odds of that happening exponentially.

Key (Mis) Management

Because a modern encryption standard like AES is basically unbreakable using brute force methods, the main target of hackers is getting their hands on the actual keys. That means you need to protect the keys that unlock the encryption of user data incredibly well. There are numerous key management bloopers sites commit and these are some of the most egregious.

Hard-coding a Key

You should never, ever build the actual decryption into something released to the public or accessible if your servers get hacked. Don't hide it in software binaries, don't try to hide it in config or system files. Hackers know these shortcuts and will go looking for exactly these sorts of mistakes. It's not an error that you can take back and once the horse has bolted closing the barn door does nothing.

Leaving the Key in the Open

Have you ever left your keys somewhere so that a friend could easily find them to look after your plants or something similar? That's a pretty big risk, right? If someone saw you doing it or found the key, they could rob you blind easily. So why would you do the same thing with your encryption key? Leaving a copy of it on your server or inside the files of an application you've created is the same thing.

What you need to do is secure the key behind multiple levels of encryption. The key itself is encrypted with a "KEK" or key encryption key. That key is stored somewhere completely different so that even if the server is hacked, there's no way to decrypt the key.

Never Changing Keys

The thing about stealing digital objects such as encryption keys is that there isn't always obvious evidence that something is wrong. The "stolen" item is still there since of course it was copied. Careful hackers can sometimes hide their footsteps by altering logs or using other tricks.

Which means that, even if you have no reason to think so, your encryption keys may have been stolen. The easiest way to have some peace of mind is to change your keys at regular intervals. That way anyone who thinks they're going to decrypt your data are in for a nasty surprise.

Reusing Keys

You might not know this, but the password you provide, whenever you log into something online, is actually a (relatively) simple encryption key. Good online services don't actually store your passwords as plain text. They use a mathematical method known as hashing to transform the password you choose as a result. When you log in, they run the hashing process on whatever you've typed and if the two hashes match you get logged in.

The number one thing you should never do is reuse the same password on multiple sites. Some sites do (stupidly) store the actual passwords, either weakly encrypted or even as plain text. When these low-security sites get hacked, the hackers will try the same email and password combinations on other sites like online mail accounts. Of course, once they have access to your email account, they can reset just about everything. Which, incidentally, is why you need two-factor authentication on at least your most critical accounts.

How does this relate to encryption keys on your server or database? Simple - people do the same thing! Whether through laziness or haste, different sets of data are encrypted using exactly the same key. It's much safer to segregate information into groupings and encrypt them with their own keys. So if one section of data is somehow compromised, the rest is still safe and sound.

Unsafe Key Transfers

Keys have to be transferred sometimes for verification purposes or any other situation where an application or service needs to use it. It's paramount that any internet channel a key it fetches from should itself be encrypted. If an application that forms part of the service caches a local copy on a disk or moves it into memory, it should also be secured. Malware on the device in question, for example, could make copies of unsecured keys and send them back to the author of the malicious software. Carefully consider the paths that your precious keys will travel and fill any security holes.

Failing to Create a Data Recovery Plan

While we are so focused on keeping the bad guys from getting their eyes on precious data, we shouldn't forget that we can lock ourselves out as well!

In other words, if you lost your encryption keys, you yourself will never get access to your data again. There must be a clear data recovery plan for the eventuality that a key person or system fails. Losing the ability to decrypt your own data is no different from losing it entirely. You have been warned!

Failure to Test

So you've done all the things you are supposed to do when it comes to encryption. The right people have audited your settings, configuration and all the technical issues on the checklist. You're ready to roll, right? Not quite, my friends. There is no substitute for actual testing of a security system. It's a good idea to use penetration testers and the services of white hat hackers who will try to break into your system using the best tricks of the trade.

Only after you have genuinely kicked the tires on your overall system with encryption in place can you begin to hold the opinion that you built something secure.

Proceed with Caution

There are some things you can get right through trial and error. You can build it, it fails and then you learn from your mistakes and build it better then next time.

Then there are some things you absolutely can't approach in that way. Brain surgery is certainly not learned through trial and error. At least not on a living person. Securing sensitive communications, data or anything else using encryption is also not something you get a second chance at. Once the cat is out of the back, you can't stuff it back in.

Taking care of the data you have been entrusted with is a big responsibility. Whether it's your own personal information or that of customers or anyone else. You can't afford to do this any other way than properly. These common mistakes are of course not exhaustive, but they demonstrate that there's a lot more thinking that goes into the implementation of digital encryption than at first you may think.