有设计要慢的密码吗？

Question

为了安全地存储密码，最好使用哈希函数来存储哈希函数，该函数设计得像bcrypt那样慢。我们的目标是战胜暴力攻击。

有足够慢的密码来防止暴力攻击吗？我对SSH私钥存储特别感兴趣。如果我的密码只有8个字符的话，蛮力攻击会起作用吗？

Answer 1

大多数加密算法已经比较慢，判断成功也要困难得多。当您试图确定哈希的输入时，您知道所需的输出。然而，当您试图破解加密时，您通常不知道所需的明文，即使知道，潜在的输入空间通常要大得多、更大、更大。

密码的每一个数字只值大约7位熵，即使是理想的随机选择。即使是标准对称密钥的低端也通常使用128位熵。如果每个人都使用真正随机的18个字符密码，那么哈希的速度就无关紧要了。此外，攻击者通常不知道您需要访问的纯文本，而且加密算法的操作通常要慢一些，因为它们必须对一组较长的数据执行更复杂的操作。

所以，从某种意义上说，不，没有专门设计缓慢作为设计目标的算法，但它们不需要像提供的安全级别那样，而且算法的正常速度也不需要被放慢才能实用。在没有系统漏洞的128位加密算法上，对精心选择的密钥进行暴力攻击所需的时间已经超过我们的太阳燃烧时间，更不用说256位密钥了(在宇宙热死之前，目前的硬件不会进行这种攻击)。简单地说，放慢速度是不必要的。

如果要对密码派生密钥使用密钥派生函数，则需要慢一点，但不希望使解密本身变得慢，因为这样做效率很低。

至于SSH私钥存储，它将完全取决于密钥派生函数的实现，而不是加密算法的速度，但如果您想让SSH私钥存储使用相当慢的密钥派生(我不确定SSH私钥存储使用什么，并且它可能因客户端而异)，我建议它至少至少有10个字符。

Answer 2

大部分情况下，不是。密码被设计成尽可能快，同时提供一个良好的安全水平，以便您可以快速和容易地加密数据。然而，这个属性使它们不利于密码加密，因此，为什么会有bcrypt之类的东西通过多次迭代密码算法来减慢它们的速度。

大约十年前，我遇到了一个例外，那就是设计缓慢。作者是这样设计的，因为他不相信快速算法是安全的。虽然一般认为这是不切实际的，因为对重要数据进行加密需要很长时间，而且该设计阻止了它在流环境中的使用，但如果设计是加密安全的，则它很可能成为单向密码散列算法的良好基础。

Answer 3

一些哈希函数(假设您指的是散列，而不是密码，因为您在谈论密码哈希)比其他函数慢。例如，Bernstein最初的CubeHash实现相对较慢，DJB将其糟糕的性能吹嘘为卖点。不过，没人真正相信它。

许多业界的努力需要致力于完善和保护一个单一的加密功能，因此该功能需要全面发挥作用。此外，除了用于散列密码之外，散列函数还用于文件验证和即时消息签名。

在需要高性能的情况下，运行缓慢的哈希函数是不可挽救的，但是快速操作的哈希函数可以通过简单地迭代地运行，就像在PBKDF2和类似的哈希增强算法中所发生的那样。考虑到这一点，快速散列是普遍更有用的，因此更有可能得到良好的审查和广泛部署。