当你有一个 128 位输出时，更大的输出长度使它更强大，直到已经达到的某个点。进一步扩大它不会改变安全性。

细节：除非有任何结构上的弱点，散列函数的安全性取决于它对一般攻击的抵抗力（又名“运气”：攻击者尝试随机输入直到找到匹配项），而这种抵抗力取决于哈希输出的大小。对于具有n位输出的散列函数，攻击者需要花费2 ⁿ的努力才能找到原像（即某个密码，不一定是与输出匹配的“真实”密码）。超过大约2 ⁸⁰的努力距离攻击者无法想象的技术上不可行的程度太远了。在 128 位，你已经有2 ⁴⁸保证金，即比已经过于昂贵的保证金高出近 30 万亿美元。这就像吹嘘在没有超过 0.01 美元现金的情况下偿还美国国债一样。

更大的输出大小也有助于防止碰撞；再次，基于运气的通用攻击的成本为2 ^n/2（您会看到为什么 SHA-1 具有 160 位输出：使2 ⁸⁰的碰撞成本无法达到）。但是，冲突不是密码散列的问题。计算碰撞的能力不会给攻击者任何优势。碰巧的是，使用通常的哈希函数也无法实现冲突，但如果它们是可行的，那就不是什么大问题了。

密码散列的真正弱点不是散列；这是密码。或者，更准确地说，是密码背后的人脑。对散列密码的成功攻击是尝试潜在密码的攻击，而不是针对散列函数结构弱点（如果有）的攻击。缓解措施包括慢散列和加盐，这是 PBKDF2 所做的。

您只能存储 80 位左右的 PBKDF2 输出（和盐）；事情仍然是安全的。（出于纯粹的审美原因，将其设为 128 位：这些计算机人，他们只是喜欢 2 的幂。）

是的，512 位哈希是多余的。128位就足够了。

请记住，系统的安全性与最薄弱的环节一样强。在这种情况下，最薄弱的环节几乎可以肯定是用户密码的熵。 大多数用户选择容易猜到的低劣密码。增加哈希长度并不能阻止这种攻击。

出于这个原因，最重要的是使用旨在减缓对用户密码的猜测攻击的密码散列方案，例如bcrypt、PBKDF2或 scrypt 。 选择使密码散列尽可能慢的迭代次数。确保也使用随机盐。确保使用 SSL 保护密码从用户到您的站点的传输；我建议您使用 SSL 站点范围。在其他地方，我就如何提高基于密码的身份验证的安全性提供了其他建议。

这个网站上有很多关于保护密码存储的附加信息。试试搜索栏：你应该会找到各种好的提示和有用的建议。

虽然任何两种散列方案的安全性在功能上是等效的，但一旦超过约 100 位，除非存在一些重大缺陷——我不会说 512 位散列是矫枉过正的。只要哈希值超过 128 位，其长度在很大程度上是无关紧要的。

您的数据库中是否有足够的密码来为每个用户存储额外的（512 位 = 64 字节；128 位 = 16 字节）48 字节非常重要？

地狱，许多系统会将您的哈希存储为 ASCII 十六进制字符串（这意味着每个字节需要两个 ASCII 字符0-9a-f来存储），因此您通常可以通过转到二进制 blob 来优化哈希的大小。但是，您很少不关心在现代系统上节省几十个字节。如果您有 100 万用户，它仍然只有额外的 48 MB，这对于硬件来说仍然是微不足道的。而且我们建议使用慢速哈希（例如，bcrypt/scrypt），获取/比较哈希的性能问题是无关紧要的（事实上，更大的哈希在这方面稍微好一些，因为它们会稍微慢一些）。

我在我的 linux 系统上使用 SHA-512 crypt。（这不是一个简单的 sha-512 哈希；但基本上是 5000 轮（默认）SHA-512。）我不使用它，因为我需要的不仅仅是 SHA-256 crypt，但它是我的发行版的默认设置（并且每个用户额外的 43 个字节完全无关紧要（它采用类似 base64 的编码）。如果将来发现对 SHA 的攻击会显着降低其复杂性，它还有一个额外的小好处，我从一个更安全的起始位置开始。（例如，如果您发现一个原像攻击使其更简单 2 ⁶⁴倍，则 128 位散列会受到损害，而 256/512 位散列会很好）。