SHA512Managed被认为是.NET 3.5中安全性方面最好的单向散列吗？

三个SHA512管理相关问题：

SHA512Managed被认为是.NET 3.5中安全性方面最好的单向散列吗

SHA512管理时应使用多大的盐量？该应用程序用于至少包含8个字符的强密码

与小字符串的256相比，512是否过多

---

如果你想防止暴力攻击，可以在bcrypt或scrypt获得战利品。它们被设计成在算法上很慢。因此，即使攻击者确实掌握了密码数据库，计算所有内容也将花费很长时间

Sha512Managed不依赖于系统调用，并且具有内置哈希中最大的哈希大小。如果您没有针对其他任何内容进行优化，那么它将被认为是最安全的

为了破解密码，salt本质上增加了密码的大小。虽然“越大越好”，但任何超出密码本身位数的东西都在很大程度上被浪费了。因此，对于最小8个ASCII字符的密码，您可以选择64位salt

是的，也不是。对现代技术来说，这太过分了；字符串的大小无关紧要。如果你需要你的密码在未来100年内保持安全，那么，选择512

参考：

---

Ben的答案不正确，您不应该使用SHA*函数散列密码。您应该使用专门为哈希密码而设计的哈希函数，例如PBKDF2、BCrypt或SCrypt。闵的回答和评论是正确的

由于您想使用标准的.NET库，我建议使用Rfc2898DeriveBytes，它是PBKDF2的一个实现

---

您如何定义“最佳”？没有散列冲突？最好的安全性，我会更新这个问题。这些看起来很有趣，但我正在寻找一个散列函数，它是.NET Framework（3.5版）的一部分。我认为您需要重新思考较长的散列如何使它更安全。使用较长哈希的主要原因是为了降低冲突的概率。那么，更长的散列究竟是如何提高安全性的呢？你基本上是通过减少冲突的可能性来实现的，在我看来，冲突并不是一个很好的衡量标准。对于存储密码来说，所有这些都是多余的。只需修改密码。请记住，bcrypt是为密码存储场景而设计的。第2点（salt的用途）：不。salt是为了防止两件事：1。非盐字典攻击（即MD5数据库）2。如果数据库中加密了两个相同的明文值（如果未加密），则在数据库中找到任何测试值的有效冲突的概率将乘以N条记录（如果未加密）。基本上，任何大型数据库unsalted都意味着，虽然您可能不会与特定行发生冲突，但与任何行发生冲突的可能性更高。添加salt会使您返回到需要个性化的每行攻击，前提是salt对于每个记录都是唯一的。我正在寻找单向散列，Rfc2898DeriveBytes使用键。您对Rfc2898DeriveBytes的解释不正确，请再次查看。还可以阅读这篇关于为什么不应该使用SHA的文章*