使用多种算法会使密码更安全吗？(或更少？)
为了清楚起见,我不是在谈论做这样的事情:
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),你也可以将其中一个暴露给其中一个.
这有助于减少碰撞的可能性.正如你所提到的,有几个缺点(最薄弱的环节是一个很大的缺点).
如果目标是减少冲突的可能性,那么最好的解决方案就是使用bcrypt具有更大散列的单个安全算法(例如).
碰撞不是现代哈希算法的关注点.关键是不要确保数据库中的每个哈希都是唯一的.真正的重点是确保在您的数据库被盗或意外泄露的情况下,攻击者很难确定用户的实际密码.和一个现代化的散列算法识别的几率错误密码作为正确的密码实际上为零-这可能是更你在这里得到什么.
需要说明的是,您可能会关注碰撞有两个重要原因.
关注1通过使用强/现代哈希算法(并避免非常反辉煌的事情,例如仅基于其密码哈希来查找用户记录)来解决.关注2通过适当的腌制解决 - 每个密码的"冗长"独特盐.让我强调,适当的腌制仍然是必要的.
但是,如果你在混合中添加哈希,那么你只是给潜在的攻击者提供更多信息.我不确定目前有任何已知的方法可以从一对哈希中"三角测量"消息数据(密码),但是你并没有通过包含另一个哈希来获得显着的收益.有一种方法可以利用其他信息,这是不值得冒险的.
| 归档时间： |
|
| 查看次数： |
766 次 |
| 最近记录： |