使用多种算法对密码进行哈希处理

Question

使用多种算法会使密码更安全吗？(或者更少？)

澄清一下，我不是在说要做这样的事情：

key = Hash(Hash(salt + password))

我说的是使用两种不同的算法，并同时匹配两种算法：

key1 = Hash1(user_salt1 + password)
key2 = Hash2(user_salt2 + password)

然后要求两者在认证时都匹配。我认为这是一种建议的消除冲突匹配的方法，但我想知道意外的后果，比如创建一个“最弱链接”的情况，或者提供使用户数据库更容易破解的信息，因为这种方法提供的数据比单个键提供的数据更多。例如，将信息和散列结合起来，以便更容易地找到它们。此外，如果真正消除了冲突，理论上您可以暴力破解实际密码，而不仅仅是匹配的密码。事实上，为了暴力破解系统，你必须这样做。

我实际上并不打算实现这一点，但我很好奇这是否真的是对单一key = Hash(user_salt + password)的标准实践的改进。

编辑：

许多好的答案，所以在这里猜测，这应该是显而易见的回顾，但您确实创建了一个最弱的链接，因为两个算法中较弱的匹配可以针对另一个算法进行尝试。例如，如果你使用一个弱的(快速的) MD5和一个PBKDF2，我会先暴力破解MD5，然后尝试我找到的任何与另一个的匹配，所以通过使用MD5 (或其他任何东西)，你实际上会使情况变得更糟。此外，即使两者都在更安全的集合中(例如bcrypt+PBKDF2)，您也会加倍暴露于其中一个被破坏的风险。

Answer 1

这样做唯一有帮助的是减少碰撞的可能性。正如您所提到的，有几个缺点(最弱的环节是一个很大的环节)。

如果目标是减少冲突的可能性，最好的解决方案将简单地使用具有更大散列的单个安全算法(例如bcrypt)。

Answer 2

冲突不是现代散列算法关心的问题。重点不是确保数据库中的每个散列都是唯一的。真正的要点是确保在数据库被盗或意外泄露的情况下，攻击者很难确定用户的实际密码。现代散列算法将错误密码识别为正确密码的可能性实际上为零--这可能是您在这里得到的更多信息。

需要说明的是，您可能担心冲突有两个主要原因。

1. “正确”密码与提供的“错误”密码之间的冲突可能允许使用“错误”密码的用户在两个用户的密码之间发生冲突，如果用户B的密码已知，则两个用户的密码之间的冲突可能会“泄漏”用户A的密码。

问题1通过使用强大/现代的散列算法来解决(并避免非常不光彩的事情，例如仅根据用户的密码散列来查找用户记录)。关注点2是通过适当的加盐来解决的--每个密码都有一个“冗长的”唯一加盐。让我强调，正确的盐渍仍然是必要的。

但是，如果你将哈希加入其中，你只会给潜在的攻击者提供更多的信息。我不确定目前是否有任何已知的方法可以从一对散列中“三角化”消息数据(密码)，但是通过包含另一个散列并不能获得显著的收益。有一种方法可以利用额外的信息，这是不值得冒险的。

Answer 3

回答你的问题：

拥有独特的盐比拥有通用的盐更好。使用多个算法的H(S1 + PW1)，H(S2 + PW2)可能比使用单一的H1(X)，H2(Y)更好(但可能不是，正如svidgen提到的那样)

然而，，

这个问题的精神有点错误，原因有两个：

1. 如果没有安全专家的指导，您不应该提出自己的安全协议。我知道这不是你自己的算法，但大多数安全问题都是因为使用不当而出现的；算法本身通常是密不透风的。
2. 你不应该使用散列(salt+password)将密码存储在数据库中。这是因为哈希被设计为快速而不安全。使用当今的硬件(特别是使用GPU处理)在较旧的算法中查找散列冲突比较容易。当然，在冲突不是问题的情况下，您可以使用更新的安全散列算法(SHA-256或SHA-512)，但为什么要冒险呢？

您应该研究基于密码的攻击( Password-Based Key Derivation Functions，PBKDF2)，它被设计得很慢，无法阻止这种类型的攻击。通常，它需要盐化、安全散列算法(SHA-256)的组合，并迭代数十万次。

如果用户在登录时不会注意到速度减慢，那么让函数运行一秒钟是没有问题的。但对于攻击者来说，这是一场噩梦，因为他们每次尝试都必须执行这些迭代；大大减慢了任何暴力尝试的速度。

看一下支持PBKDF加密的库，这是一种更好的方法。Jasypt是我最喜欢的Java加密工具之一。

查看这个与相关的安全问题：How to securely hash passwords和这个松散相关的SO question