Home Assistant: Unbefugtes Scannen von Benutzerpasswörtern enthüllt

Zuerst soll die Zeit festgelegt werden. Am 16. Oktober (UTC) stellte der Benutzer Viss in der Dokumentenbibliothek von Home Assistant einen Issue #49314 ein, dessen Titel lautet „Ich habe nie eine Integration erlaubt, meine Geheimnisse zu scannen“. Dabei wurde auf eine Funktion in dem System hingewiesen, die lokale Konfigurationsdaten über das Netzwerk abruft und diese an eine Datenbank weiterleitet. Der Betreuer frenck reagierte am selben Abend zunächst mit Widerspruch und schloss den Issue anschließend zweimal – seine Haltung war dabei sehr entschlossen, bis er schließlich sagte: „Entladen Sie einfach.“ Um 20:33 Uhr wurde der Issue auf Hacker News veröffentlicht, wo er schnell in die Top-Liste geriet. Bis zum Morgen des 17. Oktober hatte der Issue bereits über 150 Unterstützungsstimmen und mehr als 100 Kommentare erhalten, und diese Zahl steigt weiterhin. Um 21:11 Uhr, also 116 Minuten nach der ersten Bewertung, veröffentlichte frenck einen langen Kommentar mit einer Entschuldigung, in dem er zugab, dass seine vorherigen Antworten zu nachsichtig waren, und eine Befehlszeile anführte, die in den Dokumenten nicht enthalten war. Die 48-Stunden-Frist läuft vom 16. Oktober bis zum 18. Oktober – dieser Artikel liegt innerhalb dieser Frist. Zunächst soll festgelegt werden: Die Identitäten von Viss, frenck sowie den später auftauchenden Kommentatoren sind entweder selbst angegeben oder durch andere Benutzer identifiziert. Bei der Angabe der Identitäten werden diese eingeschränkt; die Originalzitate können direkt verwendet werden, da sowohl der Issue als auch Hacker News öffentliche Aufzeichnungen sind. Alle Zeitstempel im Folgenden stammen aus Issue #49314 und Hacker News.

Was ist passiert?

Die Funktion zur Überprüfung ist eine alte Funktion. Laut Frenck in seiner Entschuldigungsmitteilung existiert diese Überprüfung bereits seit vielen Jahren in Supervisor. Der Mechanismus besteht darin, die Felder in den Add-ons-Configurations zu scannen, die als Passwörter markiert sind, eine SHA-1-Hash-Aufgabe durchzuführen und nur die ersten 5 Hexadezimalzeichen des Hashwerts an den Dienst Have I Been Pwned (HIBP) zu senden. HIBP gibt eine Liste aller Hashwerte mit demselben Präfix zurück, und die Überprüfung erfolgt schließlich auf der lokalen Maschine. Dieser Mechanismus wird K-anonymity genannt. Der ursprüngliche Passworttext und der vollständige Hash werden nicht von der lokalen Maschine ausgegeben. 1Password, Chrome und Firefox verwenden denselben Mechanismus. Die offiziellen HA-Dokumente beschreiben dies bereits ausführlich. Genauer gesagt: Nach der Berechnung der SHA-1-Hash werden die ersten 5 Hexadezimalzeichen erhalten, etwa 20 Bit. Dieses Präfix wird dann zur Suche im HIBP-Range-API verwendet. HIBP gibt alle Hashwerte mit demselben Präfix zurück, normalerweise einige hundert Stück. Schließlich erfolgt die vollständige Vergleichung auf der lokalen Maschine. HIBP erhält nur ein Präfix und kann daher nicht herausfinden, welches Passwort es ist oder welches Gerät verwendet wurde. Auf der mathematisch-chemischen Ebene ist diese Funktion unproblematisch, wie in den Dokumenten beschrieben. Der Streit liegt nicht am Mechanismus.

