Security and Cryptography Mistakes You Are Probably Doing All The Time
Tags: security, docker, cryptography, devops
Published: 2019-12-13 16:25:35

_Note: This was originally posted [martinheinz.dev](https://martinheinz.dev/blog/12)_

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](https://www.2uo.de/myths-about-urandom).

## 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:

<table><tr>
    <td> <img src="https://res.cloudinary.com/martinheinz/image/upload/v1575807287/blog_posts/gopher_ijkz2l.png" style="width: 250px;"/> </td>
    <td> <img src="https://res.cloudinary.com/martinheinz/image/upload/v1575807287/blog_posts/gopher-ecb_hqfxsi.png" style="width: 250px;"/> </td>
    </tr></table>
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:

<table><tr>
    <td> <img src="https://res.cloudinary.com/martinheinz/image/upload/v1575807287/blog_posts/gopher_ijkz2l.png" style="width: 250px;"/> </td>
    <td> <img src="https://res.cloudinary.com/martinheinz/image/upload/v1575807288/blog_posts/gopher-ctr_sktjkd.png" style="width: 250px;"/> </td>
    </tr></table>

_You can try it yourself with `openssl`:_

```shell
~ $ 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](https://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html) 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](https://xkcd.com/936/), 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.