Home Assistant's Pwned-Password Check: The GitHub Issue, the Opt-Out Command, and the Privacy Debate

Home Assistant's Supervisor has quietly checked password-marked app options against the Have I Been Pwned (HIBP) breach database for years, using a k-anonymity scheme that sends only the first five characters of a locally computed SHA-1 hash. In October 2026, a GitHub issue titled "I never authorized an integration that scans my secrets" turned that long-standing behavior into a public fight about consent, opt-in defaults, and maintainer tone — and ended with a maintainer apology and the disclosure that the check can already be turned off.

What Home Assistant actually sends to Have I Been Pwned

Home Assistant's Supervisor hashes password values locally and sends only the first five characters of the SHA-1 hash to Have I Been Pwned. The matching against the returned hash list happens on the user's own instance, so the full password and the full hash never leave the system.

The maintainer, Franck Nijhof (GitHub handle frenck), described the mechanism in his follow-up on the issue:

Privacy was a design requirement for this feature from the start, which is why your secrets never leave your system. The Supervisor hashes them locally and sends only the first 5 characters of the SHA-1 hash to Have I Been Pwned. HIBP returns every hash starting with that prefix, and the matching happens on your own instance.

He pointed readers to the implementation at https://github.com/home-assistant/supervisor/blob/main/supervisor/utils/pwned.py.

This is the same k-anonymity approach documented by Cloudflare for validating leaked passwords and described on Wikipedia under k-anonymity — both links were cited in the original GitHub thread.

How to turn the pwned-password check off

The check can be disabled from the command line with:

ha security options --pwned=false

This command was not documented at the time the issue was filed. Nijhof acknowledged that gap: "You are right that our documentation should have explained this, including how to turn it off. We'll get that page updated."

Who is affected — and who is not

The scanning behavior lives in the Supervisor, not in Home Assistant Core. A Hacker News commenter (gcommer) noted that users running Home Assistant Core in a self-hosted container are not affected, because the relevant Supervisor service is only part of Home Assistant OS and Home Assistant Supervised installations.

The GitHub issue: what was reported and why

The issue was filed on the home-assistant/home-assistant.io documentation repository by GitHub user Viss, against Home Assistant version 2026.10.1. The reporter wrote:

This is a pretty severe invasion of privacy. I never authorized any integrations or plugins for scanning secrets and sending them up the line, even if they are hashed or not. This mechanism could be abused by a malicious threat actor with access to the home assistant github repos in a variety of ways.

The suggested solution was to "make this an opt-in feature, do not just opt people in to scanning for secrets with a system they were not aware existed."

The reporter's background is relevant to the dispute. Viss stated he runs Phobos Group, travels internationally giving security presentations, is "very well acquainted with HIBP," has met HIBP founder Troy Hunt, and helped deploy 1Password at Twitter in 2011 as its sole red-team staff member. He added: "As a red teamer, I can give you a list as long as my arm about how I could abuse this to loot credentials from every HA install on the planet."

The maintainer's first response and the escalation

Nijhof's first reply rejected the framing outright:

It is not an invasion of privacy and there are sure other apps out there doing this (most notably the 1Password password manager). Your passwords are never send out, never published.

He also wrote: "If anything, learn from the output, because the secrets you are using are listed in the password databases and thus easily 'hackable'."

The exchange escalated when another long-time user, 0x00string, asked for the issue to be reopened and for a documented way to disable the check, adding: "If there is no interest in addressing this reasonably, please let us know so we can uninstall and fork."

Nijhof responded:

Sorry, these are not statements we can work with. Doing such threats and trying to intimidate it not going to bring you anywhere. If you want to do a feature request, that is fine, we have places for that.

He closed the report as "won't fix," noting that it had been filed against the documentation repository and that "There is no amount of documentation I can adjust to adjust this or address this."

The thread was subsequently locked as "too heated" and limited to collaborators on October 16, 2026.

The follow-up apology and the correction

Nijhof later posted a follow-up on the same issue, apologizing for the tone of his earlier replies and correcting the record on the opt-out:

Leaving this closed since this repository is for our documentation, but I want to follow up, because my earlier replies were more dismissive than this deserved. My apologies.

