账号密码泄露查询——能查到的比想的少

输个邮箱，回车，页面跳出几行红字说这个地址在某次泄露里出现过——不少人到这一步就关页面了，觉得自己做过账号密码泄露查询，剩下的交给命。这个想法我以前也有，后来发现查询能给的东西很有限：它大致告诉你这个邮箱在某年某家公司的库里出现过，但漏出去的是邮箱本身、是密码哈希、还是连手机号一起打包，界面上常常一句话说不清。知道一半，比什么都不知道强，但也别指望它替你做判断。我见过有人查到红字之后连着三天换密码，也见过查完就当没事的，两种都走了极端。

账号密码泄露查询能查到的，就三层

第一层，有没有。你输的邮箱、用户名在不在已知的库里。就一个是或否，命中还挺随机——小号邮箱往往查不到，常用的主邮箱一查一大片。第二层，是哪次。事件名称、大概哪一年、涉及多少条记录，这些数字各家口径不一样，以查询服务自己的页面说明为准，别拿一个站的说法当定论。第三层，漏了什么字段。好的服务会把字段类别列出来：邮箱、用户名、密码明文、密码哈希、手机号、IP。有些只给一句包含密码，是哈希还是明文它不区分——这一句差别可大了，后面再说。这三层看完，你手上已经有足够信息决定先改哪个号。

查不到的那部分，才是真正麻烦的地方

公开的泄露库基本来自被曝光、被上报、被人贴到论坛上的东西。企业内部小范围的泄露、钓鱼站收走的表单、木马抓的键盘记录、某个员工把表格导出去卖——这些压根不会出现在查询结果里。更别扭的一种情况：你查不到任何记录，但账号早就被人登过。因为撞库不需要你这家漏，别人家漏了、你又拿同一个密码到处注册，一样中招。所以查询通过这四个字，最多说明已知库里没你，不说明没被撞过。这两件事经常被混成一件事。

别把密码本身往查询框里贴

这一条好多人不当回事。查询的时候只用邮箱或者用户名就够了，别整段粘密码、别粘数据库连接串、更别粘对象存储的 AK/SK。来路不明的小工具让你把密码贴进去检测强度，那就等于把钥匙递出去。顺带说个我比较认可的做法：密码类查询有用一种前缀比对的思路——客户端本地算 SHA-1，只把前 5 个字符发出去，服务端返回一批同前缀的哈希后缀，本地自己比对。这样服务端也不知道你查的到底是哪个密码。看到要求你提交完整哈希或者完整密码的，先打个问号，再看它页面上的说明。

红字之后，动手顺序比数量重要

顺序我一般这么排：先主邮箱，它是所有找回密码的入口，这一步丢了后面全完；再支付和电商；再社交；最后那些一年登一次的小号。同一套密码在几个站复用的，全部换掉，别只改被查出来的那一个——被查到的那家你肯定会改，没被查到的那些才是隐患。顺手上两步验证，能上验证器 App 或硬件密钥就别只靠短信。再回头翻一翻邮箱的转发规则、自动回复、登录设备列表、第三方授权应用。有些人密码改了三遍还是被登，问题就出在这些授权和转发上，跟密码本身没关系。

哈希和明文，差别比很多人想的大

查到含密码两个字，很多人当场血压上来。得看存的是什么。正经站点存加盐哈希，漏出去的也是一串看不出所以然的东西，还原成本不低。麻烦的是早年那些无盐的 MD5、SHA-1，弱口令一撞一个准，等于明文。所以看到哈希也别急着安慰自己——密码本身要是姓名加生日这种，加不加盐都白搭。结论就一句：查到泄露不等于有人正拿着你的密码，但也不等于没人拿得动。

站里的账号也该顺手查一遍

做站的人别只查个人邮箱。面板账号、数据库账号、FTP/SFTP、SSH 密钥、对象存储的密钥、CDN 和短信服务的 API key，全是一个站的要害。但记住查询站只查邮箱，密钥类的东西一个字都别往里贴。数据库账号尤其别跟别处复用，单独一套口令，只给这台机器用。团队里离职的人、外包留下的账号，也别指望查询结果提醒你，得自己去清。真要系统一点，就把谁有几个账号、分别在哪、谁能登列个表，比一次性查一遍有用得多。

查完就忘，是最常见的结局

大多数人查完看一眼，关掉，下一次想起来可能是一年后。我的建议很土：在日历里挂个隔一段时间的提醒，顺手把主邮箱、支付、后台这三类账号过一遍。密码交给密码管理器生成和保管，别自己编。非要记，也至少做到主邮箱一套、跟钱有关的一套、后台一套，三套不重叠。多花的那点记性，比出事之后挨个平台申诉划算得多。

回到开头那句话——查询能给的是方向，不是结论。查到了，按主邮箱、支付、后台的顺序换密码、开两步验证、翻授权和转发规则；查不到，该做的还是这几件事，因为你没法证明自己没在某个没公开的库里。把查询当成一次体检的提醒，别当成一张免疫证明。后面这半句，比前面那半句有用。