Das Problem liegt bei der Empfindung des Benutzers. Viss sah zum ersten Mal die Warnung „Meine Geheimnisse werden gescannt“ in der Version 2026.10.1. Seine Schlussfolgerung war, dass er niemals Zugang dazu gewährt hatte. Er forderte, dass die Funktion in eine opt-in-Version umgestellt würde, also erst Zustimmung einholt man, bevor die Scannung durchgeführt wird. Warum funktioniert die alte Funktion erst jetzt nicht mehr? Frenck erklärte in seiner Entschuldigung, dass in der letzten Version ein Bug behoben wurde, der diese Warnung verursachte. Die alten Benutzer sahen sie zum ersten Mal.

Nächstes ist die Upgrade-Liste der nächtlichen Stunde, mit allen Zeitstempeln. Um 19:15 Uhr gab Frenck seine erste Bewertung ab, mit dem Satz „Oh hi there 👋“, definierte es als „Das ist keine Verletzung von Privatsphäre“ und nannte 1Password als Beispiel dafür, dass andere Software ebenso handelt. Er fügte den Link zum K-anonymity-Blog und Wikipedia von Cloudflare hinzu und schloss mit dem Satz „Was gesagt werden muss, kann man aus dieser Ausgabe lernen, denn die Geheimnisse, die du verwendest, liegen bereits in einer Leaks-Datenbank und können leicht abgerufen werden.“ Um 19:48 Uhr meldete sich Viss zurück und argumentierte, dass er die Phobos Group leite, regelmäßig Sicherheitsvorträge hält, den Autor von HIBP, Troy, kennt und im Jahr 2011 als einziger Red-Hat-Mitglied auf Twitter 1Password eingesetzt hat (allesamt Selbstbehauptungen, nicht unabhängig überprüft). Sein Kernargument hat sich nicht geändert: Das sollte eine opt-in-Funktion sein und nicht „so einfach passieren“; als Red-Hat-Mitglied konnte er eine lange Liste von Methoden nennen, wie man durch diesen Kanal Daten aus jeder HA-Installation weltweit abgreifen kann. Um 19:56 Uhr hinterließ Frenck den Satz „Dieser Fall ist geschlossen, da er nicht behoben werden kann. Entschuldigung.“ Der Fall wurde geschlossen.

20:12 Uhr: Der alte Benutzer mit der Anfrage 0x00string fordert eine Neuanmeldung mit der Bitte: „Wenn ihr die Sache nicht angemessen behandeln könnt, sagt es einfach, damit wir das Programm deinstallieren und einen neuen Branch erstellen können.“
20:14 Uhr: frenck sendet einen zweiten Abschiedsbrief, in dem er den Benutzern „Bedrohungen“ vorwirft und sagt: „Wenn das schon reicht, um die Installation und Fork zu veranlassen… 🤷 Dann macht es ruhig, schließlich handelt es sich um Open-Source-Software.“
20:33 Uhr: Die Anfrage wird auf HN veröffentlicht.
21:11 Uhr: Frencks Top-Beitrag mit einer Entschuldigung erscheint, in dem er den Befehl ha security options --pwned=false gibt und zugleich zugibt, dass die Option bereits existierte. Der Zustand der Anfrage ist „Closed“; frenck hat ihn oben im Repository markiert.

Kritik an der Hauptlinie: Das System ist in Ordnung, die Verwaltung hat Probleme.

Die erste Hauptlinie ist die Autorisierung. Die Funktion ist standardmäßig aktiviert, und der Auslöser sind alle Felder in den Add-Ons, die als „Passwort“ markiert sind. Der Benutzer weiß möglicherweise nicht genau, welche Konfigurationen zu dieser Kategorie gehören. Obwohl der Datenstrom nur einen Hash-Prefix sendet, gelangt er letztendlich an Drittanbieterdienste. Die Warnmeldungen waren vor diesem Versionupdate noch nie sichtbar. Standardmäßig „Opt-out“, keine Benachrichtigungen und Drittanbieter-Datenfluss – diese drei Faktoren zusammen bilden das, was Viss tatsächlich kritisiert. Die von ihm vorgeschlagene theoretische Angriffsfläche liegt ebenfalls auf diesem Niveau: Laut dem ursprünglichen Problem kann theoretisch jemand, der gegen die HA-Repositorys handelt, diese Mechanismen für böswillige Zwecke nutzen. Das ist die theoretische Angriffsfläche, die der Autor des Problems angibt – es handelt sich dabei nicht um bereits bestätigte Lücken, die in diesem Artikel nicht weiter erörtert werden.

