Home Assistant 的密码泄露检查：GitHub 问题、退出命令与隐私争议
Home Assistant 的 Supervisor 多年来一直默默地将标记为密码的应用选项与 Have I Been Pwned (HIBP) 泄露数据库进行比对，使用 k-匿名性方案，仅发送本地计算的 SHA-1 哈希的前五个字符。2026 年 10 月，一个标题为“我从未授权任何集成扫描我的秘密”的 GitHub 问题将这一长期行为变成了关于同意、默认选择和维护者态度的公开争论——最终以维护者道歉并披露该检查已经可以关闭而告终。
Home Assistant 实际向 Have I Been Pwned 发送了什么
Home Assistant 的 Supervisor 在本地对密码值进行哈希处理，仅将 SHA-1 哈希的前五个字符发送给 Have I Been Pwned。与返回的哈希列表的匹配发生在用户自己的实例上，因此完整密码和完整哈希永远不会离开系统。
维护者 Franck Nijhof（GitHub 用户名 frenck）在后续评论中描述了该机制：
隐私从一开始就是此功能的设计要求，这就是为什么你的秘密永远不会离开你的系统。Supervisor 在本地对它们进行哈希处理，仅将 SHA-1 哈希的前 5 个字符发送给 Have I Been Pwned。HIBP 返回所有以该前缀开头的哈希，匹配发生在你自己的实例上。
他引导读者查看实现，位于 https://github.com/home-assistant/supervisor/blob/main/supervisor/utils/pwned.py。
这与 Cloudflare 记录的用于验证泄露密码的 k-匿名性方法相同，并在维基百科的 k-匿名性条目中有所描述——这两个链接都在原始 GitHub 讨论中被引用。
如何关闭密码泄露检查
可以通过命令行禁用此检查：
ha security options --pwned=false
在问题提交时，此命令并未被记录。Nijhof 承认了这一差距：“你说得对，我们的文档应该解释这一点，包括如何关闭它。我们会更新该页面。”
谁受影响——谁不受影响
扫描行为存在于 Supervisor 中，而不是 Home Assistant Core 中。一位 Hacker News 评论者（gcommer）指出，在自托管容器中运行 Home Assistant Core 的用户不受影响，因为相关的 Supervisor 服务仅存在于 Home Assistant OS 和 Home Assistant Supervised 安装中。
GitHub 问题：报告了什么以及为什么
该问题由 GitHub 用户 Viss 在 home-assistant/home-assistant.io 文档仓库中提交，针对 Home Assistant 版本 2026.10.1。报告者写道：
这是对隐私的严重侵犯。我从未授权任何集成或插件扫描秘密并将其发送出去，即使它们被哈希或未哈希。此机制可能被能够访问 home assistant GitHub 仓库的恶意威胁行为者以多种方式滥用。
建议的解决方案是“将其设为选择加入功能，不要仅仅因为一个他们不知道存在的系统就默认选择扫描秘密。”
报告者的背景与争议相关。Viss 表示他经营 Phobos Group，在国际上旅行进行安全演讲，“非常熟悉 HIBP”，见过 HIBP 创始人 Troy Hunt，并于 2011 年作为唯一的红队成员帮助在 Twitter 部署了 1Password。他补充说：“作为红队成员，我可以给你一份长长的清单，说明我如何滥用这一点来从地球上每个 HA 安装中窃取凭据。”
维护者的首次回应与升级
Nijhof 的首次回复直接拒绝了这一说法：
这不是侵犯隐私，而且肯定有其他应用在做这件事（最著名的是 1Password 密码管理器）。你的密码永远不会被发送出去，永远不会被发布。
他还写道：“如果有什么，从输出中学习，因为你使用的秘密列在密码数据库中，因此很容易被‘破解’。”
当另一位长期用户 0x00string 要求重新打开问题并提供禁用检查的文档化方法时，交流升级了，他补充说：“如果对合理解决这个问题没有兴趣，请告诉我们，以便我们可以卸载并分叉。”
Nijhof 回应道：
抱歉，这些不是我们可以处理的陈述。进行这种威胁并试图恐吓不会让你有任何进展。如果你想提出功能请求，那没问题，我们有地方处理。
他关闭了报告，标记为“不会修复”，指出该问题是在文档仓库中提交的，并且“无论我调整多少文档，都无法调整或解决这个问题。”
该讨论随后于 2026 年 10 月 16 日被锁定为“过于激烈”，并限制为协作者可访问。
后续道歉与更正
Nijhof 后来在同一问题上发布了后续评论，为他早期回复的语气道歉，并更正了关于退出的记录：
保持关闭状态，因为这个仓库是用于我们的文档的，但我想跟进，因为我早期的回复比这应得的更轻蔑。我道歉。
他还澄清了时间线：该检查“不是新的，它已经成为 Supervisor 的一部分多年。它检查标记为密码的应用选项。最近的版本修复了显示它的警告，这就是你现在看到它的原因。”
支持该功能的隐私论点：k-匿名性
该检查的设计意图是当密码已经出现在公开泄露语料库中时警告用户。因为只传输五字符哈希前缀，服务无法确定用户持有哪个特定密码——返回的候选集足够大，具有模糊性。这是密码泄露检查中 k-匿名性的标准论点，也是维护者将其与 1Password 的行为进行比较的原因。
反对的隐私论点：同意与最小惊讶原则
批评者没有质疑密码学；他们质疑默认设置。Hacker News 上获得最多点赞的评论来自 eranation，将分歧框定为一组问题：
密码管理器是否应该在不选择加入的情况下警告我重复使用的密码而不发送任何内容？是的——密码管理器是否应该在不选择加入的情况下将我的任何数据（即使是一个字节）发送给任何服务，无论其意图多么好且数学上证明“安全”？我会说不。那么任何其他产品，无论是智能家居管理器还是烤面包机，是否应该在不选择加入的情况下将我的任何数据（无论是否哈希）发送给任何第三方？即使只是向一个名为“donothing.com”的页面发送字节“1”？我说绝对不行。
该评论还为 Nijhof 对分叉威胁的抵制辩护——“我们有时都会在激动时写出后来后悔的回复”——同时得出结论，“任何形式的‘打电话回家’都违反了最小惊讶原则。”
另一位评论者 thunderfork 持相反观点：“所以，等等，这些秘密已经给了 h-a，进行了哈希，只发送了哈希的前五个字符……？是的，我同意维护者的观点，这在我看来是过度愤怒，而不是实际问题，不是吗？”
Arcuru 直接提出了同样的技术问题：“这个功能应该是选择加入的，但有人能解释这如何构成安全担忧吗？我不明白分享我密码 sha256 的前 5 位数字怎么会是实际的安全风险。”
讨论中提出的法律问题
一位 Hacker News 评论者 Rygian 认为该集成可能在欧洲引起合规问题：“如果该集成因 GDPR 在欧盟完全非法，我不会感到惊讶，从而使 HIBP 因在没有法律依据的情况下处理个人数据而陷入困境。”同一位评论者批评了最初的回复：“第一个回复‘这不是侵犯隐私’只是显示了在隐私问题上的无能。这永远不是一个有效的答案。”讨论中没有做出法律裁定。
Hacker News 上的社区反应
该故事在 Hacker News 上获得了 177 分和 131 条评论。反应分为三条线：k-匿名性的技术合理性、隐私关注项目默认选择退出的适当性，以及维护者回应的语气。
几位评论者关注语气和流程，而不是功能本身。interf4ce 指出，维护者关闭问题的原因——问题是在文档仓库而不是代码仓库中提交的——是“可以理解的”，但“帮助用户并直接引导他们到正确的仓库不会花费更多努力。”Cameri 写道：“开发者显得自私……称其激烈，而实际上是他自己语气不当引起的。”onionisafruit 表示他们正准备购买 Home Assistant Green，写道暂停“不是关于向 haveibeenpwned 发送哈希，而是关于在 github 上得到的回应。”
其他人则为维护者的直接性辩护。altairprime 写道，“果断的软件创作者对一群自以为是的反对者来说远不那么讨喜，而同样的果断正是造就最佳软件的原因，”并将该讨论描述为“喜剧闹剧。”TZubiri 反驳了将分叉评论描述为威胁的说法：“我认为让开发者知道用户可以停止使用软件并不是不恰当或‘威胁’。”
abletonlive 建议道歉是反应性的：“在这种情况下，frenck 肯定是因为意识到自己上了 HN 首页并且不想承受热度而退缩了。”
一位评论者 speerer 观察到：“一个罕见的场合，AI 回复比人类写的更好。”
一位评论者还将 Nijhof 与 NixOS nixpkgs 仓库中一个无关的先前争议（拉取请求 126326）联系起来，并指向 2021 年的 Hacker News 讨论。
Home Assistant 表示接下来会做什么
该问题仍然关闭，因为它是针对文档仓库提交的。维护者后续评论中的具体承诺是：密码泄露功能的文档页面将更新以解释机制以及如何禁用它，希望将行为改为选择加入的用户被引导通过 Home Assistant 的正常功能请求渠道提交功能请求，而不是在文档仓库中。
对于 Home Assistant OS 和 Supervised 用户，功能上的要点是检查已经是可选的——ha security options --pwned=false 今天就可以禁用它。