bcrypt 和多次哈希有什么区别？

Question

bcrypt 比，比方说，

def md5lots(password, salt, rounds):
    if (rounds < 1)
        return password
    else
        newpass = md5(password + salt)
        return md5lots(newpass, salt, rounds-1)

我有一种感觉，鉴于它的炒作，比我更聪明的人已经弄清楚了bcrypt 比这个更好。有人可以解释一下“聪明的外行”术语的区别吗？

Answer 1

主要区别 - MD5 和其他旨在验证数据的哈希函数被设计得很快，而 bcrypt() 被设计得很慢。

当您验证数据时，您需要速度，因为您希望尽可能快地验证数据。

当您试图保护凭据时，速度会对您不利。拥有密码哈希副本的攻击者将能够执行更多的暴力攻击，因为 MD5 和 SHA1 等的执行成本很低。

相比之下，bcrypt 是故意昂贵的。当真正的用户尝试进行一两次身份验证时，这并不重要，但暴力破解的成本得多。

Answer 2

bcrypt 和使用 MD5 进行多次哈希处理之间存在三个显着差异：

1. 输出大小：MD5 为 128 位（16 字节），bcrypt 为 448 位（56 字节）。如果您在数据库中存储数百万个哈希值，则必须考虑到这一点。
2. 针对 MD5 的碰撞和原像攻击是可能的。
3. 随着 cpu 变得越来越强大，Bcrypt 可以配置为越来越多的迭代。

因此，使用 MD5 进行加盐和拉伸并不像使用 bcrypt 那样安全。这个问题可以通过选择比 MD5 更好的哈希函数来解决。

例如，如果选择 SHA-256，则输出大小将为 256 位（32 字节）。如果可以像 bcrypt 一样配置加盐和拉伸来增加迭代次数，那么两种方法之间没有区别，除了存储结果哈希所需的空间量不同。

Answer 3

您实际上正在谈论实施 PBKDF2 或基于密码的密钥派生函数。实际上，它与 BCrypt 是一样的，优点是可以延长派生密码所需的 CPU 时间。与 BCrypt 相比，它的优点在于，通过知道您已经输入了多少次“迭代”密码，当您需要增加密码时，您可以无需重置数据库中的所有密码。 。只需让您的算法获取最终结果，就好像它是在第 n 次迭代（其中 n 是前一次迭代计数）一样，然后继续！

建议您使用适当的 PBKDF2 库，而不是创建自己的库，因为让我们面对现实，就像所有密码学一样，您知道某些东西是否安全的唯一方法是它是否已经过互联网“测试”。 （请参阅此处< /a>)

使用此方法的系统：
.NET 有一个已经实现的库。请参阅此处
Mac、Linux 和 Windows 文件加密使用此加密方法的许多迭代（10,000+）版本来保护其文件系统。
Wi-Fi 网络通常使用这种加密方法来保护
来源

感谢您提出这个问题，它迫使我研究我正在使用的方法保护我的密码。

TTD

Answer 4

尽管这个问题已经得到解答，但我想指出 BCrypt 和散列循环之间的细微差别。我将忽略已弃用的 MD5 算法和指数成本因子，因为您可以在问题中轻松改进这一点。

您正在计算哈希值，然后使用结果来计算下一个哈希值。如果您查看 BCrypt 的实现，您会发现每次迭代都使用生成的哈希值以及原始密码（密钥）。

Eksblowfish(cost, salt, key)
  state = InitState()
  state = ExpandKey(state, salt, key)
  repeat (2^cost)
    state = ExpandKey(state, 0, key)
    state = ExpandKey(state, 0, salt)
  return state

这就是原因，您不能采用 Bcrypt 哈希密码并继续迭代，因为那时您必须知道原始密码。我无法证明这一点，但我认为这使得 Bcrypt 比简单的哈希循环更安全。

Answer 5

严格来说，bcrypt 实际上是对文本进行加密：

OrpheanBeholderScry怀疑

64 次。

但它使用从您的密码和一些随机生成的盐派生的密钥来完成此操作。

密码散列不是散列

“密码散列算法”（如 bcrypt）的真正优点是它们使用大量 RAM。

SHA2设计就是为了速度快。如果您是实时网络服务器，并且想要验证文件完整性，那么您需要运行速度非常快、资源使用量非常低的服务器。这是密码散列的对立面。

• SHA2 被设计为快速
• SHA2 可以在 128 字节 RAM 上运行
• SHA2 很容易在硬件中实现
• 我拥有一个 USB 记忆棒设备，可以计算3.3 亿 哈希值
• 事实上，我拥有其中的 17 个

如果您多次执行“快速” 哈希值（例如 10,000 是PBDKF2 的常见推荐），那么你就不是真的添加任何安全性。

您需要的是一个很难在硬件中实现的哈希值。您需要的是难以在 GPU 上并行化的哈希值。

在过去的几十年里，我们了解到 RAM 是减缓密码哈希尝试的关键。定制硬件在执行原始计算方面表现出色（事实上，只有 1% 的 CPU 专用于计算 - 其余部分专用于将机器指令更快地执行；预取、乱序执行、分支预测、缓存）。阻碍定制硬件的方法是让算法必须占用大量 RAM。

• SHA2：128 字节
• bcrypt：4 KB
• scrypt（可配置）：LiteCoin
• Argon2 中为 16 MB（可配置）：文档示例中为 64 MB

密码哈希并不意味着简单地多次使用快速哈希。

• 现代推荐的 bcrypt 成本因子是 12；因此计算大约需要 250 毫秒。
• 您必须执行大约 330,000 次 SHA2 迭代才能等于现代单核 CPU 上的时间成本。

但是，我们回到我的 2.5W、USB、SHA2 棒，它的速度为 330 Mhashes/秒。为了防止这种情况发生，迭代次数必须达到 8300 万次。

• 如果您尝试仅增加 CPU 成本：您就输了。
• 您必须添加内存成本

bcrypt 已有 21 年历史，并且仅使用 4KB。但它仍然比任何数量的 MD5、SHA-1 或 SHA2 哈希要好得多。