许多网站(我的头顶:GMail和我使用的银行)都有针对您选择的密码的安全措施;例如,选择“mypassword”将被归类为 insecure 。
但是,在我自己的应用程序中,我正在基于随机数和其他用户特定字符串的哈希码实现用户特定的salt 。当然,这会使密码分类(如上所述)成为对字典攻击的有效威慑而多余的吗?
我是对的吗?为什么谷歌和其他大型网站都在为密码分类烦恼?他们不打扰用户特定的盐吗?
答案 0 :(得分:9)
不,不,不,不。
密码哈希+ salting和强密码解决了两个完全不同的问题:
密码哈希和salting确保很难从内部存储的数据中找到原始密码。这很有用,例如减轻数据泄露:攻击者确实拥有用户名,但没有密码或易于恢复的哈希值。
仍然需要针对外部攻击者的强密码 - 最简单的形式是抓取登录表单并尝试最常用密码的脚本,例如password
,letmein
,{{1 },mypassword
等
正如您所看到的,这些问题根本不会重叠:弱密码(12345
)对外部威胁仍然不安全,无论您在后端对它们进行了多少次哈希处理。其他问题也适用:如果您已成功以密码hello
以Piskvor身份登录,则很可能这也是我的银行,电子邮件和行李的密码。
答案 1 :(得分:3)
为了能够检查密码,您需要将盐存储在某处。在您的情况下,存储随机字符串,并且还存储用户特定字符串。
因此,如果有人能够访问存储的随机字符串和用户特定字符串,并知道您使用哪种算法从这些部分生成盐,他将能够尝试大量不安全且易于猜测的密码( “password”,“qwerty”,“123456”等)并查看它们是否与存储的哈希匹配。
因此仍然需要安全密码。
盐很有用,因为如果密码在被散列之前没有被腌制,那么破解者只需要将散列与不安全密码的散列字典进行比较就可以找到密码。
答案 2 :(得分:1)
比较密码强度(又名“怪异密码”)和盐水哈希就像比较苹果和橙子。是的,两者都是水果。
不要只使用其中一种方法,同时使用 - 你真的睡得更好。您可以为每个用户实现不同的salt。我不确定这是否会大大增加安全性,但如果做得恰到好处,它也不会伤害它。
SO和网络上有很多文章提供了很多关于这两个主题的知识。为了更深入地了解盐渍,我推荐这篇文章: