Home Assistant 密码检查推荐解读，自托管不等于零外联的一课

一位安全研究员上周在开源智能家居平台文档仓库开炮，标题是 我从未授权过一个扫描我密码的集成，一百七十余分热帖把 Home Assistant 推上风口。风口上的平台是全球最大的开源智能家居系统，装机量以百万计，事件的波及面不小。我把原始议题、维护者回应与社区讨论核了一遍，事件的全貌比标题有意思，它给所有自托管用户上了一课。

事件是什么

先还原事实。发难者是位资深安全从业者，自述运营安全公司且做过某社交平台红队，红队的职业就是把每个系统当对手打，这次打的恰好是自己家里装的那套。他在自查时发现系统的管理组件会对外发送数据点，追查后发现是一个内置的密码泄露检查功能，他从未被告知也未同意，于是公开发难要求改为可选。

这个功能是什么来头。系统对标记为密码的插件配置项做泄露检查，对接的是那个知名泄露库查询服务，功能存在多年，近期一个版本修了提示显示才被用户注意到。存在多年没被发现，本身也说明出站流量透明度差到什么程度，透明度差的系统里可能还有别的没被发现，这次发现靠的是一个较真的用户，较真的用户是所有开源社区的稀缺资产。发难者按不当流程关闭了议题，随后讨论过热被平台锁定，锁定前后的攻防记录都在议题页，原始材料完整可查。

双方说的都对在哪

维护者的技术解释站得住。检查用的是 k 匿名设计，密码在本地哈希后只把哈希前五位发出去，比对在本地完成，明文密码不出系统，与某 CDN 巨头用的机制同款，业内标准做法，标准做法不代表无需告知。从这个角度说，隐私风险被夸大了。

发难者的立场同样成立。默认开启且不告知，违背的是知情同意原则，哪怕机制再安全，用户有权知道自己设备上有出站流量。安全从业者对任何形式的凭据相关外联保持极端敏感，这是职业本能也是防线，防线过敏总比防线失灵好。

后续的处理值得肯定。维护者先按惯例关闭了议题，看到社区反弹后置顶道歉，承认最初的回复过于轻慢，给出一条命令的关闭方法，承诺补充文档，从犯错到修正的路径走得不算快但走完了。开源项目在社区监督下的自我纠偏，这轮走得完整。

解决了什么需求

对自托管用户，事件的价值是一份自查清单，清单不长，三条而已，每一条都拿这次事件当过教材，教材现成不用自己编。第一，别默认自托管等于零外联，装完任何系统跑一遍网络监控，出站流量逐条过目，过目的十分钟换长期安心，安心这个词在自托管圈子值多少钱，装过监控的人都知道。十分钟换一次系统级安全审视，比任何安全软件年费都便宜，便宜的审视做多了系统透明度自然上来，透明度上来了这次这种乌龙就不会再瞒这么多年。第二，懂机制的可以留着这个检查，它确实能提前发现弱密码，密码出现在泄露库里意味着可能被撞库，提前知道提前改。介意的一条命令关掉，方法就在官方文档里，关闭之后系统照常运行。第三，议题区是最好的知情渠道，重大功能变更盯一盯仓库动态，动态里藏着你要的答案，答案不会主动推送给你，主动权永远属于愿意翻 issue 列表的人，翻列表比刷资讯有用。

对开发者，教训同样清楚，隐私相关功能默认值给关闭或至少首启时问一句，告知的成本远低于事发后的信任修复，修复信任的账单这次那位维护者自己看到了。

一句话收尾，自托管的隐私是自己的责任，这一课学费是别人的。

来源

• 原始议题 https://github.com/home-assistant/home-assistant.io/issues/49314
• 社区讨论 https://news.ycombinator.com/item?id=50124251