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.

通常，关于加密和安全性有很多神话和错误的假设。 人们通常会滥用密码原语，默认情况下会认为某些东西是安全的，或者使用过时的技术/算法。 因此，让我们看一下其中的一些神话和常见错误，以便将来避免它们。

停止使用/dev/random (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.

几乎所有人都会说，出于加密目的，您应该始终使用/dev/random 。 好吧，那是错误的。 /dev/urandom和/dev/random都使用完全相同的CSPRNG 。 它们之间的区别是/dev/random阻塞直到它具有足够的熵为止。 这是另一个问题-您不希望您的应用程序等待/dev/random阻塞可能性的熵和设计逻辑，特别是考虑到您不需要那么多的熵...您所需要的只是256位熵，您将从/dev/urandom 。 如果您想更深入地研究该主题，请参阅此处的文章。

永远不要使用AES ECB (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 the problem with using ECB (Electronic Code Book) mode? It uses an unaltered key on every block, so if you encrypt more than 128 bits of data, your ciphertext will look something like this:

如您所知， AES是分组密码。 它以128位为块加密纯文本。 好吧，听起来不错，那么使用ECB(电子密码簿)模式有什么问题？ 它在每个块上使用未更改的密钥，因此，如果您对128位以上的数据进行加密，则密文将如下所示：

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.

那不是很多加密，对吗？ 那么，您应该使用什么代替ECB ？ 计数器模式(CTR)！ 为什么？ 因为加密可以并行完成，并且它使用IV (即刻)来消除ECB模式具有的不变密钥问题 。 只记得永远不要重复使用IV 。

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

这是在CTR模式下密文的外观：

You can try it yourself with openssl:

您可以使用 openssl 自己尝试 ：

绝不将MD5用于任何用途 (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.

当我们讨论从不使用任何东西的话题时……马上就忘掉MD5 。 它被设计为用作安全的密码哈希算法，但是目前还没有安全的方法。 它具有冲突漏洞，您可以在其中创建一对具有相同MD5哈希的文件，这意味着您可以伪造SSL或CA证书。 那么，您应该使用什么呢？ 这取决于用例-对于密码哈希，请使用bcrypt或scrypt 。 在我看来，您使用哪一种是个人喜好scrypt设计要比bcrypt “更好” ，但是它较新，因此受到的审查较少。 我-个人-仍然使用bcrypt 。 至于其他用例，请使用SHA-2系列的哈希函数，最好使用较长的摘要(如SHA-512) 。

始终加密然后MAC (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.

本部分的标题为“ Encrypt-then-MAC” ，但让我们先回溯一下。 许多人没有意识到他们应该始终将加密与消息身份验证结合使用。 我不想过多地说明为什么您实际上应该对消息进行身份验证，我要说的是，如果您不对消息进行身份验证，那么您将使应用程序面临相当多的可能的攻击，例如重播攻击或主动攻击 。

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.

有了这种方式，为什么要加密然后使用MAC ？ 简而言之，这是获得可证明的安全性的唯一方法，但这并非总是必要的，但这意味着使用此结构时，基本上不可能以密码方式弄乱。

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

如果您想要更深入的解释，那么我建议您在这里发表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).

放开它。 如流行的xkcd密码强度漫画中所示 ，使用通过连接几个随机单词而制成的密码比尝试记住一些乱码更有意义。 创建这些类型的密码既可以满足人类的要求，也可以满足计算机的要求，换句话说，它很容易记住，而且很难猜测(高熵，无法强行使用)。

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)!

再次回到“永不做事”主题。 我已经看过很多次了，这很麻烦，以至于我注册后某个网站通过电子邮件向我发送了密码……就像……当从用户那里获得密码时，您应该做的第一件事就是对它进行哈希处理并丢弃密码的明文版本，如果您通过电子邮件将其发送给我，那么您显然没有这样做( 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.

收到用户的密码后，请使用工作系数至少为12的慢速散列函数(如bcrypt对其进行散列，并从内存中清除明文密码。 12的工作系数现在有效，在发布时有效，一年后还不够。 我会亲自拍摄长达400毫秒的密码验证，您可以在计算机上检查哪个工作因素会给您带来帮助。

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

如果您不打算使用bcrypt确保在密码中添加盐 ，以防止进行预计算攻击，例如彩虹表攻击 。

容器不安全 (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.

许多人认为Docker容器默认是安全的，但事实并非如此。 它们旨在解决部署问题，而不是安全问题。

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?

甚至存在一些漏洞，攻击者可以通过该漏洞获得对主机系统的root访问权限，而仅需要对容器的外壳访问即可。 那么，如何避免这些安全问题和漏洞呢？

• Use minimal base images to reduce attack surface — Example of these images are alpine-based images or Red Hat universal base images.

  使用最小的基本映像来减少攻击面 -这些映像的示例是基于alpine的映像或Red Hat 通用基本映像 。

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

  使用受信任的映像 —不要只是从Docker Hub下载任何映像。 使用由值得信赖的团队审查，维护并有大量下载内容的内容(很多关注对象)。

• Don’t use latest tags - By using fixed tags you make sure that no vulnerabilities will get introduced with your next build.

  不要使用 latest 标签 -通过使用固定标签，您可以确保下一个版本不会引入任何漏洞。

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

  使用特权最小的用户(永远不要在 root 下运行 ) -一个好的做法是使用USER 1001命令结束Dockerfiles ，以确保您使用的用户没有特权，这会使您的容器遭受更多漏洞。

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.

您还可以做很多事情来保护图像，以后可以在Google上进行搜索，但是我认为上面的列表是使用Docker图像/容器时每个人都应该记住的最低要求。

结论 (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.

每个软件开发人员/ DevOps工程师都至少在一定程度上(无论您是否喜欢)对应用程序和系统的安全性负责。 因此，我相信我们所有人都应该花一点时间来进行必要的研究，以确保避免上述愚蠢的错误和误解。

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

注意：这最初发布在 martinheinz.dev