“双重哈希”比仅哈希一次密码更不安全吗？

双重哈希只有在我在客户端上对密码进行哈希，然后保存该哈希的哈希（使用不同的盐）才有意义。
这样即使有人黑入服务器（无视SSL提供的安全性），他仍然无法获得明文密码。
是的，他将拥有进入系统所需的数据，但他将无法使用该数据来危及用户的外部帐户。而人们众所周知地几乎为任何事情使用相同的密码。
他能够访问明文密码的唯一方法是在客户端上安装keygen - 这已经不再是您的问题了。
因此简而言之：
1. 在客户端上的第一次哈希可在“服务器遭到黑客攻击”的情况下保护您的用户。 2. 服务器上的第二次哈希用于保护您的系统，如果有人获得了您的数据库备份，他将无法使用这些密码连接到您的服务。

关于减少搜索空间的担忧在数学上是正确的，尽管搜索空间仍然足够大，对于所有实际目的（假设您使用盐），在2^128。然而，由于我们谈论的是密码，可能的16个字符字符串（字母数字，大小写敏感，加入了一些符号）的数量大约是2^98，根据我草稿纸上的计算。因此，搜索空间的感知减少实际上并不相关。

除此之外，在密码学上实际上没有区别。

虽然有一个名为“哈希链”的密码原语——一种允许您执行一些很酷的技巧的技术，例如在使用签名密钥后披露它，而不会牺牲系统的完整性——在最小时间同步的情况下，这使您可以干净地绕过初始密钥分发的问题。基本上，您预先计算一组大量的哈希值 - h(h(h(h....(h(k))...)))，使用第n个值进行签名，在一定时间间隔后，发送密钥，并使用密钥（n-1）进行签名。接收者现在可以验证您发送了所有以前的消息，而且没有人可以伪造您的签名，因为其有效期已过。

重新哈希数十万次就像Bill建议的那样，只是浪费你的CPU...如果你担心人们破解128位，那么使用更长的密钥。

正如本文中的几个回答所建议的那样，有些情况下可能会提高安全性，而其他情况则肯定会降低安全性。有一个更好的解决方案可以明显提高安全性。不要将哈希计算的次数加倍，而是将您的盐加倍，或者将哈希使用的位数加倍，或两者兼而有之！不要使用SHA-245，而升级到SHA-512。

是的。

绝对不要使用传统哈希函数的多次迭代，比如md5(md5(md5(password)))。最好的情况下，你只会获得微小的安全性提升(这样的方案几乎没有任何防御GPU攻击的保护; 只需进行管道处理即可)。在最坏的情况下，每增加一次迭代，你就会减少哈希空间(因此减少了安全性)。在安全方面，明智的做法是假设最坏的情况。

要使用由有能力的密码学家设计为有效密码哈希且能够抵御暴力和时间空间攻击的密码哈希函数，包括bcrypt、scrypt，以及在某些情况下PBKDF2。glibc基于SHA-256的哈希函数也是可以接受的。

我要冒昧地说，在某些情况下，它可能更安全...但不要马上给我点踩！

从数学/密码学的角度来看，它不太安全，我相信其他人会给你一个比我更清晰的解释。

然而，存在大型MD5哈希数据库，其中更有可能包含“密码”文本，而不是其MD5哈希值。因此，通过双重哈希，您可以降低这些数据库的有效性。

当然，如果您使用盐，则这种优势（劣势？）就消失了。

双重哈希是丑陋的，因为攻击者很可能已经建立了一个表来生成大多数哈希值。更好的方法是对哈希值进行盐处理，并将哈希值混合在一起。还有一些新的方案可以“签名”哈希值（基本上是盐处理），但以更安全的方式。