这是一次相当严重的隐私侵犯。我从未授权任何集成或插件扫描密钥并将其上传，无论这些内容是否经过哈希处理。该机制可能被有权访问家庭助手（Home Assistant）的 GitHub 仓库的恶意威胁行为者以多种方式滥用，因此我该如何关闭这个功能？

描述

问题类型

其他（内容格式问题、无效链接或图片、无法使用的小部件）

问题描述

这是一起相当严重的隐私侵犯。我从未授权任何集成或插件扫描我的机密并把它们往上传，无论是否经过哈希处理。如果有恶意威胁者获得了 Home Assistant GitHub 仓库的访问权限，这个机制可能被以多种方式滥用。我要怎么关掉这个功能？

建议解决方案

把它做成选择性加入（opt-in）的功能，不要在他们根本不知道有这个系统存在的情况下，就默认把人拉进来扫描机密。

链接

https://www.home-assistant.io/more-info/pwned-passwords/

版本

2026.10.1

你如何知道建议的解决方案是正确的？

无回应

附加信息

无回应

活动

frenck（成员）于 2026 年 10 月 16 日评论

嗨 👋。这不是侵犯隐私，确实有其他应用也在这么做（最典型的是 1Password 密码管理器）。你的密码从来不会被发送出去，也不会被公开。参见 Cloudflare 关于用 k-匿名验证泄露密码的博文 和 k-匿名（维基百科）。事实上，这个机制在设计时就考虑了隐私。你更应该从输出结果中吸取教训，因为你正在使用的机密已经出现在密码数据库中，因此很容易被“黑”。——Frenck

Viss（作者）于 2026 年 10 月 16 日评论

我仍然不满的是，Home Assistant 在没有我 opt-in、没有我许可的情况下，扫描了我的 HA 安装并把数据往上传给 HIBP。这应该是一个 opt-in 功能，而不是“就这么发生”的东西。作为红队成员，我能列出一长串方法，说明我可以如何滥用它来窃取全球每一个 HA 安装上的凭据。

Viss（作者）于 2026 年 10 月 16 日评论

在确认 HA 没有在未经我许可的情况下把东西从我系统上拿走并发送给第三方之前，这个 issue 不会关闭。

frenck（成员）于 2026 年 10 月 16 日评论

这个 issue 以“不予修复（won't fix）”关闭。抱歉。——Frenck

0x00string 于 2026 年 10 月 16 日评论

我是 HA 的长期用户。请重开这个 issue，并回答如何禁用该功能。如果目前没有实现禁用方法，请考虑实现它，而不是坚持让用户群接受这一点并相信你们的说法。这个回复让人感觉极其敷衍；作为平台用户，我间接感到被冒犯，因为我和楼主有完全相同的担忧，并且认为这里的回复没有充分回应这些担忧。如果没有兴趣合理解决这个问题，请告诉我们，这样我们可以卸载并分叉（fork）。

frenck（成员）于 2026 年 10 月 16 日评论

“请告诉我们，这样我们可以卸载并 fork”——抱歉，我们无法接受这样的说法。发出这种威胁并试图施压，不会给你带来任何结果。如果你想提功能请求，那没问题，我们有相应的渠道。这篇报告是针对我们的文档的。无论我怎么调整文档，都无法改变或解决这个问题。因此以“不予修复”关闭。如果这就是你要卸载并 fork 的理由……🤷 那随你吧，毕竟它是开源项目。——Frenck

troed 于 2026 年 10 月 16 日评论

“这不是侵犯隐私”——是的，它就是。/白帽黑客

因讨论过热，该 issue 于 2026 年 10 月 16 日被锁定，对话被限制为仅协作者可参与。

frenck（成员）于 2026 年 10 月 16 日评论

这个仓库是用于文档的，所以保持关闭，但我想跟进一下，因为我之前的回复比这件事应得的更加敷衍。抱歉。

实际上，这个检查早就可以关闭，命令是 ha security options --pwned=false。

坦白说：这个检查并不是新东西，它多年来一直是 Supervisor 的一部分。它检查被标记为密码的应用选项。最近一个版本修复了触发该检查的警告，所以你现在才看到它。

隐私从一开始就是这个功能的设计要求，因此你的机密永远不会离开你的系统。Supervisor 在本地对它们进行哈希，只把 SHA-1 哈希的前 5 个字符发送给 Have I Been Pwned。HIBP 会返回所有以该前缀开头的哈希，匹配过程发生在你自己的实例上。你可以在这里看到它具体做了什么：supervisor/utils/pwned.py。

你说得对，我们的文档应该解释这一点，包括如何关闭它。我们会更新那个页面。——Frenck

多数人批评 Home Assistant 维护者默认把密码相关信息发给 Have I Been Pwned，且回应态度轻蔑；也有不少人认为这在技术上只是常见的已泄露密码 k-匿名检查，用户的愤怒被放大了。维护者随后道歉并补上关闭方式与实现细节，但社区对他改口的动机仍有怀疑。

