· via Hacker News – Front Page (hnrss.org)
Home Assistant apologizes after backlash over default breached-password checks
A maintainer apologized after users objected to a years-old Home Assistant Supervisor check that hashes password options and queries Have I Been Pwned by default; it can be turned off with one command.
A Home Assistant maintainer has publicly apologized for dismissive replies to a user who discovered that the smart-home platform's Supervisor routinely checks stored passwords against the Have I Been Pwned breach database. The argument unfolded in a GitHub issue on the project's documentation repository, surfaced on Hacker News' front page on October 16, 2026, and ended with an explanation of the feature's design, a promise to improve the docs, and confirmation that a one-line command turns it off.
The complaint
The issue was filed by a user named Viss, who says he runs Phobos Group and speaks internationally on security topics, and that he was Twitter's sole red-team staff member in 2011. Reporting against Home Assistant 2026.10.1, he wrote that he never consented to any mechanism that scans secrets on his installation and passes information about them to a third party, and asked how to switch it off.
Viss added that he knows the breach-notification field well — he says he has met HIBP founder Troy Hunt and helped deploy 1Password at Twitter — but argued that familiarity with the technique is not consent. As a red teamer, he claimed he could enumerate many ways an attacker with access to Home Assistant's repositories could abuse the pipeline to harvest credentials from installations worldwide. His proposed remedy was simple: make the check opt-in.
How the thread escalated
Maintainer frenck initially rejected the privacy framing. He compared the behavior to 1Password's breached-password warnings, linked to Cloudflare's explanation of k-anonymity (the technique that lets a client query a breach database without revealing the password itself), and noted that a flagged password is one that already appears in known breach data. Because the repository in question hosts documentation rather than code, he closed the issue as "won't fix."
The close did not land well. Another long-time user asked for the issue to be reopened and for a documented way to disable the check, suggesting the community would otherwise uninstall and fork the project; frenck replied that threats of that kind would get the discussion nowhere. Viss insisted the matter was not settled until he was assured nothing left his system without permission. A self-described white-hat hacker flatly contradicted the claim that no privacy interest was at stake, and the conversation was then locked and restricted to collaborators.
What the feature actually does
frenck returned with a follow-up comment conceding his earlier replies had treated the complaint too lightly, and apologized. According to his explanation:
- The check is not new. It has shipped inside the Home Assistant Supervisor for years and examines only add-on configuration options explicitly marked as passwords.
- Users noticed it now because a recent release fixed a warning that displays the results, making long-standing behavior suddenly visible.
- No secret leaves the machine, he said. The Supervisor computes a SHA-1 hash locally, sends just the first five characters of that hash to Have I Been Pwned, receives every breached hash sharing that prefix, and performs the match on the user's own instance. The implementation is visible in the Supervisor repository, in supervisor/utils/pwned.py.
- It can be disabled with
ha security options --pwned=false.
He acknowledged that the documentation should have described both the feature and its opt-out, and said that page would be updated. The issue itself remained closed, since the repository is for documentation.
Why it matters
Technically, the design frenck described is the same privacy-preserving pattern used by mainstream password managers, and nothing in the thread contradicts his account that full hashes — let alone plaintext secrets — stay local. But the episode is a case study in how a defensible engineering choice becomes a trust problem through defaults and disclosure. A credential-touching check ran silently for years, surfaced only because a warning got fixed, and came with an opt-out that was effectively undocumented until an argument made it famous. Users who run Home Assistant, often on hardware they regard as private infrastructure, reasonably expect network-touching security features to be announced and easy to opt out of. The thread also shows how much maintainer tone matters: between the "won't fix" close and the apology, the technical facts barely moved, while the community's reading of them flipped entirely.
- #home-assistant
- #security
- #privacy
- #open-source
- #passwords