为什么不应该对传递给 Crypto.HashPassword 的密码加盐？答案

【问题标题】：Why shouldn't passwords passed to to Crypto.HashPassword be salted?为什么不应该对传递给 Crypto.HashPassword 的密码加盐？
【发布时间】：2016-05-20 19:58:35
【问题描述】：

所以，在 ASP.NET 中，

System.WebHelpers.Crypto.HashPassword("123456");

将创建一个每次都是唯一的散列、加盐字符串。这很棒;这意味着如果有人设法获得散列密码（例如，在 SQL 注入攻击中），他们将无法使用查找表来找到原始密码。但是，据我所知，他们仍然可以轻松编写代码来尝试在本地进行暴力破解，而不涉及受害者的服务器，例如：

foreach(string passwordToTry in BigListOfCommonPasswords)
if (Crypto.VerifyHashedPassword(stolenHash,passwordToTry)) return passwordToTry;

...所以在调用HashPassword时添加自己的额外盐不是更好，其中额外的盐存储在数据库之外，例如：

System.WebHelpers.Crypto.HashPassword("123456"+getSaltFromWebConfig());

...，还是出于某种原因这毫无意义？在我看来，让上述蛮力攻击变得更加困难是值得的，但我从未在 Crypto.HashPassword 的使用示例中看到任何地方提到过这个想法，所以有什么我遗漏的吗？

编辑：这不是 The necessity of hiding the salt for a hash 的副本。这个问题是问一个不隐藏的盐是否有任何用处。我并不认为存储在与散列密码相同的位置的盐是有用的，或者将未加盐的密码传递给 Crypto.HashPassword 是有用的。我真正得到的是添加您自己的额外盐，存储在其他地方（即使每个用户都相同），在 Crypto.HashPassword 提供的保护之上提供了额外的保护层。

在暴露数据库的 SQL 注入攻击的情况下，例如 web.config 文件中的额外盐仍将受到保护（或至少需要完全不同的攻击才能访问它）。

System.WebHelpers.Crypto.HashPassword("123456"+getSaltFromWebConfig());

使散列密码对攻击者的用处远不如

System.WebHelpers.Crypto.HashPassword("123456");

针对某些类型的攻击，在计算能力或编程时间方面没有太多额外成本。

【问题讨论】：

The necessity of hiding the salt for a hash的可能重复
好吧，那个方法已经给你的密码加盐了。所以你在腌制盐渍哈希。那是没有意义的吗？我不知道。腌三遍就没意义了吗？或者可能是四个？五次腌制没有意义吗？我想说，在无限盐之前的某个时刻，我们达到了无意义的高峰。所以我们有一个介于 2 和无穷大之间的数字，它变得毫无意义。由于我们不知道实际数字，而 2 肯定是候选者，那么我们不妨选择 2。
@Will whelp，听起来您阅读了帖子的标题而没有真正阅读它的文本。但是感谢您的评论，我们的生活中都需要更多的讽刺！
你是说我的评论毫无意义吗？

标签： asp.net security

【解决方案1】：

您所描述的盐通常称为胡椒。关于是否使用辣椒的问题已经在这里得到了非常完整的回答：

Best Practices: Salting & peppering passwords?

总之，你不应该使用辣椒，因为：

您无法更改辣椒的值，因为哈希函数是一种方式。
添加辣椒可以有效地改变散列算法，这只能由专家来完成。

但是，如果假设获取静态密钥比获取密码哈希更难的假设成立，那么还有另一个选项可以提高安全性。无需添加胡椒，只需使用标准对称算法对哈希和盐的组合进行加密。这解决了上述两个问题，同时在加密密钥不被泄露的情况下仍能提高安全性。

【讨论】：