Der zweite Hauptgrund für die Sperrung ist die Widersprüchlichkeit der Argumente. Ein Issue wird im Dokumentenlager erstellt, da der Schalter nicht in das Dokument aufgenommen wurde – es gibt also keinen Grund, ihn nicht im Dokumentenlager zu lagern. Der Kommentator HN mcmcmc hat diesen Punkt aufgedeckt: Die Option zur Sperrung dieser Funktion existiert bereits, sie wurde nur nicht dokumentiert. Deshalb ist das Dokumentenlager genau der richtige Ort, um einen Issue zu erstellen. Wenn die Entwickler diese Funktion jedoch mit der Begründung sperren, dass „es sich um ein Dokumentenlager handelt und Änderungen am Dokument keine Probleme mit der Funktion lösen können“, dann ist ihre Logik unstützbar.

Der dritte Hauptpunkt ist, dass die Art der Antwort das Thema verändert hat. Viss’ Argument ist ein Regierungsfehler, während Frencks erste Bewertung stattdessen 1Password als Vergleich heranzieht und das Thema auf „Auch andere tun das“ lenkt. Der satirische Kommentar des hochbewerteten Nutzers jackpepsi ist sehr repräsentativ: „Du magst denken, dass diese unangekündigte Scans eine Demütigung sind, aber wir können mit Mathematik beweisen, dass wir dich nicht demütigt haben.“ Technisch falsch zu sein und keine Berechtigung zu haben, sind zwei verschiedene Dinge; die erste Bewertung hat nur das Erste beantwortet.

Sprachliche und handelnde Prüfung: Vier Gesichter in 116 Minuten

Die Worte jener Nacht in der Reihenfolge aufzuzählen, ist eine bereits vorbereitete Materialien für eine Prüfung der Äußerungen. Um 19:15 Uhr: „Das ist keine Verletzung des Privatlebens“, mit einem Link zur Begründung. Um 19:56 Uhr: „Nicht reparieren, Entschuldigung“, das Thema wurde geschlossen. Um 20:14 Uhr: „Bedrohungen sind wirkungslos“ „Entfernen Sie die Fork, wenn Sie möchten, es ist jedenfalls offen“, das Thema wurde zweimal geschlossen. Um 21:11 Uhr: „Meine vorherige Antwort war noch respektloser als das, was dieses Thema verdient hat, ich entschuldige mich“, der Schalter wurde übergeben, das Offenlegungsmechanismus wurde veröffentlicht, die Ursachen des Ausbruchs wurden erklärt, mit einem Link zum Quellcode (dieser Kommentar wurde auf der Seite unterbrochen, der genaue Quellcodepfad wurde in diesem Artikel nicht vollständig überprüft, es wird nicht festgelegt). Zwischen den vier Gesichtern lagen nur 116 Minuten, und das, was zwischen ihnen geschah, war nur eines: HN hat 38 Minuten fermentiert.

Die Entschuldigung selbst ist erwähnenswert, denn sie liefert viele zusätzliche Informationen: Details zum Mechanismus, die Ursachen des Ausbruchs und der Befehl zur Schließung – all das fehlte in den ersten beiden Antworten. Das bedeutet, dass die Nutzer bereits in der ersten Runde etwas klarheit suchen wollten, und die Betreuer konnten diese Fragen tatsächlich beantworten, nur entschieden sie sich zunächst dafür, die Funktion zu schließen.

Auch die alten Probleme wurden angesprochen. Die Kommentatoren janice1999 und someguydave wiesen darauf hin, dass Frenck vor einigen Jahren in der Kontroverse um die PR #126326 von NixOS genau diese Art von Haltung zeigte – „Kann man es ändern oder nicht, ist eine eigene Entscheidung“. Dies gilt als sein übliches Kommunikationsverhalten. Nach den Vorgaben der roten Linie handelt es sich dabei um Angaben von Nutzern; dieser Artikel wird daher ohne feste Aussagen veröffentlicht. Ein weiterer Kommentator, hypfer, bezeichnete die Wiederholung alter Probleme als bad faith – dies wird ebenfalls aufgezeichnet.

