HIBP 重大更新：支持通行密钥、k-匿名搜索、大幅提速及批量域名验证 API

# HIBP 重磅更新：通行密钥、k-匿名搜索、大幅速度提升以及批量域名验证 API 作为一个业余时间构建的爱好项目，旨在提供简单的社区服务，“我是否被入侵过？”（Have I Been Pwned）确实是……怎么说呢，“升级”了。如今，我们每天支持数十万网站访客、数千万次 API 查询，以及*数亿次*密码搜索。我们每年处理由被入侵公司、白帽研究人员、黑客和执法机构提供的数十亿条泄露记录。而且，它被各种用户群体使用：信息安全专业人士、“普通父母”、客户支持服务，以及根据数据，超过一半的财富 500 强公司都在积极监控其域名的曝光情况。所以，是的，“升级”这个词很恰当！ 在处理数据的繁忙之余，我们一直在思考该在哪里投入精力开发新功能。本质上，数据泄露很简单：你有一堆暴露的电子邮件地址，归属于某个来源，旁边还有一大堆我们用元数据描述的字段。我们的目标一直是帮助人们利用这些数据，在坏事发生后做好事。今天，我们推出了一系列新功能来实现这一目标。那么，开始吧： ## 新功能，新计划 一开始（好吧，是“最近几年”），我们只有一个计划，叫做“Pwned”，在这个计划下有不同等级。例如，入门级计划一直是“Pwned 1”，直到今天，我们超过一半的订阅用户还在使用这个等级。按原始数据计算，对于一项恰好能满足大部分订阅用户需求的服务来说，这只是“每月一杯咖啡”的价格。这些用户通常是小型企业，只需进行少量 API 查询，或监控一两个域名下的少量电子邮件地址。它简单、有效，并且……对于大型组织来说不够用。于是，我们添加了 Pwned 2、3 和 4，它们都提供了更高的电子邮件搜索 RPM 和更大的域名搜索容量。然后我们添加了 Pwned 5，增加了窃密日志支持，并且在此过程中还添加了 Pwned Ultra 等级，用于进行大量 API 请求。结果，那个“单一”计划在不同等级下不断增加内容，最终变得有点混乱。 今天，我们推出了一系列新功能，以更好地满足订阅用户在容量和隐私方面的需求，同时我们也在调整现有计划以配合这一目标。现在的计划如下所示： 1. **核心版 (Core)：** 基础知识，主要是我们已有的内容，专为入门级用例设计 2. **专业版 (Pro)：** 包含许多专为大型组织以及代表客户搜索域名的用户设计的新功能 3. **高 RPM 版 (High RPM)：** 旧的“Ultra”计划等级，仅用于向电子邮件搜索 API 发送大量请求 4. **企业版 (Enterprise)：** 我们已经提供多年，是一个更定制化的产品 以上就是高层次的概述。现在让我们看看所有新内容以及所有变化： ## 支持代表第三方进行监控的 MSP 对大多数人来说，这听起来并不特别令人兴奋，但我把它放在前面，是因为稍后描述更重要内容时会提到它。过去，我们的使用条款中有这样一条限制，即你*不*被允许使用该服务： > 为了第三方的利益（包括供关联实体使用，或为了转售或以其他方式向任何第三方提供商业利益的服务） 这排除了托管服务提供商，例如，将他们监控客户域名作为其服务一部分的做法。现在，该条款已被修改，前面添加了以下文字： > 除非您购买了明确允许您这样做的付费服务 这意味着我们现在欢迎 MSP 加入专业版和高 RPM 版。他们不能仅仅拿 HIBP 用它来创建竞争产品（出于显而易见的原因，这是许多在线服务中相当标准的条款），但他们完全可以将它添加到他们提供给自己的客户的服务中。*而且*，我们正在添加新功能，使其更容易做到这一点，例如： ## 自动化域名验证 在保护隐私的同时提供实用、有效的服务一直是一种平衡，我认为我们把握得相当好。但人们在域名验证过程中需要跨越的障碍，尤其繁琐。一个组织想要添加一堆域名，必须通过 Web 界面一个接一个地完成流程，然后一个接一个地验证对它们的控制权。他们会花费*大量*时间做繁琐、重复的工作。今天，我们推出了两种以更自动化方式添加域名的新方法，第一种是**通过 DNS API 进行验证**： 成功将预定义的 TXT 记录添加到 DNS 是强有力的证据，证明试图搜索该域名的人确实控制了它。除了在浏览器中旧有的繁琐方式（等待 DNS 传播，然后返回浏览器完成验证）之外，我们现在可以通过 API 完全自动化这个过程。工作原理如下： 1. 调用 HIBP API 生成 TXT 记录令牌 2. 调用您的 DNS 提供商的 API，将令牌添加到 TXT 记录中 3. 调用另一个 HIBP API 来验证令牌是否存在 这可以很容易地用您选择的语言编写脚本，并且您可以根据需要枚举任意数量的域名。当 DNS 需要一些时间才能生效时，您还可以根据需要多次重试上面的第 3 步。这一切现在都已完整记录在最新版本的 API 中（https://haveibeenpwned.com/API/v3?ref=troyhunt.com#VerifyDomainViaDns），可以随时使用。但是，如果您不控制 DNS 怎么办？也许这在您的组织中是一个繁琐的过程，或者您是代表客户监控域名的 MSP，但您无法控制 DNS。这就是**通过电子邮件 API 进行验证**的用武之地： 我们长期以来一直有一个验证过程，涉及选择域名上的几个标准别名之一，通过电子邮件发送验证令牌。您可以通过仪表板执行此操作，获取发送到电子邮件的令牌，然后将其粘贴回仪表板，域名即验证完成。新的 API 使这个过程变得容易得多，尤其是在验证多个域名时。工作原理如下： 1. 调用 HIBP API，并指定一个预定义的别名来发送验证电子邮件 2. 单击电子邮件中的链接，批准将域名添加到请求者的帐户 就是这样。我们认为这对 MSP 特别有用，他们现在可以针对客户的域名发送大量电子邮件，只要有人收到并点击链接，验证过程就完成了。该 API 现在也已完整记录并准备就绪（https://haveibeenpwned.com/API/v3?ref=troyhunt.com#VerifyDomainViaEmail），所有专业版计划订阅者均可使用。 ## 自动验证子域名 这个功能对将电子邮件地址分布在多个子域名上的大型客户来说，一直是令人沮丧的。假设一家公司拥有 example.com，并且成功验证了对它的控制，但随后他们按地区分发电子邮件地址。他们最终得到了类似 @apac.example.com 和 @emea.example.com 这样的地址，过去需要分别验证每个子域名。 事实证明，我们在 User Voice 上收到了 154 票支持这个功能（https://haveibeenpwned.uservoice.com/forums/275398-general/suggestions/9421500-allow-root-domain-to-verify-subdomains?ref=troyhunt.com），这远高于我的预期。因此，为了延续专业版计划让大型组织更轻松的主题，该等级的任何用户现在都可以添加他们的顶级域名，相应地验证它，然后自由添加他们想要的任何子域名，而无需验证每个子域名。 ## 向大众普及 k-匿名搜索 直到今天，每次您通过公共网站订阅并开始搜索电子邮件地址（https://haveibeenpwned.com/API/v3?ref=troyhunt.com#BreachesForAccount）时，看起来都是这样的： ``` GET https://haveibeenpwned.com/api/v3/breachedaccount/[email protected] ``` 显然，这涉及将电子邮件地址发送给 HIBP 的服务。虽然我们不存储那些地址（https://haveibeenpwned.com/Privacy?ref=troyhunt.com），但如果您以这种方式向服务发送数据，我们始终*在技术上*能够看到那部分个人身份信息，并通过其 API 密钥将其与请求者关联起来。这种方法我们称之为“直接电子邮件搜索”。现在让我们看看 k-匿名搜索，我将把它分解为几个简单的步骤： 1. 首先创建要搜索的地址的 SHA-1 哈希值，对于 [email protected]，就是这样：`567159D622FFBB50B11B0EFD307BE358624A26EE` 2. 取哈希值的前 6 个字符，并将其传递给新的 API：`GET https://haveibeenpwned.com/api/v3/breachedaccount/range/567159` 这里非常重要的一点是，**这 6 个字符是发送给 HIBP 的唯一标识符**，它们完全无法用于识别实际搜索的是哪个地址（https://www.troyhunt.com/understanding-have-i-been-pwneds-use-of-sha-1-and-k-anonymity/）（该链接也解释了为什么 SHA-1 对此完全合理） 3. 然后，HIBP 响应返回所有与我们拥有的前缀匹配的哈希值的*后缀*，以及每个后缀对应的泄露事件：`{ "hashSuffix": "D622FFBB50B11B0EFD307BE358624A26EE", "websites": [ "Adobe", "Stratfor", "Yahoo", ... ] }, ...` 目前前缀包含 393 个后缀，如果其中一个与完整电子邮件地址的哈希值的剩余字符匹配，您就找到了要找的地址。 这与我们多年来在 Pwned Passwords 搜索中使用的相同方法（https://haveibeenpwned.com/Passwords?ref=troyhunt.com），目前我们每月处理大约 180 亿次请求，所以看起来很多人都已经轻松掌握了。这是一个相当简单的技术概念，具有极佳的隐私属性，并且在 API 页面上有完整文档（https://haveibeenpwned.com/API/v3?ref=troyhunt.com#BreachesForHashRange）。 k-匿名搜索现在可供所有专业版和高 RPM 版订阅者使用，速率限制与直接搜索相同。该速率限额是*共享的*，因此您可以将 100% 的请求用于 k-匿名，或者 100% 用于直接搜索，或者 50/50 分配。我们对这个 API 的隐私方面感到非常满意，并且知道它满足了许多组织长期以来的需求。 ## 取消 API 速率限制的平滑化 以前，当您获取一个 10 请求/分钟的 API 密钥时，我们实施的速率限制是每 6 秒 1 个请求。同样的逻辑也适用于所有更高级别的产品，原因很简单，就是为了更均匀地将负载分配到每一分钟，换句话说，就是“平滑”请求速率。这在早期很重要，因为底层的 Azure 基础设施必须支持这些流量，突然的爆发可能会带来问题。 但另一个问题是，人们（相当合理地）认为他们可以快速发送 10 个请求，等一分钟，然后再来一次。这导致了我们这边的支持负担和客户的挫败感，两者都不好。 通过最近的这些更新，10 RPM（以及所有其他 RPM）现在完全按字面意思实现——在任何一分钟内发送 10 个请求。以下是我们的 Azure API 管理策略： 换句话说，我们已经“取消平滑化”了。您可以快速连续地访问服务 10 次，然后等一分钟，您不会看到任何 HTTP 429“请求过多”的响应。同样，如果您是 12,000 RPM 计划（并且您真的可以快速发送那么多请求！），您也不会遇到意外的 429。我们现在之所以能做到这一点，是因为我们通过 Cloudflare 的边缘节点服务大量内容的方式（https://www.troyhunt.com/closer-to-the-edge-hyperscaling-have-i-been-pwned-with-cloudflare-workers-and-caching/），从而减轻了底层基础设施的突然峰值负载。 这是个小事情，但会为很多人（包括我们自己）解决很多不必要的困扰。这项改进也适用于每个计划，所以每个人都能受益。 ## 我们只想（更）快 我们今天面临的挑战是：如何让每天数百万人搜索数十亿条记录并获得近乎即时的结果……并且还能负担得起成本？这两个目标有些矛盾，但偶尔我们会找到一个巧妙的方法来显著改善情况。大约 18 个月前，我写过关于我们如何使用 Cloudflare Workers 和缓存来超大规模扩展 HIBP（https://www.troyhunt.com/closer-to-the-edge-hyperscaling-have-i-been-pwned-with-cloudflare-workers-and-caching/）。基本前提是，当人们搜索服务时，我们在 Cloudflare 的 300 多个边缘节点中构建一个缓存，其中包含刚刚搜索的完整哈希范围（参见上面的 k-匿名部分）。每次加载新的泄露数据时，我们都会刷新缓存，当缓存重新构建到完整的 16^6 个可缓存哈希范围时，我们的源站负载趋近于零，所有内容都从边缘节点提供。差不多是这样，因为我们还有以下文章中描述的问题： > 然而，后两种模型（公共和企业 API）有额外的负担，即需要根据 Azure API 管理 (APIM) 验证 API 密钥，而 APIM 只存在于美国西部的源站服务中。这意味着对于这些端点，在从一个可能相距不远的地点返回搜索结果之前，我们需要绕到地球另一边去验证密钥并确保请求在速率限制内。 至少我们*曾经*有这个问题，现在我们用简单的修复方法解决了。上面引用的问题源于这样一个事实：为了确保每个人都遵守速率限制，我们在*返回*任何数据*之前*执行 APIM 检查。这意味着即使数据缓存在附近，也总是要等待数据包往返美国。但我们意识到，遵守速率限制可以*最终*强制执行；一两个超过限制的请求漏过去真的没太大关系，*然后*我们再执行限制。这个顿悟之所以重要，是因为考虑到这一点，我们可以立即开始向客户端返回数据，同时异步进行 APIM 检查。如果请求超过速率限制，Cloudflare 将阻止*后续*请求，直到客户端开始在其限制内发起请求。因此，速率限制检查不再是阻塞调用；它是一个后台进程，不会延迟我们返回结果。 这意味着大幅缩短了首字节时间： 等待时间减少了近 40%！这是一个很好的例子，说明对我们运行方式持续投入如何产生切实的成果，从而显著改善用户从服务中获得的价值。 ## 通行密钥！ 还有一件事…… 这一切都是全新的、免费的，并且对所有用户开放，无论他们是否拥有付费订阅。还记得我去年被钓鱼了吗？（https://www.troyhunt.com/a-sneaky-phish-just-grabbed-my-mailchimp-mailing-list/）我当然记得，我发誓要利用那次经历，尽可能广泛地推广通行密钥。所以，说到做到（投入金钱和时间），我们现在推出了通行密钥，作为登录仪表板的另一种方式： 这省去了每次登录时都需要通过电子邮件发送“魔法”链接的麻烦，虽然它不算双因素认证（通行密钥变成了登录的单一因素），但它大大简化了您访问仪表板的方式。而且因为