2021 年存储密码的最佳方式是什么？

Question

我存储密码，如果您是开发人员，那么以实际上最好的方式存储密码很容易。所以我想知道，2021年哪个最好？对我来说，调整我的代码以使其成为最好的代码很容易。

是的- 我研究并阅读了 Stack Overflow 和其他网站上的许多文章，所有这些文章都提供了最好的建议，并且我已经遵循了它，所以这个问题不会重复其他线程。

---

我目前所做的事情的高级概述：

• 使用SSL
• 使用 bcrypt 库
• 使用密码强度库
• 每次生成/存储随机的唯一盐
• 存储为 SHA3_512

这是我从读过的所有文章和主题中“学到”的智慧。

但是，就在最近，有人告诉我，实际上上述内容在 2021 年应该被认为是不安全的。虽然这个人有很好的资格，但我仍然对在对话中进行任何安全更改保持警惕，而且我不是安全专家，所以我之前想我做出改变然后我必须测试它。

而且，我想不出比 Stack Overflow 更好的地方了，我知道如果它值得的话，它会立即被切成碎片！我不是安全专家，但我问这个问题听起来很可信。

所以我带着一些惶恐的样子问，并跟随一些我相信的白痴，以下......是的，我问这个不是其他人。请找出我所提出的逻辑，然后我向您展示......哎呀！：

• 如果Users您的数据库表已被泄露，那么您存储的 SALT 也已被泄露（从我所读到的内容来看，这是普遍接受的）
• 黑客/密码破解工具非常复杂、成熟并且快速发展/适应。
• 标准的“黑客”密码数据库拥有超过 7 亿个已使用的明文密码，他们的软件创建了巧妙的变体，可以快速访问数十亿种可能的可能性。
• 标准黑客软件已经从现有受损数据库的现有字段中获取 bcrypt 和 PBKDF 衍生品的“盐”输入，因此意味着 SALT 变得无关紧要。实际上，它成为现有工具的命令行选项，它简单地描述了算法以及哪个字段是“盐”。
• 此外，这些工具现在非常复杂，它们可以快速检查具有不同“成本”值、不同 SHA 摘要排列的前 x% 密码，以确定和分析开发人员使用的实际组合（如果他们不知道）。
• 因此，这些“最新工具”非常聪明，可以使用已知的盐来尝试大量常用技术，并针对选择的“可能目标”来实际确定您是否使用了 SHA1/2/3 或长度和其他内容我真的不明白。但他们不再愚蠢，实际上他们非常非常聪明。
• 这些“工具”已经存在，并且它们相对容易使用大量命令行选项，因此它们非常容易访问，这极大地拓宽了攻击向量。

因此，使用bcrypt 或类似工具生成随机 SALT更加安全，因为工具已经发展到了这一点。盐实际上不再有任何区别，正如基本上所预期的那样。

问题 1： 以上情况是否属实？ （我个人完全不知道）

显然，推荐的 2021 年解决方案如下：

1. 不要依赖现有加密方法的内置盐功能。
2. 是的，利用现有的盐功能，但这不足以作为标准。
3. 您必须创建自己的附加 SALTS，以阻止现有的主流工具。
4. 您必须创建 2 个额外且单独的 SALTS，存储在 2 个单独的位置。
5. SALT 1：是本地存储在环境变量中或本地存储在“秘密文件”中的随机静态秘密。
6. SALT 2：是存储在数据库中的动态随机“用户盐”，并且是特定于密码的。
7. SALT 3：是您当前已经生成、存储并传递给 bcrypt 或类似的盐。
8. 然后，您创建自己的独特公式来生成最终的加密密码令牌。

分析

• 如果您的数据库已被泄露，由于本地静态机密，您将不再受到攻击。
• 如果您的本地脚本和数据库已被泄露，那么您的脚本副本将不包含攻击所需的 ENV STATIC 机密。你不再受到攻击。
• 如果您已完全受到损害，则无法利用现有的主流工具进行攻击，因为您的定制系统仍然超出了当前黑客命令行技术的范围。
• 如果您已完全受到损害，那么不良行为者将需要重新编码底层黑客工具源代码，以直接解决您的精确攻击向量，从而利用现有技术。

就像一个可能的独特盐示例：

encrypted_real_user_password = Bcrypt ( SHA3_512 ( 
SHA1_256(static_password_stored_on_server) + 
SHA2_512(plain_text_user_provided_password) + 
CRC_32  ( (static_password_stored_on_server) + (plain_text_user_provided_password) ) +
SHA3_256(dynamic_password_stored_in_DB) ))

问题 2： 我是白痴吗？ （请告诉我我是否……我知道你会的！）

综上所述

我真的不知道反应会是什么，尽量表现得友善（尽可能），我希望最终如果由此产生任何小的变化以使我的密码存储更加安全，那么这是值得的。

终于终于

按照上述方式以编程方式存储加密密码或“密码令牌”很简单。一行代码就可以按照上面的方式加密和解密密码。

但它更安全吗？

Answer 1

您的很多研究都是正确的，并且在 2021 年仍然适用，因此使用 BCrypt 仍然是安全的（它通常为每个密码生成自己的随机盐）。好的密码散列算法有 Argon2、SCrypt 和 BCrypt，它们都提供了控制必要时间的成本因素。

但也存在一些误解。

1. 盐并没有过时，即使你可以将它喂给饼干工具。由于每个密码都有其独特的盐，因此该工具只会破解这一个密码，并且必须对其他密码重复该工作，而不是一次性找到所有密码。
2. 只要密码哈希函数正确使用系统的随机源来创建唯一的随机盐，就没有已知的盐。对所有可能的盐进行预先计算是绝对不可能的。
3. 最好让密码哈希函数创建盐（而不是创建您自己的），因为这些库有望正确地从操作系统的随机源读取。

散列后可以进行额外的加密，这甚至是比使用胡椒更好的选择。我试图在关于安全存储密码的教程的末尾解释它。

Answer 2

您自己的密码

如果我们谈论的是我们自己的密码，那么存储密码的最佳方法就是记住它，而不是把它写在任何地方，无论是在密码管理器中、纸上还是其他地方。

如果您必须以数字方式或纸质形式存储密码，那么我会在存储密码之前使用私人密码 - 例如书本密码。

如果您的密码存储被黑客入侵，包含密码的秘密笔记本被盗等等，那么小偷仍然不知道真正的密码，也不知道用于加密它的书。

别人的密码

如果我们谈论的是其他人的密码，那么您应该只存储一个无法逆转的加密版本，并且要求密码足够长，需要很长时间才能暴力破解并将每个密码的盐存储在另一个密码上，更安全的服务器。您选择的密码加密算法永远不应该是可逆的。

最佳情况下，您应该将身份验证过程外包给值得信赖的供应商，而不是自己存储任何加密密码、盐或种子。