认为默认把密码哈希前缀发给第三方不可接受，应改成用户主动开启

• 家庭自动化系统本就把隐私当卖点，任何未经明确同意就把数据发给第三方服务的行为都违背最小惊讶原则；哪怕只发哈希的一小部分、目的再正当，也应默认关闭、由用户选择。（较多人） > 产品不应在未经用户选择的情况下，把任何数据发给第三方，哪怕只是一个字节、即便目的正当且数学上安全。（意译 @eranation）
• 其中也有人承认这未必构成实际安全风险，但仍坚持程序上必须先获得同意；重点不在泄露概率，而在知情权和选择权。（少数人）

认为维护者的回应傲慢、火上浇油

• 许多批评集中在项目在 GitHub 上的回复：把用户的不安说成“数学上不成立”，并用“这是开源，爱用不用、自己分叉”来结束讨论，被视作轻蔑和推卸；这种语气让本来可以技术解释的问题升级成信任危机。（较多人） > 即便你能用数学证明没有羞辱用户，也不该直接否定用户的不适感。（意译 @jackpepsi）
• 作为当事人，frenck 后来跟帖承认回复比应该的更轻蔑并道歉，也保留旧回复；但仍有用户认为他先前的态度已经劝退潜在用户，暴露出项目治理与社区沟通的问题。（较多人）

认为实际安全风险被夸大，这是密码管理器常见的 k-匿名检查

• 有用户指出，被检查的密码早已交给 Home Assistant，上传的只是密码的 SHA-1 哈希前 5 个字符，完整比对在本地完成，和主流密码管理器调用 Have I Been Pwned 的方式没有本质区别；所以更像是“没告知”，而不是真的泄露了密码。（较多人） > 既然这些密码已经交给 Home Assistant，且只上传哈希的前几个字符，这更像小题大做而非实际问题。（意译 @thunderfork）

认为争议根源在于文档缺失，而不是新增长传数据

• 维护者说明，该功能其实早已存在于 Supervisor，只检查被标记为密码的附加组件选项；最近一次发布才把相关警告暴露出来，用户因此突然注意到它。文档没有解释原理和关闭方式，才是主要失误。（较多人） > 文档本应解释这一切，包括如何关闭；我们会更新。（意译 @frenck）
• frenck 已表示会补文档，并说明可以通过 Supervisor 的命令行安全设置关闭该检查（把 pwned 检查设为关闭）；也就是说，用户并非只能靠分叉项目来摆脱它。（较多人）

认为维护者有权直接拒绝，不必迎合用户

• 少数评论从文化差异和开源作者主权出发，认为果断的创造者不需要向“觉得被冒犯的用户群”解释；一旦决定就关闭问题、继续工作，并不算失职，反而是做出好软件的特质。（少数人） > 一旦决定就已关门继续工作，这种直率在有些文化里并不算傲慢，而是一种果断。（意译 @altairprime）

怀疑道歉只是迫于 Hacker News 流量压力

• 有人不信任维护者的转向，认为他并非被技术讨论说服，而是发现事件登上 Hacker News 首页、不想承受舆论火力才改口和补说明。（少数人） > 他之所以改口，是因为发现自己上了 Hacker News 首页，不想承受这波热度。（意译 @abletonlive）

有价值的补充

• 实现细节：被检查的是 Home Assistant Supervisor 中标记为密码的附加组件选项，不是用户登录 Home Assistant 的主密码；发送的是密码的 SHA-1 哈希前 5 个字符，Have I Been Pwned 返回候选列表后在本地比对，属于 k-匿名范围查询，服务端看不到完整哈希或密码。
• 关闭方式：该功能其实早已能通过 Supervisor 的命令行安全设置关闭（把 pwned 检查设为关闭），并非只能卸载或分叉；文档缺失让用户误以为这是新增的强制外传。
• 合规风险：有评论指出，在欧盟，未取得明确同意就向第三方发送哪怕是哈希化的密码相关信息，可能缺乏 GDPR 下的法律依据，也可能让接收方面临接收个人数据的合规问题。
• 认知误区：讨论里有人误以为是 SHA-256 或上传完整哈希；实际实现用的是 SHA-1 哈希前缀，这也是 Have I Been Pwned 长期使用的标准做法。
• 优先级之争：相比这个密码泄露检查，部分用户更希望项目优先支持抗钓鱼的多因素认证（如通行密钥），并认为过去相关补丁被拒更值得关注。
• 沟通类比：在开源项目里说“我们要卸载并分叉”其实不算有效威胁，因为分叉本来就是开源权利；但用户表达停用意愿也不应被维护者当成挑衅，否则会把技术讨论变成情绪对抗。