c# - 发布站点上的加密类

Question

最近我遇到了 System.Web.Helpers.Crypto 类。

使用Crypto.HashPassword 函数似乎是一个非常容易/简单的解决方案。但我不确定这个句子(来自 msdn):

The password hash is generated with the RFC 2898 algorithm using a 128-bit salt, a 256-bit subkey, and 1000 iterations. The format of the generated hash bytestream is {0x00, salt, subkey}, which is base-64 encoded before it is returned.

所以我的问题:

1) 是否可以在生产/发布网站上使用此类？

2) 1000 次迭代的限制是否揭示了网站安全问题？

3) 如果是这样，有没有简单的方法来克服这个限制？

我知道调用 Crypto.HashPassword(MyPlainText) 会自动生成 salt 并将它们散列在一起，但是如果我也像下面的代码一样将随机 salt 与我的纯文本连接起来会怎样:

var myAdditionSalt=Crypto.GenerateSalt(); Crypto.HashPassword(MyPlainText+myAdditionSalt)

并将 myAdditionSalt 存储在数据库中。 它会增加安全性吗？

Answer 1

1) Is it ok to use this class on a production/release site?

与任何系统一样，安全控制的有效性取决于对手为破坏控制所投入的资源。如果妥协的后果很小，那么即使在生产环境中，迭代次数也可能更少。

应该补充的是，密码存储库对攻击者具有内在值(value)，因为用户可以在多个服务中重复使用密码。在某些情况下，密码本身需要比凭据保护的资源更大的保护。

2) Does the limitiation of 1000 iterations reveal the web site to secure problems.?

我建议查看问题和回复 here . 1,000 次迭代是 RFC 2898(2000 年发布)中推荐的最小值。在 2012 study (PDF) ，Durmuth 等人得出结论，“我们认为，按照 RFC 2898 对 PBKDF2 的定义，安全系统在应用程序或系统的生命周期中以恒定(最小)1000 次哈希迭代运行是不够的，”建议取而代之的是可用计算资源下限的动态迭代计数。

3) Is there a simple way to overcome this limitation?

虽然稍微复杂一些，但您可以使用 Rfc2898DeriveBytes System.Cryptography 命名空间中的类。这个类提供了一个 constructor接受密码、哈希和迭代次数作为参数。 (有关功能实现示例，请参见 here。)

4) will [concatenating an additional salt with the password] increase security?

在这种特殊情况下，额外的盐会有效地为用户密码引入熵(复杂性)，就好像用户输入了更复杂的密码一样。由于需要存储额外的盐以进行密码验证，因此如果攻击者可以访问这第二种盐，则可能会抵消增加的安全增益。

也就是说，密码规范对算法更改高度敏感，偏离规范可能会引入可通过密码分析加以利用的漏洞。加强安全性的最佳做法是增加迭代次数(RFC 299 认可)，而不是引入非标准的增强功能。