国内需要泄露查询吗
核心摘要
- Have I Been Pwned 是一个让你输入邮箱、查询自己是否出现在数据泄露事件中的网站,截至 2026 年 10 月已收录 1048 起泄露、178 亿条泄露地址
- 它由安全专家 Troy Hunt 创建,从一个业余项目成长为每天数十万访客、数千万次 API 查询、数亿次密码搜索的基础设施,半数以上财富 500 强企业用它监控自己的域名
- 它提供个人邮箱查询、密码泄露查询、企业域名监控和开放 API,其中密码查询采用 k 匿名设计,只发送哈希前缀,不回显明文
- 国内有 12387 网络安全事件报告平台和漏洞共享平台,却没有面向个人的公开泄露查询,法律上采取的是数据处理者主动通知模式
Have I Been Pwned 是一个让你输入邮箱、查询自己是否出现在数据泄露事件中的网站,截至 2026 年 10 月已收录 1048 起泄露、178 亿条泄露地址。
它由安全专家 Troy Hunt 创建,从一个业余项目成长为每天数十万访客、数千万次 API 查询、数亿次密码搜索的基础设施,半数以上财富 500 强企业用它监控自己的域名。
它提供个人邮箱查询、密码泄露查询、企业域名监控和开放 API,其中密码查询采用 k 匿名设计,只发送哈希前缀,不回显明文。
国内有 12387 网络安全事件报告平台和漏洞共享平台,却没有面向个人的公开泄露查询,法律上采取的是数据处理者主动通知模式。
问题由此而来:国内到底需不需要这样的服务?如果需要,怎么建,才能让它成为保护个人的工具,而不是异化为黑产的“社工库”?
一、HIBP 是什么
- 一个人做出来的基础设施:HIBP 最初是 Troy Hunt 在业余时间做的社区服务,把公开可查的数据泄露事件汇聚起来,让任何人都能查询自己的邮箱是否受影响。
- 规模:根据其官网,截至本文检索时已收录 1048 个泄露网站、178 亿条泄露地址,每年处理数十亿条来自泄露公司、白帽研究者、黑客和执法机构的记录。
- 使用人群:从安全专业人员、普通用户、客服机构,到半数以上财富 500 强,后者持续监控自身域名的暴露情况。
- 收录中国案例:HIBP 收录了 CSDN、小米、京东等中国相关泄露事件,说明它的覆盖面是全球性的。
- 基本逻辑:数据泄露后,数据被归属于某个来源并标注泄露了哪些字段,HIBP 帮助人们在坏事发生后利用这些数据采取补救行动,比如改密码、开两步验证。
二、四层服务
- 个人邮箱查询:输入邮箱,返回它出现在哪些泄露事件中、泄露了什么类型的数据,帮助个人判断风险和补救优先级。
- 密码泄露查询:Pwned Passwords 从最初的 3.06 亿条密码增长到数十亿条,含执法机构贡献的数据,用于判断一个密码是否已在真实泄露中出现。
- 企业域名监控:企业验证对域名的所有权后,可查看该域名下所有邮箱的暴露情况,监控域名和子域名,接收新泄露通知。
- 开放 API:提供 RESTful API,让开发者和企业把泄露查询集成进自己的系统,按 Core、Pro、高并发和企业等不同计划提供服务。
三、它为什么能成立
- k 匿名查询:密码查询采用 k 匿名设计,本地先对密码做哈希,只把哈希前几位发送给服务端,服务端返回匹配前缀的后缀集合,由本地完成比对,明文密码不离开设备。
- 邮箱查询也引入 k 匿名:2026 年的更新把同样思路扩展到邮箱查询,只发送邮箱哈希的前几位,降低把可识别个人信息发送给服务的隐私风险。
- 不回显明文:HIBP 只告诉用户“在哪个站泄露、泄露了什么类型”,并不直接展示完整密码和敏感字段,这是它与黑产“社工库”的根本区别。
- 数据来源合法可追溯:数据来自公开泄露、企业主动提供、研究人员和执法机构,每条记录都标注来源和时间。
- 边缘分发与工程化:它利用 Cloudflare 边缘节点缓存哈希范围,把检索延迟和源站负载降到极低,密码查询每月服务约 180 亿次请求。
四、中国现状
- 有事件报告平台:12387 网络安全事件报告平台接收网络安全事件,包括数据泄露、数据窃取、数据篡改等,但它是“上报”和“处置”入口,不是个人自助查询泄露的服务。
- 有漏洞平台:工信部网络安全威胁和漏洞信息共享平台、国家信息安全漏洞共享平台等聚焦漏洞,而非个人信息泄露记录的聚合查询。
- 安全厂商做终端防护:360、火绒等厂商的产品主要做终端安全、威胁检测和漏洞管理,没有面向公众的泄露数据聚合查询服务。
- 个人查询入口缺失:国内个人想知道自己的手机号、邮箱在哪些平台泄露,往往只能依赖零散的第三方工具,这些工具来源不一、合法性和安全性难以保证。
- 手机号是核心标识:与海外以邮箱为主不同,国内账号体系高度依赖手机号,这意味着查询服务必须围绕手机号、邮箱等多标识设计,也更敏感。
五、法律路径:处理者通知
- 主动通知义务:《网络数据安全管理条例》规定,数据处理者应建立应急预案,发生安全事件时立即启动、向主管部门报告。
- 通知利害关系人:事件对个人权益造成危害的,处理者应及时以电话、短信、即时通信、电子邮件或公告等方式通知利害关系人,说明事件、风险、危害和补救措施。
- 犯罪线索移送:处置中发现涉嫌违法犯罪线索的,应向公安机关、国家安全机关报案并配合调查。
- 这是“处理者主动”模式:中国法律把泄露通知的第一责任放在数据处理者身上,而不是要求个人主动去第三方平台查询。
- 通知可能不完整:现实中一个人可能在多个平台泄露,不同企业的通知能力、范围和时点不一,个人未必能拼出完整的暴露图景。
六、国内到底需不需要
- 个人侧确实需要:个人信息泄露、暗网交易和信息窃取木马高发,个人往往是最后一个知道自己被泄露的,难以及时改密码、防欺诈、防账户接管。
- 需要统一入口:处理者主动通知和个人自助查询并不矛盾,后者是前者的补充,让个人有一个权威、可追溯的统一查询入口。
- 最大风险是“社工库”异化:聚合泄露数据的服务,一旦设计不当,可能被黑产用来批量查询、拼接个人信息,成为更强大的社工库。
- 必须与社工库划清界限:只展示泄露来源和类型、不回显明文、不允许批量枚举、强实名认证、本人查本人,这是不可逾越的红线。
- 结论是“需要,但不能照搬”:国内需要泄露查询能力,但必须在数据来源、身份核验、展示范围和防滥用上走更严格的路径。
七、应该由谁建、怎么建
- 监管或行业组织主导:纯商业公司聚合泄露数据存在合规风险,更适合由行业组织、国家机构主导,或有资质的安全厂商在授权和监管下运营。
- 强实名认证:查询者必须实名认证,且只能查询本人,防止冒用他人身份查询。
- 最小化展示:只告知“在哪个平台、泄露了什么类型、应如何补救”,不回显明文密码、证件号等敏感字段。
- k 匿名与防枚举:查询采用隐私保护设计,配合频率限制、行为分析和反爬虫,防止批量拉取和数据库重建。
- 金融行业可先行:银行业具备身份核验、风控、反欺诈和安全运营基础,可率先建设面向金融账户的泄露查询和预警,与监管平台衔接。
八、银行的机会与责任
- 拦截弱密码:银行可在开户、改密环节集成密码泄露查询,发现客户使用已在外部泄露的密码时提示或强制更换,降低撞库风险。
- 撞库与账户接管防控:监测客户账号、密码在外部泄露的情报,对匹配账户触发登录保护、二次验证和交易风险复核。
- 暗网泄露监测:对员工、企业域名和对公客户做泄露监测,发现内部账号、邮箱或客户信息暴露时及时预警和处置。
- 对客安全服务:可向客户提供“我的金融账户是否暴露”的查询和提醒,作为增值服务,提升客户信任和安全感。
- 把泄露情报纳入风控:外部泄露数据是重要的风险信号,应纳入反欺诈、反洗钱和交易风险模型,但要注意数据来源合法、最小化使用。
九、给银行的落地清单
- 在开户、改密、重置密码等环节接入泄露密码校验,优先采用 k 匿名方式。
- 建立外部泄露情报的采集、评估和使用流程,确保来源合法、可追溯。
- 对命中泄露情报的账户启用分级防护,如强验证、限额、延迟和人工复核。
- 监控员工、企业域名和关键系统账号在外部的暴露情况,纳入安全运营。
- 为客户提供本人金融账户暴露查询和补救指引,做好身份核验。
- 对客户信息泄露事件严格履行报告和通知义务,衔接监管平台。
- 建立撞库、账户接管和信息窃取木马的专项监测与处置机制。
- 把泄露情报纳入风险模型,明确数据口径、权限和留存,避免滥用。
- 对客户开展密码安全、多因素认证和 passkeys 的教育引导。
- 参与行业泄露查询和预警标准建设,推动金融先行、跨行业衔接。
十、冷静的边界
- 查询不是万能:泄露查询只能发现已知、已收录的事件,无法覆盖未被发现或未公开的泄露,也不能替代企业自身的安全防护。
- HIBP 口径也有限:其数据依赖外部提供,覆盖面和时点存在局限,性能与覆盖数据来自官方自述,不应被神化。
- 国内方案要适配国情:以手机号为核心、强实名、强监管的环境,决定了国内方案不能简单复制 HIBP 的形态。
- 防止二次集中:新建的查询服务本身也可能成为高价值目标,需按关键信息基础设施的标准保护。
- 责任不能转移:无论有没有第三方查询,数据处理者的安全和通知责任都不会因此减轻。
结语
HIBP 的成功,本质上回答了一个朴素的问题:在数据泄露频发的时代,个人有没有权利、有没有渠道,第一时间知道自己的信息在哪里暴露了? 它用 k 匿名、不回显明文、来源可追溯和企业级监控,把一件极易滑向“社工库”的事情,做成了保护个人和企业的基础设施。对国内而言,答案不是简单地“要不要一个 HIBP”,而是如何在“处理者主动通知”的法律框架上,补上一个权威、实名、最小化、防滥用的个人查询入口,让主动通知与自助查询相互补位。银行在其中既是责任方,也是最有条件先行的行业:拦截泄露密码、防控撞库和账户接管、监测暗网暴露、为客户提供账户安全查询,都是可以立刻落地的动作。守住“不回显明文、不批量枚举、只服务本人”的红线,泄露查询才会成为提升个人安全感和金融安全水位的公共能力,而不是新的风险源头。
(口径说明:本文 HIBP 相关数据来自其官网、已收录泄露页面及 Troy Hunt 2026-03-31 的更新说明,其中 1048 起泄露、178 亿条地址、每月约 180 亿次密码查询、访客与 API 规模等为官方口径,随时间变化。中国法律部分来自《网络数据安全管理条例》(国务院令第790号,2025-01-01 施行)及 12387 平台公开信息。国内是否建设、由谁建设属于制度与路径分析,本文已区分“已查证事实”与“政策建议”。HIBP 收录的中国案例以其页面记录为准。本文为行业与风险管理分析,不构成法律或投资建议。)
参考文献
- Have I Been Pwned 官网(数据泄露查询) [Have I Been Pwned]
- Who's Been Pwned(HIBP 已收录泄露事件,1048 起、178 亿条) [Have I Been Pwned]
- HIBP Mega Update: Passkeys, k-Anonymity Searches and Bulk Domain Verification API(Troy Hunt,2026-03-31) [Troy Hunt]
- 网络数据安全管理条例(国务院令第790号,2025-01-01 施行) [中国政府网]
- 12387 网络安全事件报告平台 [CNCERT]