Naz.API 凭据填充列表

原文 ↗ Hacker News 讨论 ↗

Naz.API 凭据填充数据集被加入 Have I Been Pwned 的消息，让许多用户对自己实际上能做什么感到不确定，因为这类泄露往往暴露邮箱-密码对，却没有清楚说明哪些服务遭到影响。评论者权衡了通过 HIBP 的 k-匿名 API 或第三方搜索站点检查密码、批量轮换凭据，以及依赖密码管理器和 passkeys 的取舍，同时也在质疑厂商责任、数据可能的恶意软件来源，以及当前认证模型的局限。总体来看，这一事件凸显了凭据泄露已多么普遍，以及个人要评估自己真实暴露程度仍然有多困难。

可操作性与用户困惑

  • 许多评论者表示，他们的邮箱出现在 Naz.API 中，但却看不到涉及的是哪个网站或哪个密码，因此这条提醒感觉“不可操作”。
  • 拥有数百个登录账号的人说，要把所有密码都轮换一遍并不现实；他们计划优先处理高价值账号和仍在使用的账号。

想知道泄露来源

  • 人们强烈希望知道每个泄露的凭据对应的是哪个服务或域名，这既出于实际原因（要改哪个密码），也出于法律原因（例如 GDPR 责任）。
  • 反对意见是：公开每个邮箱的密码，甚至公开过多上下文，可能会让攻击者去查询任意邮箱的密码。
  • 有人建议通知邮件至少在可用时附上泄露/来源名称，而不暴露密码。

Naz.API 数据集的性质（Seagate？恶意软件？聚合器？）

  • 有一条讨论把 Naz.API 与 Seagate NAS 软件/NAS API 漏洞联系起来；但泄露中的其他人表示他们从未使用过 Seagate 产品，所以这种解释似乎并不完整。
  • 这篇博客文章和几条评论都说，很多数据来自“stealer logs”（窃密木马导出的已保存凭据）以及之前的泄露集合（例如“Polish Credentials”）。
  • 总体范围仍不清楚：更可能是旧数据与新数据、恶意软件日志和多次泄露的混合，而不是一次整洁的单一事件。

检查被泄露的密码

  • 人们讨论使用 HaveIBeenPwned 的 Pwned Passwords 服务，包括：
    • 在线 k-匿名 API（本地哈希，只发送前 5 个字符）。
    • 完整哈希转储（约 37 GB）以及本地工具/缓存，用于离线查询。
  • 主要密码管理器都集成了这些检查；有些用户指出新数据显示到工具中会有延迟。
  • 还提到了替代搜索站点“0t”，说它暴露了 Naz.API 的细节，但包含许多泄露内容，而且其运营者不鼓励抓取。

密码管理与轮换

  • 有些人会按计划轮换旧密码；另一些人认为，如果每个密码本来就唯一且足够强，轮换带来的好处并不大。
  • 几位评论者推荐使用密码管理器（Bitwarden、1Password、KeePass + 云存储）加上 2FA；也有人提到把未使用的账号删除，作为清理的一部分。

邮箱别名与“信标”地址

  • 评论者使用自定义域名或转发服务，为每个网站提供一个独特邮箱，并把邮箱出现在泄露中的情况当作“信标”，用来识别是哪家组织泄露了数据。
  • 代价是：这会让集中式泄露提醒服务更难处理，因为它们只监控少量邮箱地址。

认证替代方案与一般安全话题

  • 越来越多人支持 passkeys/FIDO 密钥，因为它们比密码更能抵抗钓鱼。
  • 讨论的焦点在于这种方案对“普通人”是否实用（密钥丢失、备份、恢复）以及是否能带来更好的安全性。
  • 还讨论了公共 Wi‑Fi：普遍认为 HTTPS 大体上已经足够，但写得很差、会削弱 TLS 的应用仍然令人担忧。