最近，我遇到了System.Web.Helpers.Crypto类。
使用Crypto.HashPassword函数似乎是一个非常简单的解决方案。但我不确定此句子（来自msdn）：
密码散列是通过RFC 2898算法使用
128位盐，一个256位子项和1000次迭代。的格式
生成的哈希字节流是{0x00，salt，subkey}，它是base-64
在返回之前进行编码。
所以我的问题是：
1）是否可以在生产/发布站点上使用此类？
2）是否限制了1000次迭代才能揭示网站以解决问题？
3）如果是，是否有简单的方法来克服此限制？
我知道调用Crypto.HashPassword(MyPlainText)会自动生成盐并将它们散列在一起，但是如果我也将随机盐与我的纯文本连接起来，例如以下代码，该怎么办：var myAdditionSalt=Crypto.GenerateSalt();
Crypto.HashPassword(MyPlainText+myAdditionSalt)
并将myAdditionSalt存储在数据库中。
会增加安全性吗？
最佳答案
1）是否可以在生产/发布站点上使用此类？
与任何系统一样，安全控制的有效性取决于攻击者致力于破坏控制的资源的功能。如果折衷的后果很小，那么即使在生产环境中，也可以进行较少的迭代。
应该补充的是，密码存储库对攻击者具有内在的价值，因为用户可以在多个服务之间重用密码。在某些情况下，密码本身将需要比凭据保护的资源更大的保护。
2）是否限制了1000次迭代才能揭示网站以解决问题？
我建议回顾问题和答案here。 RFC 2898（2000年发布）中建议的最低迭代次数为1,000。在2012 study (PDF)中，Durmuth等人得出结论：“我们认为，对于安全系统而言，按照RFC 2898的定义，在应用程序或系统的生命周期中，以恒定（最少）的1000次哈希迭代次数运行是不够的。对于PBKDF2”，而是建议使用可用计算资源下限的动态迭代计数。
3）有没有简单的方法可以克服此限制？
虽然稍微复杂一些，但您可以直接在Rfc2898DeriveBytes名称空间中使用System.Cryptography类。此类提供了一个constructor，它接受密码，哈希和迭代次数作为参数。 （有关功能实现的示例，请参见here。）
4）[将额外的密码与密码连接]是否可以提高安全性？
在这种特殊情况下，附加盐将有效地将熵（复杂性）引入用户密码，就像用户输入了更复杂的密码一样。由于将需要存储其他盐用于密码验证，因此，如果攻击者可以使用此第二盐，则可能会否定增加的安全性。
也就是说，密码规范对算法更改高度敏感，并且偏离规范可能会引入可通过密码分析利用的漏洞。增强安全性的最佳实践是增加迭代次数（RFC 299认可），而不是引入非标准增强功能。
关于c# - 发布站点上的加密类，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/19988966/