安全密码散列[关闭]答案

【问题标题】：Secure Password Hashing [closed]安全密码散列[关闭]
【发布时间】：2010-12-22 22:22:22
【问题描述】：

我需要在 .Net WinForms 应用程序中存储单个密码的哈希值。

最安全的方法是什么？

特别是：

盐、HMAC 还是两者都有？
多少盐？
多少次迭代？
什么编码？（密码是纯ASCII）

我假设算法应该是 SHA512 或 HMACSHA512。

【问题讨论】：

无法提供最安全的建议（尽管这是您真正想走多远的问题），但请确保它绝对是真正的单向哈希并且足够安全，即使您即使您需要非常努力也无法获得密码。例如如果有大客户臭味或要求获取密码。
我假设 SHA512 是安全哈希。
我认为“最安全”并不是真正合适的问题。这是一个基于保护数据的重要性在安全性、复杂性和用户便利性之间找到平衡的问题。我们是在谈论保护银行帐号或视频游戏分数吗？可能的攻击者是脚本小子还是 NSA？
@Tim：用户方便不是一个因素。我会有密码；我只是在问最好的方法来散列它。
阅读：stackoverflow.com/questions/800685/…

标签： .net security passwords hash

【解决方案1】：

使用至少 128 位或更长的安全随机盐对您的哈希进行加盐，以避免彩虹攻击并使用 BCrypt、PBKDF2 或 scrypt。 PBKDF2 自带NIST approval。

引用：Archive.org: http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html

问题在于 MD5 速度很快。它的现代竞争对手也是如此，比如 SHA1 和 SHA256。速度是一种设计现代安全哈希的目标，因为哈希是几乎每个密码系统，通常得到在每个数据包上按需执行或基于每条消息。

速度正是您在密码哈希函数中所不想要的。

快速密码验证功能是一个问题，因为它们可能会受到暴力攻击。使用上述所有算法，您可以控制“缓慢”

【讨论】：

速度是消息摘要功能中非常重要的部分。 NIST 在选择下一个标准的过程中排除了缓慢的消息摘要。
有时我想知道人们是否在投反对票之前阅读了我的答案
我要补充一点，Rfc2898DeriveBytes 中有一个 PBKDF2 的本机 .Net 实现，这可能是目前最好的选择。

【解决方案2】：

我可以推荐BCrypt.net。非常易于使用，您可以调整执行散列所需的时间，这太棒了！

// Pass a logRounds parameter to GenerateSalt to explicitly specify the
// amount of resources required to check the password. The work factor
// increases exponentially, so each increment is twice as much work. If
// omitted, a default of 10 is used.
string hashed = BCrypt.HashPassword(password, BCrypt.GenerateSalt(12));

// Check the password.
bool matches = BCrypt.CheckPassword(candidate, hashed);

【讨论】：

【解决方案3】：

对于具有大量密码的服务器端实现，您绝对应该使用像 bcrypt 这样的可调迭代方法。这篇关于该主题的知名文章仍然（大部分）相关：

http://www.securityfocus.com/blogs/262

对于独立应用程序中的单个密码，其中存储位置可能已经由系统自己的身份验证系统保护，我认为它的重要性要小得多。单个强哈希可能就足够了，添加盐也很容易，没有理由不这样做。

【讨论】：

【解决方案4】：

RNGCryptoServiceProvider 生成随机盐，然后SHA512 带有盐的密码，最后存储密码哈希和相应的盐，如果您想稍后验证某些文本是否等于存储的密码。

【讨论】：

你认为我不应该使用 HMAC，还是使用迭代哈希？
在我看来，带有随机盐的 SHA-512 已经足够强大了。这里有一篇不错的文章aspheute.com/english/20040105.asp，只需使用 SHA-512 而不是 SHA-1。
HMAC 引入了你不需要的问题（密钥）。
bcrypt 是一种明显更好的方法
SHA512 不是一个好的选择：它太快了。 bcrypt 更好。

【解决方案5】：

哈希和盐。如果您只散列，您可能会受到彩虹攻击（反向查找）的攻击，而盐会使这变得更加困难（随机盐是最好的。）对于您的编码，您可能希望使用 Base64 或十六进制对生成的字节数组进行编码.如果您只是尝试将字节数组存储为 Unicode，您可能会面临丢失某些数据的风险，因为并非所有模式都是有效字符。这也允许一种更简单的方法来比较哈希（当您想要验证而不是比较字节数组时，只需比较 base64 或十六进制字符串）

增加的回合数除了减慢攻击者的速度外并没有多大作用。但是，如果您丢失或需要重新创建哈希算法，这也使得将来重用哈希变得更加困难。您可以在 unix 系统上查看标准密码哈希，例如 crypt。这允许您更改哈希算法，甚至可以支持版本控制。

但是，对于大多数应用程序来说，简单的哈希 + 盐就足够了。

【讨论】：

【解决方案6】：

严格来说更安全：

Salt, HMAC, or both?

两者都会更安全。由于 HMAC 的密钥可以被视为一种盐，因此两者都做有点多余，但仍然更安全，因为它需要更多的工作才能破解。

How much salt?

每一点盐都会使彩虹表中需要维护的组合加倍，以便轻松破解密码。但是由于只有一个密码，并且只有一种盐，因此可能不需要更多。 HMAC 使用底层散列的块大小作为其密钥大小，SHA512 为 1024 位。块大小应该足以容纳盐，但是将其加倍或三倍会使使用彩虹表破解密码变得更加困难。

How many iterations?

越多越好。当然，更多的迭代意味着确定是否输入了正确的密码需要更长的时间，但是计算机速度很快，用户不会介意在验证密码时等待几秒钟。进行更多的迭代意味着破解密码的人也必须进行更多的迭代。

What encoding? (The password is plain ASCII)

不妨加密（使用 AES）过度迭代、过度加盐、HMAC'ed、超级安全的密码及其盐，以使其更难。为加密的密码哈希和密钥设置密码，是应该出现在可执行文件中的字符串组合，例如“RNGCryptoServiceProvider”或“System.Security.Cryptography”。在编码时，我们不妨将其转换为十六进制、base64 或更好的 base-36 或其他一些不太预期的转换。

注意：这主要是开玩笑写的，但应该还是有些道理。

【讨论】：

【解决方案7】：

我认为您应该坚持开放标准。在目前的散列方案中，OpenLDAP 使用的“{ssha}”是非常安全且被广泛使用的。你可以在这里找到描述，

http://www.openldap.org/faq/data/cache/347.html

大多数 LDAP 库都实现了这种方案。

【讨论】：

【解决方案8】：

您可以遵循已发布的标准，例如 pkcs#5。有关简短说明，请参阅 http://en.wikipedia.org/wiki/PKCS，或参阅 RFC 以 https://www.rfc-editor.org/rfc/rfc2898。

【讨论】：

【解决方案9】：

这是一个 API，它可以满足您的所有需求：)

https://sourceforge.net/projects/pwdtknet

【讨论】：