问System.Web.Helpers，HashPassword盐和迭代？

EN

您正确地说，存储salt和迭代计数对将来的规划更好，只需查看PHP的核实()即可。

该算法不仅具有迭代计数(称为代价，不完全是迭代计数，而且基于相同的概念)和用导出密钥存储盐的特点，而且在将来需要替换的情况下，算法也会被存储。

System.Web.Helpers.Crypto类使用PBKDF2对密码进行散列，在内部通过定义的迭代次数使用哈希算法对密码进行散列。由于内部操作都是不可逆的，并且“迭代”段不是最终段，所以执行额外的哈希操作不起作用。整个密码需要从原来的纯文本源重新哈希。

通常，重新哈希密码的过程发生在用户下次再次登录时。此时，系统可以确定用户的密码是否需要重新哈希，并在需要时继续这样做。这不仅避免了运行可能导致停机的主要重散列操作的成本，而且也是用户的明文密码再次可用的唯一时间。如果在不久的将来存在漏洞的可能性，而不是漏洞完全暴露的时候，密码应该重新哈希，因为此时可能为时已晚。

如果数据的安全性与未来的规划有关，我建议您使用另一个类(可能是自己的类)，它允许自定义的迭代次数，并将所有相关数据存储在派生密钥/散列密码本身中。

实际上，该助手确实存储了一个前缀，指示使用的算法和迭代次数，因此如果算法在将来发生变化，仍然可以验证旧密码。

我们考虑过将违约从1,000增加到更高。然而，当我们这样做时，新的CPU命中是不可接受的。用户设备需要100万次迭代是可以的，因为您并不关心平板电脑或电话是否需要0.5秒才能登录。但是，当网页需要可测量的时间来处理登录请求时。好吧..。您不希望用户只通过登录就可以DoS服务器。:)

遗憾的是，1,000次迭代仍然是提供更高安全性(而不是直截了当的盐和散列)和保持web服务器响应性的最佳选择。

1. 不，您不能“加强”现有的密码--更改散列迭代次数将破坏现有的验证。除非要强制所有当前用户创建新密码，否则不要更改哈希设置。如果您正在加密而不是散列，这是可能的(但不要进行加密)。
2. 我们使用一个常见的助手库来进行盐化和散列，它允许我们为每个项目调整散列迭代的次数，这样我们就可以任意地增加迭代。如果你关心的是未来的防伪，这可能会让你在未来扩大规模.

通常，我们使用各种算法(SHA256、MD5等)进行大约100次的哈希操作。迭代次数和散列序列是单个项目设置的一部分--我们不使用salt和hash结果将其存储在DB中。

编辑：

现在我意识到，(通常)您实际上可以对现有密码哈希进行更多次哈希，以使它们与更新的散列功能同步--只要新哈希例程的第一部分与现有的哈希例程相同。例如，如果您当前散列10次并将其更改为100次，则可以将现有值哈希90次并更新数据库。如果Crypto实现在此过程中没有盐碱化，我预计10 + 90的迭代散列将产生与100个散列相同的结果。

但是，如果您搞砸了这个过程，最终可能会损坏所有用户的现有密码。除非我真的需要这样做，否则我不愿意实现这样的东西。