重点强化。我做得对吗？
我正在编写一个类来哈希密码，该类通过使用 System.Security.Cryptography.Rfc2898DeriveBytes 类来生成密钥拉伸用于计算哈希值的密钥。
该代码本质上是这样做的：
// Higher iterations value results in better key strength
var db = new Rfc2898DeriveBytes(password + salt + secretKeyFromConfigFile,
saltAsBytes,
iterations);
byte[] hashKey = db.GetBytes(64); // 64 bytes is the recommended size for the HMACSHA512 class
var sha512 = new System.Security.Cryptography.HMACSHA512(hashKey);
byte[] hashInput = System.Text.Encoding.UTF8.GetBytes(password + salt + secretKeyFromConfigFile);
byte[] hash = sha512.ComputeHash(hashInput);
return System.Convert.ToBase64String(hash);
System.Security.Cryptography.Rfc2898DeriveBytes 的文档表明它使用“...基于 System.Security.Cryptography.HMACSHA1 的伪随机数生成器”来派生密钥。
既然 SHA512 比 SHA1 更好，那么像这样简单地应用 SHA512 哈希函数会更好吗？
byte[] hash;
for (int i = 0; i < iterations; i++)
{
hash = sha512.ComputeHash(hash ?? hashInput);
}
return System.Convert.ToBase64String(hash);
加强密钥（如第一个代码块所示）和加强哈希（如第二个代码块所示）有什么区别？
对密码进行哈希处理时进行密钥拉伸的首选方法是什么？
I am writing a class to hash passwords which implements Key Stretching by using the System.Security.Cryptography.Rfc2898DeriveBytes class to generate the keys used to compute the hash value.
The code essentially does this:
// Higher iterations value results in better key strength
var db = new Rfc2898DeriveBytes(password + salt + secretKeyFromConfigFile,
saltAsBytes,
iterations);
byte[] hashKey = db.GetBytes(64); // 64 bytes is the recommended size for the HMACSHA512 class
var sha512 = new System.Security.Cryptography.HMACSHA512(hashKey);
byte[] hashInput = System.Text.Encoding.UTF8.GetBytes(password + salt + secretKeyFromConfigFile);
byte[] hash = sha512.ComputeHash(hashInput);
return System.Convert.ToBase64String(hash);
The documentation for System.Security.Cryptography.Rfc2898DeriveBytes indicates that it uses "... a pseudo-random number generator based on System.Security.Cryptography.HMACSHA1" to derive the key.
Since SHA512 is better than SHA1 Would it be better to simply apply the SHA512 hash function like so?
byte[] hash;
for (int i = 0; i < iterations; i++)
{
hash = sha512.ComputeHash(hash ?? hashInput);
}
return System.Convert.ToBase64String(hash);
What is the difference between strengthening the key (as shown in the 1st code block) and strengthening the hash (as shown in the 2nd code block)?
What is the preferred method to do key stretching when hashing passwords?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
除非您是加密专家，否则请坚持使用 Rfc2898DeriveBytes，它很可能已正确实现。抵制将自定义解决方案拼凑在一起的诱惑，这会破坏系统的安全性。
没有理由对 Rfc2898DeriveBytes 的输出进行哈希处理。
直接使用 GetBytes()，它就是为此目的而设计的。
你的关键拉伸的目的是什么？密码还是密码哈希？对于密码哈希，您可能想使用不同的算法。
Unless you're a crypto guru, just stick to Rfc2898DeriveBytes which is very probably correctly implemented. Resist the temptation of hacking together a custom solution which will break the security of your system.
There's no reason to hash the output of Rfc2898DeriveBytes.
Directly use GetBytes(), it's been designed for that intent.
What's the purpose of your key stretching? Cipher or password hash? For a password hash, you probably want to use a different algorithm.
这已经很老了，但是当我在谷歌上搜索同样的问题时，我遇到了这个问题，解决方案确实是坚持 Rfc2898DeriveBytes 的输出。
Rfc2898DeriveBytes 是 PBKDF2 的 .NET 实现。它需要您的密码、盐和迭代次数。这已经是整个实现，无需使用另一种哈希算法重新哈希结果。
事实上，强烈建议不要围绕此创建自己的实现，因为您可能会像其他人已经提到的那样破坏安全性。
这也是 https://openid.stackexchange.com 的作用，您可以在此处看到：
https://code.google.com/p/stackid /source/browse/OpenIdProvider/Current.cs#1135
This is pretty old, but I came across this when I was googling for the same question and the solution is indeed to stick to the output of Rfc2898DeriveBytes.
Rfc2898DeriveBytes is the .NET implementation of PBKDF2. It takes your password, a salt and the number of iterations. That is already the whole implementation and there is no need to rehash the outcome with another hashing algorithm.
In fact it is strongly advised to not create your own implementation around this, as you might break the security as other people already mentioned here.
That's what https://openid.stackexchange.com does as well, as you can see here:
https://code.google.com/p/stackid/source/browse/OpenIdProvider/Current.cs#1135