security - MD5 哈希加盐 - 在哪里存储盐

Question

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

我最近读了很多关于散列和加盐的内容，我明白我应该为每个密码使用不同的盐，并且我不应该使用像用户名这样的东西，因为理想情况下盐应该是完全唯一的。但我不明白的是为什么建议将这种盐与密码一起存储在数据库中？

如果攻击者获得哈希和盐不是很糟糕吗？我知道这对攻击者来说更难，因为独特的盐确保他无法针对所有密码检查单个计算的哈希值。但是，隐藏一部分盐不是更好吗？

我正在考虑将盐分成两部分。第一部分像往常一样存储在数据库中，第二部分(较小的)被硬编码在我的应用程序中。攻击者几乎不可能获得完整的盐，因为他必须渗透应用程序服务器和数据库。

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

Answer 1

攻击者“被允许”知道盐 - 您的安全性设计必须确保即使知道盐，它仍然是安全的。

盐有什么作用？

Salt 使用预先计算的“彩虹表”帮助防御暴力攻击。
对于攻击者来说，盐使得暴力破解的成本更高(在时间/内存方面)。
计算这样一张表的成本很高，并且通常仅在可用于多个攻击/密码时才进行。
如果您对所有密码使用相同的盐，攻击者可以预先计算这样的表，然后将您的密码暴力破解为明文...
只要您为每个要存储哈希值的密码生成一个新的(最好的加密强度)随机盐，就没有问题。

根据您使用 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时间”(可用于彩虹表/暴力等攻击)变得越来越广泛(例如，参见事实上，亚马逊的云服务跻身全局最快 super 计算机前 50 名，任何人都可以以相对较小的金额使用)!

不建议将盐分成两部分，一个是硬编码/常量，一个是唯一的部分!

根据所使用的算法，这可能是一个弱点，可帮助攻击者破坏您的安全性。我强烈建议不要这样做，除非您可以从数学上证明它不会削弱您的安全性(恕我直言，这很难做到)。

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

更新(根据评论):

RFC 2898 is an important reference on PBKDF2 。在第 4.1 节中，它讨论了向盐中添加一部分

the salt should contain data that explicitly distinguishes betweendifferent operations and different key lengths

恕我直言，这与OP的要求无关。 RFC 讨论了有关 key 长度等的信息，这些信息作为附加部分与随机盐一起合并。这与包含描述其所包含数据的特定方面的 header 部分的文件格式非常相似。这不会削弱安全性，并且在需要不同系统之间互操作的场景中可能非常有用。

相比之下，OP所要求的基本上是只将一部分盐存储在数据库中，同时将其他(较小的)部分硬编码在应用程序中，这意味着数据库中的盐不完整......这样做意味着失去盐的熵(即 8 位恒定的 64 位盐实际上只与 56 位盐一样安全)，这反过来又导致削弱盐提供的安全性(至少对于我能想到的任何算法)立即关闭)...这与OP的意图(增加安全性)相矛盾。

更新 2(根据与 owlstead 的讨论):

您可以在使用 PBKDF2 进行散列之前使用完全存储在数据库中的独特且随机的盐将一些“ secret ”(可以在您的应用程序中硬编码)添加到明文中......这可能会有所帮助，尽管它占了国际海事组织通过默默无闻实现安全。