MD5哈希盐值 - 盐值应该存储在哪里？

Question

MD5哈希盐值 - 盐值应该存储在哪里？

securityhashcryptographymd5

5

你好，我有一个关于MD5哈希/加盐的问题。

最近我读了很多关于哈希和加盐的内容，我明白应该为每个单独的密码使用不同的盐，并且不应该使用像用户名这样的东西作为盐，因为盐最好是完全独特的。但是我不明白的是为什么建议将这个盐与密码一起存储在数据库中？

如果攻击者获得哈希和盐，这不是很危险吗？我知道唯一的盐可以让攻击者更难以破解，因为他不能对所有密码都使用单个计算出的哈希值进行检查。但是，把盐的一部分隐藏起来不是更好吗？

我正在考虑将盐分成两部分。第一部分像通常一样存储在数据库中，第二部分（更小）存储在我的应用程序中。攻击者几乎无法获取完整的盐，因为他必须渗透应用程序服务器和数据库。

这是一个好的解决方案吗？盐仍然是唯一的，但所有的盐都会以相同的序列结尾。

- Mario B

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Yahia · Accepted Answer

攻击者“被允许”知道盐值——你的安全性必须设计成这样，即使知道盐值也仍然安全。

盐值有什么作用？

盐值有助于防御使用预先计算的“彩虹表”进行暴力破解攻击。
盐值使攻击者的暴力破解变得更加昂贵（在时间/内存方面）。
计算这样的表格是昂贵的，通常只有在可以用于多个攻击/密码时才会这样做。
如果你对所有密码使用相同的盐值，攻击者可以预先计算这样的表格，然后将你的密码暴力破解为明文...
只要你为要存储哈希值的每个密码生成一个新的（最佳密码学强度的）随机盐值，就没有问题。

根据你使用MD5的方式，它是一个弱点，因为MD5不再被视为“密码学安全”

如果您想进一步加强安全性
您可以多次计算哈希值（哈希化哈希等）- 这不会花费太多，但它会使暴力攻击/计算“彩虹表”变得更加昂贵... 请不要自行发明 - 有证明的标准方法可供使用，请参见http://en.wikipedia.org/wiki/PBKDF2和http://www.itnewb.com/tutorial/Encrypting-Passwords-with-PHP-for-Storage-Using-the-RSA-PBKDF2-Standard和http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx。

现在使用这种机制是强制性的，因为“CPU / GPU时间”（可用于攻击，如彩虹表/暴力破解等）越来越广泛地可用（例如，亚马逊的云服务位列全球最快的50台超级计算机之一，并且可以被任何人用相对较少的费用使用）！

将盐分成两部分，一个硬编码/常量和一个唯一的部分是不推荐的！

根据所使用的算法，这可能会成为帮助攻击者突破您安全的弱点。我非常建议不要这样做，除非您能够数学证明它不会削弱您的安全性（在我看来这非常难）。

如果您正确实现安全性，攻击者完全可以知道您的完整盐...

更新（根据评论）：

RFC 2898是PBKDF2的一个重要参考。在第4.1节中，它谈到了向盐添加一部分的内容

盐应包含明确区分不同操作和不同密钥长度的数据

我认为这与OP提出的问题没有关系。RFC讨论了有关密钥长度等信息与随机盐一起作为附加部分合并的内容。这非常类似于包含头部区域描述其所包含数据特定方面的文件格式。这不会削弱安全性，并且在需要不同系统之间的互操作性的情况下可能非常有用。

相比之下，OP所问的基本上是仅将盐的一部分存储在DB中，同时保留应用程序中硬编码的其他（较小）部分，这意味着DB中的盐不完整...这样做就意味着失去了盐的熵（即具有8位恒定值的64位盐实际上只有56位盐的安全性），这反过来又导致了削弱盐所提供的安全性（至少对我现在能考虑到的任何算法而言）...这与OP的意图相矛盾（增强安全性）。

更新2（根据与owlstead的讨论）：

您可以在使用完全存储在DB中的唯一和随机盐对明文进行PBKDF2哈希之前添加一些“秘密”（可以在应用程序中硬编码），那可能会有所帮助，尽管在我看来它只是一种“安全性的模糊”。