Home Assistant 被曝未授权扫描用户密码

先把时间钉住。10 月 16 日（UTC），用户 Viss 在 Home Assistant 的文档仓库开了 issue #49314，标题是「我从未授权一个扫描我秘密的集成」，指向系统里一个会把本地配置的密码类字段拿去联网查询泄露数据库的功能。维护者 frenck 当晚先回怼、再两度关闭 issue，态度一路硬到「卸载请便」。20 点 33 分，这条 issue 被提交上 Hacker News，随后冲上热榜，截至 10 月 17 日上午已超 150 个支持票、100 多条评论，仍在涨。21 点 11 分，也就是首评之后第 116 分钟，frenck 发出置顶长评道歉，承认自己此前的回复过于轻慢，并给出了一个此前没有写进文档的关闭命令。48 小时窗口是 10 月 16 日到 10 月 18 日，本稿在窗内。口径先钉死：Viss、frenck 以及后文出现的几位评论者身份均为自报或网友指认，正文点身份时带限定；引用原话可直引，因为 issue 和 HN 都是公开记录；以下时间戳全部出自 issue #49314 与 HN 一手源。

发生了什么

争议功能本身是个老功能。据 frenck 在道歉评里披露，这项检查已经在 Supervisor 里存在多年，逻辑是扫描 add-on 配置里被标记为 password 的字段，在本地做 SHA-1 哈希，只把哈希结果的前 5 个字符发给泄露密码查询服务 Have I Been Pwned（HIBP），HIBP 返回同前缀下的哈希列表，最终比对在本机完成。这套机制叫 K-anonymity，密码原文和完整哈希都不出本机，1Password、Chrome、Firefox 用的是同款方案，HA 官方文档页对此早有说明。再拆细一点，本地算出 SHA-1 后取前 5 个十六进制字符，约 20 个比特，拿这段前缀去查 HIBP 的 range API，HIBP 返回该前缀下全部哈希，通常是几百条，最后在本机做全值比对。HIBP 收到的只是一段前缀，无法反推是哪一个密码，更无法反推是哪一台设备。密码学层面这个功能没有污点，文档也写了，争议不在机制。

问题出在用户这一侧的体感。Viss 在 2026.10.1 版本上第一次看到系统「在扫描我的秘密」的警告，他的判断是自己从未授权过这件事，诉求是把功能改成 opt-in，先征得同意再扫。为什么老功能现在才炸？frenck 在道歉评里给了解释：最近一个版本修复了让这条警告浮出水面的 bug，老用户是头一回看见它。

接下来是当晚的升级链，全部带时间戳。19 点 15 分，frenck 首评，开头一句「Oh hi there 👋」，定性「这不是侵犯隐私」，并举 1Password 为例说别的软件也这么干，还附了 Cloudflare 的 K-anonymity 博客和维基百科链接，末尾加了一句「要说的话，该从这条输出里学点东西，因为你在用的这些秘密已经躺在泄露数据库里，很容易被抓去用」。19 点 48 分，Viss 自报身份回击，称自己经营 Phobos Group、常年做安全演讲、认识 HIBP 的作者 Troy、2011 年在 Twitter 做唯一红队成员时部署过 1Password（以上均为自述，未独立核实）。他的核心论点没有变：这应该是 opt-in 功能，不该「就这么发生了」；作为红队成员，他能列出一长串滥用这条通道从全球每个 HA 安装里捞凭据的办法。19 点 56 分，frenck 留下一句「This issue is closed as won’t fix. Sorry.」，issue 被关。

20 点 12 分，老用户 0x00string 请求重开，措辞是「如果你们无意合理处理这件事，请直说，我们好卸载并另起分支」。20 点 14 分，frenck 发出第二封关闭辞，指对方「威胁、恐吓」，并表示「如果这就够你卸载和 fork 了……🤷 那就请便，反正这是开源软件」。20 点 33 分，issue 上了 HN。21 点 11 分，frenck 的置顶道歉评出现，给出关闭命令 ha security options --pwned=false，并以「As it turns out, this check can already be turned off after all」的口吻承认开关其实早就存在。issue 最终状态是 Closed，frenck 把它钉在了仓库顶部。

批评面主线：机制没毛病，治理有毛病

第一条主线是授权。功能默认开启，触发面是所有 add-on 配置里被标记为 password 的字段，用户未必清楚自己的哪些配置会被归进这一类；数据流虽然只发哈希前缀，但发往的毕竟是第三方服务；而警告文案在这次版本更新前根本没有浮出过水面。默认 opt-out、无提示、第三方数据流，这三点叠加，才是 Viss 真正在投诉的东西。他给出的理论攻击面也在这个层面：按其 issue 原话，能碰到 HA 仓库的恶意行为者理论上可以利用这条机制做文章。这是 issue 作者指出的理论攻击面，不是已被证实的漏洞，本篇不升格。

第二条主线是自相矛盾的关闭理由。issue 开在文档仓，因为开关没写进文档，去文档仓提没毛病。HN 评论者 mcmcmc 点破了这一层：关闭这个功能的选项本来就有，只是没文档化，所以文档仓恰恰是开 issue 的正确地方。而维护者以「这是文档仓，改文档解决不了功能问题」的姿态把它关掉，逻辑上站不住。

第三条主线是回应方式转移了议题。Viss 的论点是治理错误，frenck 的首评却拿 1Password 做类比，把话题拽到「别人也这么干」。HN 高赞评论者 jackpepsi 的讽刺很有代表性：「你可能觉得这次不请自来的扫描很羞辱人，但我们能用数学证明我们没有羞辱你。」技术上没错与程序上没授权，是两回事，首评只回答了前者。

