使用 haveibeenpwned 验证密码强度是否合理?

信息安全 密码 我被打倒了
2021-08-31 12:52:27

我越来越多地听到haveibeenpwned 密码列表是检查密码是否足够强大的好方法。

我对此感到困惑。我的理解是 haveibeenpwned 列表来自已被泄露的帐户,无论是因为它们以纯文本形式存储,使用弱密码还是其他原因。这似乎与我的密码强度无关。可能存在以纯文本形式存储的非常强的密码,因此会受到损害,只要不与原始电子邮件/用户名结合使用,它们就可以很好地使用。他们的哈希值是已知的(呃,任何特定密码的哈希值都是已知的!)这一事实并不重要,如果您存储它们的地方是盐渍的。尽管排除这些密码确实没有什么坏处,因为黑客可能会在暴力破解时从这个列表开始,并且很容易选择另一个。

但反过来是我所关心的——总是很容易破解不在列表中的密码。“longishpassword”此时还没有使用此密码的帐户被泄露。然而,这并不意味着发生散列泄漏,这个密码是安全的。很容易坏掉。

根据 haveibeenpwned 列表检查密码(没有电子邮件/用户名)以查看它是否值得使用的基本原理是什么?这是对列表的良好使用还是被误导了?

编辑:

现在改变问题的范围为时已晚,但我只是想澄清一下,这个问题来自检查其他人的密码(例如当用户在您的网站上注册时,或者您的组织中的人被给予AD 帐户)不用于验证个人密码的强度。因此,任何说“只使用密码管理器”的评论对我都没有帮助。

4个回答

“强”一直有“不可猜测”的意思。长度和复杂性有助于使密码更“不可猜测”,但长而复杂但常用的密码与Pa$$w0rd.

如果密码在 HIBP 列表中,则攻击者知道该密码被人们选择的可能性更高,因此可能会再次使用。所以这些列表将首先被击中。

因此,如果您的密码在列表中,那么它是“可猜测的”。

如果您的密码不在列表中,那么从字典攻击方法来看,它不太容易猜测,而不是其他人选择的密码,并且暗示(尽可能多地)是“不易猜测的”。当然,许多其他因素会使您的密码“更容易猜到”,即使它不在 HIBP 列表中。

与往常一样,随机生成的密码是最“不可猜测的”,并且最大长度和随机生成的密码极难破解。如果你是随机生成它,那为什么不去最大长度呢?

要正确回答这个问题,您需要像想要破解您的密码的黑客一样思考。

但是为了避免直接陷入数学思维方式,让我们先考虑一下乐高电影游戏节目“我的裤子在哪里?”中的竞争对手。

显然,当竞争对手想要找到他们的衣服时,他们会做的第一件事就是去他们的衣橱。如果这不能证明有成效,他们可能会检查他们的抽屉,然后是房间角落的椅子,然后是洗衣篮,如果狗是淘气的偷裤子的那类,也许还会检查狗的篮子。这一切都会在他们开始查看冰箱之前发生。

这里发生的事情当然是竞争对手会首先寻找最有可能的地方。他们本可以在网格中系统地检查房子的每一平方英尺,在这种情况下,他们平均必须检查一半的房子。另一方面,通过这种策略,他们很有可能在第一时间就获得它,并且当然不会期望覆盖一半的房子。

理想情况下,黑客想要做同样的事情。假设他们知道他们要使用的密码是 8 个小写字母。他们可以尝试一次解决一个问题,但有 208,827,064,576 个可能的选项,因此给定的完全随机猜测大约有 2080 亿分之一的可能性是正确的。另一方面,众所周知,“密码”是最常见的密码。(除非它被禁止)事实上,查看来自 haveibeenpwned 的数据,正确答案是“密码”的机会大约是 151 分之一。不是 1510 亿,只有 151。所以这比一些随机猜测的可能性高 10 亿倍,他们不从它开始是愚蠢的。(显然,由于您不希望找到您的密码,因此您希望避免选择它们的开头)

现在,问题是这是否可以概括为“密码”之外的东西。处理泄露的密码列表是否值得?有关一些信息,请考虑原始版本 write up 中的这句话

我转到了 Anti Public 列表,其中包含 562,077,488 行和 457,962,538 个唯一电子邮件地址。这给了我另外 96,684,629 个唯一密码,这些密码还没有出现在 Exploit.in 数据中。反过来看,该组中 83% 的密码之前已经被看到过。

