Security and Cryptography Mistakes You Are Probably Doing All The Time

Note: This was originally posted martinheinz.dev

There are a lot of myths and wrong assumptions about cryptography and security in general. It's common for people to misuse cryptographic primitives, assume that something is secure by default or use outdated technology/algorithms. So, let's look at some of those myths and common mistakes, so that you can avoid them in the future.

Stop Using /dev/random Already

Pretty much anybody would say that you should always use /dev/random for cryptographic purposes. Well, that's wrong. Both /dev/urandom and /dev/random are using the exact same CSPRNG. The difference between them is, that /dev/random blocks until it has enough entropy. Which is another issue - you don't want your applications to wait for entropy and design logic around possibility of /dev/random blocking, especially considering that you don't need that much entropy... All you need is about 256 bits of entropy, which you will get from /dev/urandom. If you want to delve deeper into this topic, then see article here.

Never Use AES ECB

As you surely know AES is a block cipher. It encrypts plain text in blocks of 128 bits. Alright, sounds good, so what is problem with using ECB (Electronic Code Book) mode? It uses unaltered key on every block, so if you encrypt more than 128 bits of data, your ciphertext will look something like this:

That's not much of an encryption, right? So, what should you use instead of ECB? Counter mode (CTR)! Why? Because encryption can be done in parallel and it uses IV (nonce) to get rid of the unaltered key problem, that ECB mode has. Just remember to never reuse the IV.

This is how the cipher text would look with CTR mode:

You can try it yourself with openssl:

~ $ identify gopher.png
gopher.png PNG 650x650 650x650+0+0 8-bit sRGB 38.9KB 0.000u 0:00.000  # Note the dimensions
~ $ convert -depth 32 gopher.png gopher.rgba
~ $ openssl enc -aes-128-ecb -e -in gopher.rgba -out gopher-ecb.rgba -k toomanysecrets  # Replace ecb with other modes too (e.g. ctr)
~ $ convert -size 650x650 -depth 32 gopher-ecb.rgba gopher-ecb.png

Never Use MD5 For Anything, Ever

While we are on the topic of never using stuff... Forget about MD5, like, right now. It was designed for use as a secure cryptographic hash algorithm, but there is nothing secure about it at this point. It has collision vulnerability, where you can create a pair of files that have same MD5 hash, meaning that you can fake a SSL or CA certificates.
So, what to use instead? It depends on use case - for password hashing use bcrypt or scrypt. Which one of those you use, is in my opinion personal preference - scrypt was designed to be "better" than bcrypt but it's newer so it faced less scrutiny. I - personally - still use bcrypt. As for the other use cases, use hash function from SHA-2 family, preferably longer digests like SHA-512.

Always Encrypt-then-MAC

The title of this section says "Encrypt-then-MAC", but let's backtrack a little bit first. A lot of people don't realize that they should always use encryption in conjunction with message authentication. I don't want to go into too much detail about why you should actually authenticate messages, all I'm gonna say is that if you don't authenticate messages, then you are opening your applications to quite a few possible attacks, like replay attack or active attack.

With that out of the way, why encrypt-then-MAC? Simply put, it's only way to get provable security, which isn't always necessary, but it means that it's essentially impossible to mess up cryptographically when using this construction.

If you want more in-depth explanation, then I recommend article here by Colin Percival.

Special Characters Don't Make Your Passwords Good

Not necessarily at least. Good password is one that you can remember, so throwing in characters like !@#$%^&* will make it more likely that you or users of your application will either forget it or write it down somewhere where someone else can see it.

What is reason to add special characters to password in the first place? It's entropy, so if we don't want to force users to include special characters in their passwords, then what is the alternative to keep the entropy high enough?

Make it loooong. As shown in popular xkcd Password Strength comic, it makes more sense to use password made by concatenating few random words, than trying to remember some gibberish. Creating these kinds of passwords satisfies both human and computer aspect of it, in other words it's easy to remember and reasonably hard to guess (high entropy, no way to brute force it).

Note: In ideal world everybody would use password manager and generate their random super high entropy passwords, but that's not something we can expect of average, non-tech savvy user.

Encryption Keys Rotation Misconception

Somebody probably already told you, that you should rotate your keys at some time interval and that's right, you absolutely should do that. A lot of people though, think that they should do it to decrease the probability of key being broken, which is not the case for encryption keys. You should rotate encryption keys to reduce the amount of data encrypted by the key, to lower the potential damage caused by single key being compromised. This misconception doesn't change the fact that you should rotate keys, but it's important to know why you are doing it, so that you can correctly assess what intervals should be used.

Never Store User Passwords

Back to the "never do stuff" topic once more. This one is little bit of rant, I've seen so many times, that website send me password by email after I registered... like... first thing you should do when you get password from user is to hash it and throw away the clear text version of password and if you are sending it to me by email, then you are clearly not doing that (end of rant)!

So, let's take a deep breath... how to store those passwords then?

As soon as you receive the password from user - hash it with slow hash function like bcrypt using work factor of at least 12 and erase the clear text password from memory. The work factor of 12 is valid now, at the time of posting and will not be enough a year from now. I would personally shoot for up to 400ms for validation of password, you can check on your machine which work factor would give you that.

If you're not gonna use bcrypt make sure to add salt to password to prevent precomputation attacks like rainbow table attack.

Containers Aren't Secure

A lot of people think that Docker containers are secure by default, but that's not the case. They were built to solve deployment problems not security ones.

There are even vulnerabilities that would allow attacker to get root access to host system and all that is needed is shell access to container. So, how to avoid these security problems and vulnerabilities?

• Use minimal base images to reduce attack surface - Example of these images are alpine-based images or Red Hat universal base images.
• Install only necessary libraries - The less you have in the container, the lower is chance, that there will be something to exploit.
• Use trusted images - Don't just download any image from Docker Hub. Use ones that are reviewed, maintained by trustworthy teams and have lots of downloads (lots of eyes on them).
• Don't use latest tags - By using fixed tags you make sure that no vulnerabilities will get introduced with your next build.
• Use the least privileged user (Never run under root) - It is a good practice end your Dockerfiles with USER 1001 command to make sure that you use user with no privileges that could open your container to extra vulnerabilities.

There are much more things that you could do to secure your images, which you can google later, but I think the list above is bare minimum that everybody should have in mind when using Docker images/containers.

Conclusion

Every software developer/DevOps engineer is responsible for security of applications and system, at least to some extent (whether you like it or not). Therefore, I believe that all of us should take little bit of time to do the necessary research to make sure to avoid stupid mistakes and misconceptions like the ones above.

Don't just trust what people tell you (people make mistakes all the time). When it comes to security and cryptography look things up and check it yourself - make decisions based on facts.