You can try it yourself with openssl :

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 the same MD5 hash, meaning that you can fake an SSL or CA certificate. So, what should you use instead? It depends on the 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 the 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 a more in-depth explanation, then I recommend the article here by Colin Percival.

Special Characters Don’t Make Your Passwords Good

Not necessarily, at least. A 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 the 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 a 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 an ideal world, everybody would use a password manager and generate their random super high entropy passwords, but that’s not something we can expect of the 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 a 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 a little bit of a rant, I’ve seen so many times, that a website sent me a password by email after I registered… like… first thing you should do when you get a password from a user is to hash it and throw away the clear text version of the 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.

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 an attacker to get root access to the host system and all that is needed is shell access to the 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.

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

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 to end your Dockerfiles with USER 1001 command to make sure that you use a user with no privileges that could open your container to extra vulnerabilities.

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

Conclusion

Every software developer/DevOps engineer is responsible for the 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 a 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.

Note: This was originally posted at martinheinz.dev