这告诉我们,粗略地说,随机选择的密码有超过 80% 的机会出现在列表中。该列表有几亿个条目,而随机 8 个字母密码的选项有几千亿个。因此,粗略地说,我们的黑客尝试 8 个字母的密码时,他们有 0.1% 的机会没有该列表,而他们有 80% 的机会获得该列表。显然他们想要使用它。再说一次,你不妨避免它。毕竟你还有上千亿的选项可以选择,只要去九个字母就可以得到上千亿!

这就是检查清单的理由。

现在你的第一个担心是“总会有很容易破解的密码不在列表中”。这可能是真的。例如,“kvym”不在列表中。只有4个字母。只有 50 万个密码是 4 个小写字母或更短,所以如果人们可能更喜欢短密码,那么黑客会在很短的时间内完成泄漏列表。他们很可能会尝试两者。

答案是显而易见的。使用这两个规则。不要使用出现过漏洞的密码,也不要使用很短的密码。如果你有一个任意长度的随机密码,你就有足够多的选择,黑客没有捷径可以找到。

这绝对是您的验证步骤之一,但不能完全依赖。

鉴于大多数用户重复使用密码,并使用相对较小的词库构建密码,字典攻击是猜测密码的一种特别有效的方法。由于 HIBP 会定期更新,因此它将有许多经常使用的密码,因此字典攻击者可能会尝试使用这些密码。因此,这是一个很好的检查起点。但是,仅仅因为您的密码不在列表中,并不意味着您的密码不会被轻易猜到。只是已知密码将在他们的密码列表中排在前面,与从互联网挖掘的文本、数字/符号的单词组合、换位等一起尝试。随着更多密码泄露的发生,HIBP 和其他此类工具变得更加有用,和黑客尝试的密码列表对他们也变得更有效。

我很惊讶地看到一些我知道的密码很容易被猜到并且肯定在多个站点中使用,而不是在 HIBP 列表中,所以我可以保证它不是密码强度的决定因素(就像问题中的示例一样)。但是,如果我想出了一个我认为是强密码的东西,并且它在列表中,我绝对不会使用它。

其他人则讨论为什么这是一个好主意。我会采取不同的方向。

从合规性的角度来看,相关的 NIST 标准、NIST 特别出版物 800-63、数字身份指南明确要求,当用户设置密码时,对照先前泄露的密码列表进行检查。相关部分是SP 800-63B, Authentication and Lifecycle Management, section 5.1.1.2,它说

在处理建立和更改记忆秘密的请求时,验证者应将预期秘密与包含已知常用、预期或泄露的值的列表进行比较。例如,列表可能包括但不限于:

  • 从以前的违规语料库中获得的密码。
  • 字典单词。
  • 重复或连续的字符(例如'aaaaaa'、'1234abcd')。
  • 特定于上下文的词,例如服务名称、用户名及其派生词。

如果在列表中找到选择的秘密,CSP 或验证者应告知订户他们需要选择不同的秘密,应提供拒绝的原因,并且应要求订户选择不同的值。

根据定义,通过 Pwned Passwords API 找到的任何内容都是“已知被 [...] 泄露的值”。

如果您的组织必须担心合规性,请注意密码的两个主要标准是不兼容的。支付卡行业数字安全标准 (PCI-DSS) 规定密码必须每 30 天更改一次,必须是大写、小写、数字和符号等的组合,而 NIST 标准规定密码不应该根据日期任意过期,并且不应该有关于允许的字符类的复杂规则,但应该足够灵活以允许用户使用字符类的任意组合。

当然,由您的组织决定要遵守哪些标准。

如果您正在为美国商务部下属的机构进行开发,则必须遵循 NIST 标准,句号。这是法律。(关于法律的所有事情,请咨询您组织的法律部门,不要盲目相信我。)

如果您正在使用任何处理支付信息的系统,我们强烈建议您遵循 PCI-DSS。如果您只有一个网上商店,并且正在使用第三方支付处理器,那么这不适用于您。它没有法律效力,但您应该咨询您的律师,因为如果出现问题,不遵守 PCI-DSS 可能会使您被发现疏忽大意。

如果这些都不适用,那么对我来说,NIST 标准最有意义。与您的安全团队进行多次深入讨论,进行研究,并找出对您最有意义的方法。

作为找出什么对您最有意义的示例,在我的组织中,我们不会拒绝在 Pwned Passwords API 中点击次数少于 10 的密码。我们仍然会显示一条警告消息,让用户知道,即使密码被泄露,我们仍然接受它。而且,他们应该考虑改用密码管理器来生成真正随机的密码。我很幸运能在一个可以与用户交谈的组织中,我们可以就密码管理进行诚实的讨论。其他人将不得不调整他们的方法以满足他们组织的需求。