今天，作为特洛伊·亨特提供的Have I Been Pwned服务的一部分，Pwned密码的v2已经发布。这个数据库包含超过5亿个真实世界泄露的密码，为纠正业界如何应对现代密码安全威胁提供了一个至关重要的工具。我在下面的帖子中写了关于我们需要重新考虑密码安全性和Pwned Passwords v2的内容：开发人员如何把密码安全性搞得如此错误。相反，在本文中，我想讨论Cloudflare在使用此工具时为保护用户信息所做的技术贡献之一。Cloudflare通过提供CDN和安全功能继续支持Pwned密码，以便可以轻松地将数据以原始形式下载给组织，以保护其客户。此外，作为本项目第二次迭代的一部分，我还与Troy一起设计和实现API端点，这些端点支持匿名范围查询，为那些使用API的用户提供额外的安全层，这对客户端是可见的。这一贡献允许Pwned Passwords客户端使用范围查询来搜索被破坏的密码，而不必向服务公开完整的未经保存的密码哈希。获取密码安全权限随着时间的推移，业界已经意识到，复杂的密码组合规则（如要求最少的特殊字符数）对改善用户在制作更强大的密码方面的行为几乎没有起到什么作用；在防止用户将个人信息输入密码方面，这些规则几乎没有起到什么作用，避免使用常用密码或防止使用以前被破坏的密码[1]。最近，凭证填充已经成为一个真正的威胁；用户名和密码是从被破坏的网站获得的，然后注入到其他网站，直到你找到被泄露的用户帐户为止。这基本上是可行的，因为用户在不同的网站上重复使用密码；当一个网站上的一组凭据被破坏时，这可以在其他网站上重复使用。以下是一些不安全网站如何破坏凭据的示例：不使用速率限制或质询登录请求的网站可以使用对给定用户的常用密码的暴力攻击来破坏用户的登录凭据，黑客网站的数据库转储可以离线，密码散列也可以破解；现代的GPU使得字典密码非常有效（即使使用Argon2、PBKDF2和BCrypt等算法），许多网站继续不使用任何形式的密码散列，一旦被破坏，它们可以被捕获的原始形式，代理攻击或劫持web服务器允许在密码被哈希处理之前捕获密码。这就成了密码重用的一个问题；在获得真实的用户名/密码组合后，它们可以被注入到其他网站（如支付网关、社交网络等），直到获得更多帐户的访问权限（通常比原始受损网站的价值更高）。根据最近的NIST指导，在存储或更新密码时，要求确保密码不包含常用、预期或泄露的值[2]。研究发现，88.41%收到恐惧申诉的用户后来设置了唯一密码，而没有收到恐惧申诉的用户中只有4.45%会设置唯一密码[3]。不幸的是，有很多泄露的密码；从Pwned密码下载的原始数据目前包含超过30gb的密码哈希。匿名密码哈希根据旧的Pwned passwords API（以及所有类似的服务）检查密码的关键问题在于如何检查密码；用户被有效地要求提交未经保存的密码哈希，以确定密码是否被违反。哈希值必须是不加盐的，因为对它们加盐会使它们在计算上很难快速搜索。目前有两种方法可用于验证密码是否泄漏：向第三方服务提交密码（以未添加哈希值的形式），在该服务中可以存储哈希值，以便以后进行破解或分析。例如，如果您使用WordPress插件向第三方API服务发出泄漏密码的API调用，则可以使用请求的IP来标识WordPress安装，然后在密码被破解时（例如从稍后披露的信息）破坏它；或者，下载密码哈希的整个列表，解压缩数据集，然后运行搜索以查看是否列出了密码哈希。不用说，这场冲突看起来就像是一块安全意识很强的石头和一块不安全的硬地之间。中间路线私有集交集（PSI）问题学术计算机科学家们考虑了这样一个问题：两方（或更多方）如何在不共享各自拥有的信息的情况下，验证数据的交集（来自双方已经拥有的两个或多个不相等的数据集）。虽然这项工作令人兴奋，但不幸的是，这些技术都是新技术，而且还没有经过密码社区的长期审查，而且密码原语还没有在任何主要的库中实现。此外（但至关重要的是），PSI实现的开销远远高于我们的k-匿名方法（尤其是通信[4]）。即使是目前学术界最先进的技术，API服务的性能边界也不可接受，通信开销相当于下载整个数据集。k-匿名相反，我们的方法通过使用一个称为k-匿名性的数学属性并以范围查询的形式将其应用于密码哈希，从而增加了额外的安全层。因此，Pwned Passwords API服务永远无法获得关于未被破坏的密码哈希的足够信息，以便以后能够对其进行破坏。k-匿名性用于多个领域，以发布匿名但可行的数据集；例如，这样医院可以发布用于医学研究的患者信息，同时保留披露个人信息的信息。从形式上讲，一个数据集可以被称为具有k-匿名性的属性，如果对于已发布表中的每个记录，都有k-1个其他记录与之相同。通过使用这个属性，我们可以将散列分成匿名的"桶"。客户机能够匿名化用户提供的哈希，然后将所有泄漏的哈希下载到与该哈希相同的匿名"bucket"中，然后进行脱机检查，以查看用户提供的哈希是否在被破坏的bucket中。更具体地说：从本质上讲，我们将讨论密码派生函数；我们没有寻求将哈希值分解到它们唯一的点（针对相同的输入），而是在客户机请求的内容中引入模糊性。给定哈希基本上是固定长度的十六进制值，我们可以简单地截断它们，而不必求助于决策树结构来过滤数据。这意味着bucket大小不等，但允许客户端在单个API请求中进行查询。这种方法可以用简单的方式实现。假设一个用户在登录表单中输入密码测试，并且他们登录的服务被编程来验证他们的密码是否在泄漏的密码哈希数据库中。首先，客户机将生成a94a8fe5ccb19ba61c4c0873d391e987982fbd3的散列（在我们的示例中使用SHA-1）。然后，客户机将把散列截短为预定数量的字符（例如，5），从而得到哈希前缀a94a8。然后使用这个哈希前缀查询远程数据库中以该前缀开头的所有哈希（例如，通过向example.com/a94a8.txt文件）。然后下载整个哈希列表，然后比较每个下载的哈希值，看是否有匹配本地生成的哈希值。如果是这样的话，就知道密码被泄露了。由于这可以很容易地通过HTTP实现，所以客户端缓存可以很容易地用于性能目的；API非常简单，开发人员可以轻松地实现。下面是如何使用范围查询（Gist）查询Pwned Passwords API的简单Bash实现：#!/垃圾桶/垃圾桶echo-n密码：read-s密码回声hash="$（echo-n$password | openssl sha1）"大写="$（echo$hash | tr'[a-z]''[a-z]'）"前缀="${大写：0：5}"响应=$（curl-shttps://api.pwnedpasswords.com/range/$前缀）读-r行；dolineOriginal="$prefix$line"如果["${lin初始值：0：40}"=="$upperCase"]；然后echo"密码被破坏。"出口1金融机构完成