数据泄露规模

我讨厌关于数据泄露的夸张新闻标题，但“20亿邮箱地址”这个标题并不夸张——它从更精确的数字1,957,476,021个唯一邮箱地址向上取整，除此之外完全符合事实。还有13亿个唯一密码，其中6.25亿个是我们从未见过的。这是我们处理过的最庞大的数据集，规模远超以往。

关于数据来源和Synthient角色的说明：这些数据来自网络犯罪分子发布的多个位置。Synthient（由Ben在大学最后一年运营）索引了这些数据，并仅出于通知受害者的目的提供给Have I Been Pwned。

数据验证过程

我首先验证了自己的数据：一个自90年代使用的旧邮箱地址曾在凭据填充列表中出现过。我找到了一个与该地址关联的密码，那确实是我很久以前用过的，符合那个时代的糟糕水平。然而，其他关联密码都不熟悉。

接着我联系了HIBP订阅者请求协助验证数据。第一个回复正是我所期待的：

#1是我不再使用的旧密码。#2是较新的密码。感谢提醒，我已经更改了所有使用这两个密码的关键账户。

这完美说明了大多数人的密码行为：#2只是在#1末尾加了两个感叹号！！（这些是简单的6位和8位密码，且都不在Pwned Passwords中。）

Pwned Passwords服务

我们将密码加载到Pwned Passwords服务中，但密码与关联的邮箱地址之间绝对没有关联。这是为了保护用户和我们自己：如果HIBP被入侵，暴露数十亿可以立即解锁无数账户的凭据对将是灾难性的。

检查服务很容易、匿名，可以通过多种方式：

• 使用Pwned Passwords搜索页面
• 使用k-匿名API
• 使用1Password的Watchtower功能

技术挑战

这个语料库几乎是我们之前加载的最大漏洞的3倍大，而HIBP比2019年加载Collection #1数据时大了许多倍。处理20亿条记录，在现有150亿语料库中添加新记录，同时不影响每天服务数百万访问者的实时系统，绝非易事。

管理SQL Server索引的细微差别以优化插入和查询不是我的强项，过去几周非常艰难。这也是个非常昂贵的时期，我们将云服务调至最高配置（在Azure SQL Hyperscale上运行，最大配置80个核心持续近两周）。

一个简单的挑战示例：将所有邮箱地址加载到临时表后，我们需要为每个创建SHA1哈希。通常这涉及“update table set column = sha1(email)”这样的操作，但这完全崩溃了，最终我们改用“insert into new table select email, sha1(email)”。

通知系统优化

我们有590万订阅者，其中290万在此数据中🫨一次性发送这么多邮件很困难。问题不在于发送本身，而在于避免进入声誉黑名单或被接收服务器限制。

针对此事件，我们放慢了单个漏洞通知的邮件发送速度。原本计划在一周内以恒定速率发送邮件，但有人在直播中提出了更好的建议：

我发现处理大量邮件发送的最佳策略是：每次想要增加发送量时，查看过去30天的平均发送量，然后每天增加约50%，直到处理完队列。

所以我们制定了按小时分解的计划，每小时增加1.015倍，这样邮件以类似、逐渐增加的节奏分布。每天计算，这在24小时内增加45%，在建议的50%阈值内。

结论

这些数据现在可以在HIBP中作为Synthient凭据填充威胁数据搜索。这是与我们之前提到的Synthient数据完全独立的语料库；它们是离散的数据集，有些交叉，但这个明显更大。当然，所有密码现在都可以按照上述Pwned Passwords指南进行搜索。

这是一个极其费力、耗时且昂贵的任务。我们尽力验证数据完整性，以实用的方式使其可搜索，同时尽可能以隐私为中心。发送如此多的通知不可避免地会导致大量回应，但请将精力转向使用密码管理器、创建强唯一密码（或更好的是使用可用时的通行密钥），并启用多因素认证。