Außerdem gibt es noch das GDPR. Der Kommentator Rygian vermutet, dass diese Integration in der EU möglicherweise illegal ist wegen GDPR, mit der Begründung, dass „PII ohne legale Grundlage abgerufen werden“. Die Kommentatoren deadbunny, Matticus_Rex und nicce widersprechen und sagen, dass nur die Hash-Prefixe gesendet werden, was keine PII darstellt. Beide Seiten haben ihre Argumente hinterlegt, es handelt sich dabei um eine unentschiedene Stellungnahme.

Was sagt man in der Kommentarbereich?

In den mehr als hundert Kommentaren gibt es neben den oben erwähnten Gruppen noch einige Stimmen, die es wert sind aufgezeichnet zu werden.

Konstruktive Vergleiche: Ein Internetnutzer identifizierte den Gründer von HA, balloob, und sagte, dass diese Funktion bereits seit fünf Jahren existiere und mit einer Dokumentlinks versehen sei. Der selbsternannten Privatsphärenwissenschaftler csoghoian schlug vor, anstatt diese Funktion einzuführen, stattdessen Passkey-Unterstützung hinzuzufügen. Er betonte, dass die Nutzer lange darum gebeten hätten und sogar Patches vorgelegt hätten, doch diese wurden abgelehnt. Die Identitäten beider Personen wurden nicht unabhängig überprüft; sie werden nach den Angaben des Internetnutzers behandelt.

Der Vertrauenskosten sind die stärkste Herausforderung. Die Kommentatoren onionisafruit und fg137 teilen, dass sie gerade dabei waren, HA Green-Hardware zu kaufen. Dies hat sie zurückgehalten und betont, was sie dazu veranlasst habe, zögern zu lassen: „Es war nicht die Übermittlung der Hashwert an haveibeenpwned, sondern die Reaktionen, die auf GitHub erhalten wurden.“ Die Kommunikationsweise eines Open-Source-Projekts hat direkt dazu geführt, dass sie bei dem Kauf der Hardware zögerten. Das ist das konkrete Beispiel für den Vertrauenskosten in der Community.

Auch der Gegenpartei sollte ihre Meinung einräumen. Der Kommentator ragall findet, dass die Antworten der Entwickler sehr vernünftig und zurückhaltend sind, während die Nutzer unhöflich sind. altairprime zeigt Mitgefühl mit den Wartungspersonen und sagt: „Entschlossene Softwareentwickler werden in einer Welt voller selbstgefälliger Widerstände immer weniger geschätzt.“ Diese Aussagen stehen im Widerspruch zur Hauptlinie, aber sie sind ein wesentlicher Bestandteil dieses Streits, daher werden sie hier nicht weggelassen.

Drei Dinge, die gewöhnliche Benutzer tun können

Erstens, wenn man HA verwendet und nicht überprüft werden möchte, sollte man es einfach ausschalten. Der Befehl lautet ha security options --pwned=false, der aus der Top-Entschuldigung des Entwicklers stammt. Die Zuverlässigkeit ist unumstritten. Dadurch wird auch etwas anderes deutlich: Diese Schaltfläche war zuvor nicht im Dokument enthalten. Wenn man sie nicht findet, bedeutet das nicht, dass sie nicht existiert.

Zweitens: Nutzen Sie die Gelegenheit, Ihre Passwörter zu überprüfen. Diese Warnung ist zwar beängstigend, aber sie tut gleichzeitig etwas Nützliches: Sie überprüft alle Felder in Ihren Add-ons, die als Passwort markiert sind, auf HIBP. Unabhängig von der Artikelsprache ist der Inhalt korrekt – Passwörter, die im Leaks-Datenbank auftauchen, sollten geändert werden. Ein schwaches Passwort zu ersetzen, ist vorteilhafter als darüber zu streiten, ob man es überprüfen sollte.