言行审计：116 分钟里的四副面孔

把当晚的话按顺序摆出来，就是一份现成的言行审计材料。19 点 15 分，「这不是侵犯隐私」，附链接自证。19 点 56 分，「won’t fix，抱歉」，issue 关闭。20 点 14 分，「威胁恐吓没有用」「卸载 fork 请便，反正是开源」，二次关闭。21 点 11 分，「我此前的回复比这件事应得的更轻慢，我道歉」，交出开关、披露机制、解释爆发原因、附源码链接（该评论被页面截断，源码具体路径本篇未核全，不写死）。四副面孔之间只隔了 116 分钟，中间发生的事只有一件：HN 发酵了 38 分钟。

道歉评本身值得记一笔，因为它给出的增量信息不少：机制细节、爆发原因、关闭命令，都是前两轮回应里没有的。也就是说，用户在第一轮就想问清楚的东西，维护者其实答得上来，只是先选择了关闭。

旧账也被翻了。HN 评论者 janice1999 和 someguydave 指认，frenck 数年前在 NixOS 的 nixpkgs PR #126326 争议里就是同款「爱改不改，开源请便」的姿态，认为这是其一贯的沟通模式。按红线口径，这是网友指认，本篇照录不定论。另有评论者 hypfer 认为翻旧账属于 bad faith，一并记录。

还有 GDPR 一支。评论者 Rygian 猜测该集成在欧盟可能因 GDPR 非法，理由是「在无合法依据的情况下摄取 PII」；同楼 deadbunny、Matticus_Rex、nicce 反驳说发出去的只是哈希前缀，不构成 PII。正反都记，本篇不定论。

评论区怎么说

HN 一百多条评论里，除了上面点到的几派，还有几路声音值得留档。

建设性对照一路：有网友指认 HA 创始人 balloob 现身，说这个功能已经存在五年并附了文档链接；自称隐私学者的 csoghoian 建议与其做这个不如加 passkey 支持，称用户求了很久、连补丁都提过、但被拒了。两者身份均未独立核实，按网友自述处理。

信任成本一路最扎眼。评论者 onionisafruit 和 fg137 都表示正要买 HA Green 硬件，此事令其犹豫，并强调让自己退缩的「不是把哈希发给 haveibeenpwned，而是这件事在 GitHub 上得到的回应」。一个开源项目的沟通姿态，直接折成了硬件订单的犹豫，这是社区信任成本最具体的样子。

反方声音也要给。评论者 ragall 认为开发者的回复非常合理克制，反倒是用户很无礼；altairprime 同情维护者，说「果断的软件创造者在一片自以为是的反对声浪里越来越不吃香」。这些说法与主线相左，但它们是这场争论的真实组成部分，本篇不裁剪。

普通用户能做三件事

第一，用 HA 且不想被扫的，直接关。命令是 ha security options --pwned=false，出自维护者本人的置顶道歉评，可靠度没有争议。顺手也说明了另一件事：这个开关此前不在文档里，你搜不到不等于不存在。

第二，趁机清点自己的密码配置。这条警告虽然吓人，但它顺带做了一件有用的事：把你所有 add-on 配置里标记为 password 的字段过了一遍 HIBP。frenck 首评里那句话抛开姿态不谈，内容是对的，出现在泄露库里的密码就该换。把弱密码换掉，比争论该不该扫更实惠。

第三，把维护者的回应姿态当成选型信号。这次事件里，功能本身安全、文档也有，真正让用户动摇的是 issue 被两轮硬关的过程。评估任何一个你要托付家庭数据的开源项目时，翻翻它关闭 issue 的方式和措辞，那里藏着的治理文化比 README 诚实。

结语

分寸声明：本篇不定罪任何一方。Viss、balloob、csoghoian 的身份均为自报或网友指认，正文已带限定；frenck 以 Member 身份回应，可称官方回应；理论攻击面按 issue 作者口径转述，未写成已存在漏洞；GDPR 违法论是评论区猜测，正反并列；道歉评里的源码路径因页面截断未核全，不写死；NixOS 旧账按网友指认记录。已核验的事实是：issue #49314 全程时间戳、四段关键原话、关闭命令、K-anonymity 机制与官方文档口径、HN 传播数据（10 月 17 日上午快照超 150 支持票），均出自 GitHub issue 与 HN 一手源。两个待盯节点：其一，HA 官方是否把关闭开关与机制说明补进文档，让下一个用户不用靠翻 issue 才知道自己有关这个的权利；其二，功能是否如 Viss 所求改为 opt-in，或至少在警告文案里给出关闭指引。任一发生，即出 v2。

参考来源

• GitHub issue #49314（home-assistant/home-assistant.io）：一手来源，本篇全部时间戳与原话出处，2026-10-16 开启，最终状态 Closed，frenck 置顶
• HN story 50124251：10-16 20:33 UTC 提交，10-17 上午快照 155▲/104💬，正文用「超 150 支持票、仍在涨」口径；评论池 mcmcmc/jackpepsi/Rygian/deadbunny/Matticus_Rex/nicce/onionisafruit/fg137/balloob/csoghoian/ragall/altairprime/janice1999/someguydave/hypfer 均为评论者自述，正文逐一归属
• HA 官方文档 more-info/pwned-passwords 页：K-anonymity 机制官方说明，直抓全文核验
• Cloudflare 博客 validating-leaked-passwords-with-k-anonymity：frenck 首评自引，佐证同款机制行业通用
• frenck 置顶道歉评：issue 内，2026-10-16 21:11 UTC，关闭命令与机制披露出处；评论被页面截断，源码链接路径未核全