最近我遇到了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 次迭代的限制是否表明网站存在安全问题。？
我建议在这里查看问题和回复。1,000 次迭代是 RFC 2898（2000 年发布）中推荐的最小值。在2012 年的一项研究 (PDF)中，Durmuth 等人得出结论：“我们认为安全系统在应用程序或系统的生命周期内以恒定（最少）1000 次哈希迭代运行是不够的，定义如下： RFC 2898 for PBKDF2”，建议改为使用可用计算资源下限的动态迭代计数。
3）有没有一种简单的方法来克服这个限制？
虽然稍微复杂一些，但您可以直接使用命名空间Rfc2898DeriveBytes中的类System.Cryptography。此类提供了一个构造函数，该构造函数接受密码、哈希和迭代次数作为参数。（有关功能实现示例，请参见此处。）
4) [将额外的盐与密码连接起来] 会增加安全性吗？
在这种特殊情况下，额外的盐会有效地将熵（复杂性）引入用户密码，就好像用户输入了更复杂的密码一样。由于需要存储额外的盐以进行密码验证，因此如果攻击者可以访问第二个盐，那么增加的安全增益可能会被否定。
这就是说，密码规范对算法变化高度敏感，偏离规范可能会引入可通过密码分析利用的漏洞。加强安全性的最佳实践是增加迭代次数（RFC 299 认可），而不是引入非标准增强。