He also clarified the timeline: the check "isn't new, it has been part of the Supervisor for years. It checks app options that are marked as passwords. A recent release fixed the warning that surfaces it, which is why you're seeing it now."

The privacy argument in favor of the feature: k-anonymity

The design intent behind the check is to warn users when a password already appears in a public breach corpus. Because only a five-character hash prefix is transmitted, the service cannot determine which specific password a user holds — the returned candidate set is large enough to be ambiguous. This is the standard argument for k-anonymity in password-breach checking, and it is why the maintainer compared the behavior to 1Password's.

The privacy argument against: consent and least astonishment

Critics did not dispute the cryptography; they disputed the default. The most-upvoted Hacker News comment, from eranation, framed the disagreement as a set of questions:

Should a password manager warn me about reused passwords without sending things out without opt in? yes - Should a password manager send even one byte of my data to any service, regardless of whether it is for a good intention and mathematically proven to be "safe" without opt in? I'd say no. - So would any other product out there, be it a smart home manager or a toaster, send any of of my data, hashed or not to any 3rd party without opt in? even if it's just the byte "1" to a page called "donothing.com"? I say hell no.

That comment also defended Nijhof's pushback on the fork threat — "We all can sometimes write a reply at the heat of the moment that we later regret" — while concluding that "a phoning home of any kind is violating The Principle of Least Astonishment."

A separate commenter, thunderfork, took the opposite view: "So, wait, these are secrets that are already given to h-a, hashed, and just the first five characters of the hash sent up..? Yeah, I agree with the maintainer, this strikes me as outrage theater over any actual problem, no?"

Arcuru raised the same technical question directly: "This feature should be opt-in, but can someone explain how this is a security concern? I don't understand how it would be an actual security risk to share the first 5 digits of the sha256 of my passwords."

Legal questions raised in the discussion

One Hacker News commenter, Rygian, argued the integration could raise compliance problems in Europe: "I wouldn't be surprised if that integration is outright illegal in EU due to GDPR, thus putting HIBP in trouble for ingesting PII without any legal legitimacy." The same commenter criticized the original reply: "the first reply being 'It is not an invasion of privacy' just shows incompetence on privacy topics. It is never a valid answer." No legal determination was made in the thread.

The community reaction on Hacker News

The story reached 177 points and 131 comments on Hacker News. Reaction split along three lines: the technical soundness of k-anonymity, the appropriateness of an opt-out default for a privacy-focused project, and the tone of the maintainer's responses.

Several commenters focused on tone and process rather than the feature itself. interf4ce noted that the maintainer's reason for closing — that the issue was filed on the documentation repo rather than the code repo — was "understandable" but that "it wouldn't have taken any more effort to be a little more helpful and direct OP to the right repo." Cameri wrote that "The dev comes as self-serving... Calls it heated when he himself caused it with their tone deaf response." onionisafruit, who said they were about to buy a Home Assistant Green, wrote that the pause was "Not about sending hashes to haveibeenpwned, but about the response this got on github."

Others defended the maintainer's directness. altairprime wrote that "decisive software creators are far less palatable to an entitled swarm of disagreement, and that same decisiveness is what makes the best software," and described the thread as a "comedy-farce." TZubiri pushed back on the characterization of the fork comment as a threat: "i don't think it's inappropriate or 'a threat' to let the dev know the user can stop using the software."

abletonlive suggested the apology was reactive: "In this case, frenck most certainly backtracked because they realized they were on the front page of HN and did not want the heat."

One commenter, speerer, observed: "A rare occasion where the AI response was an improvement on the human-written ones."

A commenter also linked Nijhof to an unrelated prior controversy in the NixOS nixpkgs repository (pull request 126326), with a pointer to a 2021 Hacker News discussion.

What Home Assistant said it will do next

The issue remains closed because it was filed against the documentation repository. The concrete commitments from the maintainer's follow-up are: the documentation page for the pwned-passwords feature will be updated to explain the mechanism and how to disable it, and users who want the behavior changed to opt-in were directed to file a feature request through Home Assistant's normal feature-request channels rather than on the docs repo.

The functional takeaway for Home Assistant OS and Supervised users is that the check is already optional — ha security options --pwned=false disables it today.