使用 Rfc2898DeriveBytes 从明文密码创建安全密码时盐的重要性答案

【问题标题】：Importance of salt when using Rfc2898DeriveBytes to create secure passwords from clear text passwords使用 Rfc2898DeriveBytes 从明文密码创建安全密码时盐的重要性
【发布时间】：2013-12-30 01:52:26
【问题描述】：

我想在我的一个 C# .NET 应用程序中合并文件的加密和解密。场景很简单：用户 A 向用户 B 发送一个 AES256 加密文件。明文密码在不同的渠道（例如电话或其他）上交换。

据我了解，我应该使用 Rfc2898DeriveBytes 将用户的明文密码转换为更安全的密码，大约需要 10,000 轮。（见this article）。

我不明白盐在我的场景中的作用。通常盐用于散列密码以防止字典攻击。但在我的场景中，PBKDF2 算法用于通过添加 PBKDF2 轮次所需的额外计算来弥补简短或易于猜测的明文密码的弱点。

如果我选择随机盐，那么接收者也需要知道该盐才能正确解密。如果我使用常量盐，那么黑客可以轻松地对我的代码进行逆向工程并使用我的常量盐进行暴力攻击（尽管由于 PBKDF2 迭代它们会非常慢）。

据我了解，我别无选择，只能在我的场景中使用常量盐并强制执行良好的明文密码规则来弥补常量盐的弱点。我的假设正确吗？

【问题讨论】：

标签： security encryption passwords cryptography salt

【解决方案1】：

在密码散列（和密钥派生）的上下文中，盐用于防止预计算攻击，如彩虹表。

请注意，每个密码的盐值必须不同且不可预测（最好是随机的）。另请注意，盐不必保密——这就是密码的用途。保守盐的秘密不会获得安全性。

在您的情况下，推荐的方法是每次加密文件时生成一个随机盐，并将盐与密文一起传输。

顺便说一句，您使用 AES-256 是否有特定原因？由于额外的回合，它比 AES-128 慢 40% 左右，并且它没有提供实际的安全优势（尤其是在基于密码的加密的情况下）。

也值得考虑使用像PGP 这样的成熟标准，而不是从加密原语构建自己的协议，因为构建安全协议非常困难，即使专家也不一定能做到。

【讨论】：

应该有 AES 的随机 IV（我假设他使用的是 ECB 以外的不安全模式）。 Salt 正在阻止使用彩虹表从哈希中获取密码，但在这种情况下攻击者无法获取此哈希，因为它仅用作加密的密钥。
@MaciejS 攻击者可以从常用密码中预先计算出大量密钥，并针对任意数量的消息使用该表，而无需做进一步的工作。
正确使用的盐可以防止多目标攻击，而不仅仅是预计算。不可预测的盐也不是那么重要。
@user3092904 “如果我使用 .NET 框架中的 RijndaelManaged 会出现什么问题” 仅仅因为一个构建块是由专家编写的，并不意味着您构建的系统是安全的。例如，您可能不正确地使用 IV、忘记 MAC、不正确地使用 MAC，......使用低级加密 API 很棘手，大多数开发人员都弄错了。
+1 虽然句子“你不会通过保持盐的秘密获得安全性。”是不正确的。例如，盐可以由公知的盐和代码中的静态盐值构成。在这种情况下，您需要知道数据库中的盐值和代码中的盐值。如果这些可以被不同的角色访问，这个技巧可以用来提供另一层安全。

【解决方案2】：

你的假设是正确的。如果他们可以访问密码，他们也可以访问盐。我见过的 BCrypt 实现将迭代次数、哈希和盐都放在同一个结果字符串中！

这个想法是：如果知道迭代，即使盐和数字也应该是安全的。（如果我们总是能知道攻击者不知道盐和迭代次数甚至算法，那么安全性就会变得容易得多！除非攻击者礼貌地拒绝阅读我们的盐，否则我们必须假设他们可以访问如果发生违规行为，他们可以使用。）所以你是对的，他们可以暴力破解 - 如果他们有几台超级计算机和几百万年的计算时间可供他们支配。

【讨论】：