Drittens sollten die Reaktionen der Betreuer als Signal für die Wahl des Tools betrachtet werden. In diesem Fall war es die Sicherheit der Funktion selbst sowie die vorhandenen Dokumentationen, was die Nutzer wirklich beeindruckte – doch was sie tatsächlich erschütterte, war der Prozess, in dem die Issues zweimal streng abgelehnt wurden. Wenn Sie eine Open-Source-Software bewerten, bei der Sie Familiendaten anvertrauen müssen, sollten Sie sich die Art und Weise sowie die Wortwahl, mit denen die Issues abgelehnt werden, ansehen. Dort versteckt sich eine bessere Governance-Kultur als in dem README.

Schlussfolgerung

Angemessene Erklärung: Dieser Artikel begründet keine Strafbarkeit für irgendeine Seite. Die Identitäten von Viss, balloob und csoghoian wurden entweder selbst angegeben oder von Nutzern identifiziert; der Text ist begrenzt. Frenck antwortet als Member und kann als offizielle Stellungnahme gelten. Die theoretischen Angriffe werden nach dem Verständnis des Autors des Issues wiedergegeben, ohne bereits existierende Lücken aufzuzeigen. Die Behauptung, dass GDPR verletzt wird, ist eine Vermutung im Kommentarbereich, die sowohl positiv als auch negativ dargestellt wird. Der Quellcode in den Entschuldigungen wurde nicht vollständig überprüft, da der Text abgeschnitten ist; daher wird er nicht festgelegt. Die alten Probleme mit NixOS werden nach der Identifizierung durch Nutzer aufgezeichnet. Überprüfte Fakten sind: Issue #49314 mit vollständigem Zeitstempel, vier wichtige Aussagen, Schließkommandos, K-anonymitätsmechanismus und offizielle Dokumentation, Daten über die Verbreitung von HN (SnapShot vom 17. Oktober mit über 150 Unterstützungsstimmen), alles stammt aus GitHub Issues und HN. Zwei Punkte, auf die man achten muss: Erstens, ob HA offiziell den Schließschalter und die Mechanismen in das Dokument eingefügt hat, damit der nächste Benutzer nicht erst im Issue suchen muss, um zu erfahren, welche Rechte er dazu hat. Zweitens, ob die Funktion so geändert wird, wie Viss es wünscht, nämlich opt-in, oder zumindest eine Schließhinweise in der Warntextstelle angegeben werden. Wenn eines dieser Punkte eintritt, wird eine v2 veröffentlicht.

Referenzquelle

• GitHub Issue #49314 (home-assistant/home-assistant.io): Ursprüngliche Quelle, alle Zeitstempel und der ursprüngliche Text sind angegeben. Abgerufen am 2026-10-16, Endzustand: geschlossen. frenck ist auf „Top“-Status gesetzt.
• HN Story 50124251: Zugriff am 10-16 20:33 UTC, Snapshot am 10-17 Morgen mit 155▲/104💬. Der Text behauptet, dass „mehr als 150 Unterstützungsstimmen vorhanden sind und weiter steigen“. Die Kommentare von mcmcmc/jackpepsi/Rygian/deadbunny/Matticus_Rex/nicce/onionisafruit/fg137/balloob/csoghoian/ragall/altairprime/janice1999/someguydave/hypfer stammen von den Kommentatorn selbst, und der Text wird einzeln zugeordnet.
• Offizielle HA-Dokumentation auf der Seite more-info/pwned-passwords: Offizielle Beschreibung des K-anonymity-Mechanismus, vollständige Überprüfung.
• Cloudflare Blog validating-leaked-passwords-with-k-anonymity: frenck hat den ersten Beitrag veröffentlicht, was beweist, dass der gleiche Mechanismus in der Branche verwendet wird.
• frenck hat sich entschuldigt und die Angelegenheit offengelegt: Im Issue vom 2026-10-16 21:11 UTC wurde der Schließbefehl und die Quelle des Mechanismus angegeben. Die Kommentare wurden auf der Seite unterbrochen, und der Quellcode-Link wurde nicht vollständig überprüft.