I never authorized an integration that scans my secrets

Original Article ↗ Hacker News Discussion ↗

A home automation project is under fire for silently checking stored passwords against the “Have I Been Pwned” breach database by default, sending the first five characters of each password’s SHA‑1 hash to a third‑party service. Many users argue that even this limited data sharing violates the expectations of a local, privacy‑focused system and should require explicit opt‑in consent, especially given concerns about trust, GDPR, and potential information leaks. The controversy is intensified by a perceivedly dismissive maintainer response—followed by an apology and moves toward better documentation and an opt‑in model—which has some users reconsidering their reliance on the platform.

Feature and Behavior

  • Home Assistant’s supervisor includes a “pwned password” check: it hashes secrets (e.g., passwords in HA config) with SHA‑1 and sends only the first 5 hex characters to Have I Been Pwned (HIBP), then matches locally using k‑anonymity.
  • This behavior has been present for years, but a recent change surfaced warnings so users noticed it.
  • There is a command-line flag to disable it, but it was undocumented; a PR now aims to make it opt‑in.

Privacy, Consent, and Expectations

  • Many commenters say the core issue is privacy and consent, not cryptography:
    • Users did not expect a “local, privacy‑focused” home automation system to contact third‑party services about their secrets by default.
    • Several argue that any unsolicited outbound traffic — “even a single byte” — is a breach of trust and violates the principle of least astonishment.
    • Some cite the project’s own privacy messaging and an “opt‑in by default” cloud principle and say this feature contradicts that.

Security and k‑Anonymity Debate

  • One camp argues the scheme is effectively safe:
    • Only 5 hex chars of a hash are sent; median bucket size is large.
    • Attackers would already need weak or known passwords; many other password managers use similar checks.
  • Another camp points to research on attacks against k‑anonymity‑style HIBP use:
    • Prefixes can aid brute‑force and password‑guessing.
    • Requests leak metadata (IP, likely presence of certain passwords, software usage).
    • They emphasize unknown threat models and advocate minimizing any information leak.
  • Some say framing this primarily as a security problem is misleading; it’s mainly a privacy/trust and “phoning home” problem.

Legal and Regulatory Questions

  • A few commenters suggest potential GDPR issues due to IP addresses and re‑use of personal data for a new purpose.
  • Others question whether the hash prefix alone is PII; overall legality is described as unclear.

Developer Response and Community Trust

  • Initial maintainer replies are widely described as dismissive, tone‑deaf, and needlessly confrontational (e.g., calling user concerns “threats” and suggesting they fork).
  • A later follow‑up includes an apology, clarification of the feature, and a promise to improve documentation; some see this as genuine, others as damage control.
  • Past disputes in other projects are referenced as contributing to concerns about judgment and culture.
  • Several users say this incident makes them reconsider adopting or recommending Home Assistant; others still see it as superior to cloud‑centric alternatives but view this as a serious trust misstep.