Home Assistant est exposé à un scan non autorisé des mots de passe des utilisateurs

D’abord, fixons le calendrier : le 16 octobre (UTC), l’utilisateur Viss a ouvert un ticket #49314 dans le dépôt des documents de Home Assistant. Le titre du ticket était « Je n’ai jamais autorisé une intégration qui scanne mes secrets », et il faisait référence à une fonctionnalité du système qui permettait d’extraire les informations de mot de passe configurées localement pour les consulter en ligne et les transmettre à une base de données. Le maintaineur frenck a d’abord réagi de manière hostile, puis a fermé le ticket à deux reprises, avec une attitude de plus en plus hostile jusqu’à dire « Désinstallez si vous le souhaitez ». À 20h33, ce ticket a été soumis sur Hacker News, où il est rapidement sorti du top des articles les plus consultés. Le 17 octobre, avant le matin, il avait déjà reçu plus de 150 votes de soutien et plus de 100 commentaires, et ce nombre continuait d’augmenter. À 21h11, soit 116 minutes après la première réponse, frenck a publié un long commentaire d’excuse, reconnaissant que ses réponses précédentes étaient trop brusques, et a fourni une commande de fermeture qui n’était pas mentionnée dans les documents. La fenêtre de 48 heures courait du 16 au 18 octobre, et cet article se situe donc dans cette période. Les identités de Viss, frenck et des autres commentateurs qui apparaîtront plus loin ont été confirmées par eux-mêmes ou par des utilisateurs de la communauté. Lorsque l’identité est mentionnée, elle est spécifiée ; les citations originales peuvent être utilisées directement, car le ticket et Hacker News sont des sources publiques. Tous les timestamps cités proviennent du ticket #49314 et de Hacker News.

Que s’est-il passé ?

La fonction de dispute est en réalité une fonctionnalité ancienne. Selon les informations fournies par frenck dans sa note d’excuse, cette vérification existe depuis de nombreuses années dans Supervisor. Le principe est de scanner les champs marqués comme mot de passe dans les configurations des add-ons, de effectuer une hachage SHA-1 localement, et de transmettre seulement les 5 premiers caractères du résultat d’hachage au service de recherche de mots de passe piratés Have I Been Pwned (HIBP). HIBP renvoie ensuite une liste de hachages avec le même préfixe, et la comparaison finale est effectuée localement. Ce mécanisme s’appelle K-anonymity : ni le texte original du mot de passe ni le hachage complet ne sortent du système local. 1Password, Chrome et Firefox utilisent le même système, et les documents officiels de HA en ont déjà parlé. Plus précisément, après calcul de la SHA-1 localement, on extrait les 5 premiers caractères hexadécimaux, soit environ 20 bits. Ce préfixe est ensuite utilisé pour rechercher dans l’API range de HIBP. HIBP renvoie alors tous les hachages avec ce préfixe, généralement plusieurs centaines, et la comparaison complète est effectuée localement. HIBP reçoit simplement un préfixe ; il est impossible de déduire quel mot de passe il s’agit, ni quel appareil l’a utilisé. Sur le plan cryptologique, cette fonctionnalité n’a aucun défaut, et cela est clairement indiqué dans les documents. La controverse ne concerne pas le mécanisme.

Le problème réside dans la perception du utilisateur. Viss a vu pour la première fois l’avertissement « Scanning my secrets » dans la version 2026.10.1 ; il a conclu qu’il n’avait jamais donné son autorisation pour cette fonctionnalité. Il demande que cette fonction soit modifiée en opt-in, c’est-à-dire qu’il faille obtenir l’accord avant de effectuer le scan. Pourquoi cette ancienne fonctionnalité ne fonctionne-t-elle plus ? Frenck a expliqué dans son message d’excuse : une dernière version a corrigé le bug qui avait provoqué cet avertissement, et les utilisateurs plus anciens ne l’avaient pas vu auparavant.

Voici la chaîne d’améliorations de cette soirée, avec toutes les timestamps : à 19h15, frenck a publié sa première critique, commençant par « Oh hi there 👋 », et a qualifié cela de « non-croisement de privé ». Il a cité 1Password comme exemple de logiciels qui font la même chose, en ajoutant des liens vers le blog K-anonymity de Cloudflare et Wikipédia. À la fin, il a ajouté : « Ce que l’on peut dire, c’est qu’il faut apprendre quelque chose de cette publication, car les secrets que vous utilisez sont déjà dans une base de données exposée, facilement exploitables ». À 19h48, Viss s’est présenté et a répondu, affirmant qu’il dirigeait le Phobos Group, faisait des conférences sur la sécurité depuis longtemps, connaissait l’auteur de HIBP, Troy, et avait utilisé 1Password en 2011 en tant que membre unique de l’équipe rouge sur Twitter (tous ces témoignages sont personnels, non vérifiés indépendamment). Son argument principal n’a pas changé : il s’agirait d’une fonctionnalité opt-in, et ce n’était pas censé arriver « simplement ». En tant que membre de l’équipe rouge, il pouvait énumérer une longue liste de moyens d’exploiter cette porte d’entrée pour obtenir des informations depuis chaque serveur HA à travers le monde. À 19h56, frenck a laissé une note : « Ce problème est clos car il ne peut pas être corrigé. Désolé ». Le sujet a donc été fermé.

20h12, un ancien utilisateur avec la requête 0x00string demande à être réouvert, en disant : « Si vous ne souhaitez pas traiter cette affaire de manière raisonnable, dites-le simplement, afin que nous puissions fermer et repartir sur une autre branche ». À 20h14, frenck émet une deuxième lettre de refus, accusant l’autre partie de « menaces et intimidations », et déclarant : « Si cela suffit pour que vous fermiez et forkiez… 🤷 Alors faites comme vous le sentez, après tout, c’est un logiciel ouvert ». À 20h33, l’affaire est publiée sur HN. À 21h11, une excuse de frenck apparaît en haut des messages, avec l’ordre de fermeture ha security options --pwned=false, et il admet que le bouton de fermeture existait déjà. L’état final de l’affaire est Fermé, et frenck l’a placé en haut du répertoire.

Critique principale : Le mécanisme est bon, mais la gestion est mauvaise

La première ligne principale est l’autorisation. La fonctionnalité est activée par défaut, et les conditions de déclenchement sont les champs marqués comme “password” dans toutes les configurations des add-ons. Les utilisateurs ne savent pas nécessairement quelles configurations seront classées dans cette catégorie. Bien que le flux de données utilise uniquement un préfixe haché, il s’agit en fin de compte d’un service tiers. De plus, les messages d’avertissement n’avaient jamais été mentionnés avant cette mise à jour. L’option par défaut “opt-out”, l’absence de messages d’avertissement et le flux de données provenant de tiers sont les trois facteurs qui constituent réellement la source des plaintes de Viss. La théorie d’attaque suggérée par lui se situe également à ce niveau : selon les mots de son issue, les acteurs malveillants du dépôt HA pourraient théoriquement utiliser ce mécanisme pour nuire. C’est la théorie d’attaque indiquée par l’auteur de l’issue, et non une vulnérabilité confirmée ; donc, elle n’est pas classée ici.

Le deuxième point principal est la raison de fermeture qui est contradictoire en soi. L’option de fermer cette fonctionnalité existe déjà, mais elle n’a pas été documentée ; donc le lieu approprié pour soulever ce problème est précisément le dépôt des issues. Cependant, les maintaineurs, en affirmant « C’est un dépôt de documents, il n’est pas possible de résoudre les problèmes de fonctionnalité en modifiant le document », ne tiennent pas leur position logiquement.

La troisième ligne directrice est que la manière de répondre a détourné l’objet du débat. L’argument de Viss est qu’il s’agit d’une erreur de gestion, tandis que le premier commentaire de Frenck fait une analogie avec 1Password, ramenant le sujet à « les autres font la même chose ». Le commentaire sarcastique de jackpepsi, un contributeur bien noté sur HN, est très représentatif : « Vous pouvez trouver que cette scanographie inattendue est humiliante, mais nous pouvons prouver mathématiquement que nous ne vous avons pas humilié. » Il y a une différence entre le fait qu’il n’y ait pas de licence technique et le fait qu’il n’y ait pas de permission procédurale ; le premier commentaire ne répond qu’à ce premier point.

Audit des paroles et des actes : quatre visages en 116 minutes

Voici la traduction en français :

Énumérer les paroles de cette soirée dans l’ordre constitue un document d’audit des propos et actions prêt à l’emploi. À 19h15, « Ce n’est pas une violation de la vie privée », avec un lien pour prouver cela. À 19h56, « Won’t fix, désolé », l’issue est fermée. À 20h14, « Les menaces et intimidations ne servent à rien » « Désinstallez le fork si vous le souhaitez, de toute façon c’est open source », l’issue est fermée une deuxième fois. À 21h11, « Ma réponse précédente était encore plus méprisante que ce qu’il mérite, je m’excuse », remettant le commutateur, le mécanisme de divulgation, l’explication des causes de la crise, avec un lien vers le code source (ce commentaire a été coupé sur la page, la route exacte du code source n’a pas été complètement vérifiée dans cet article, donc je ne le note pas). Quatre visages se sont succédés en seulement 116 minutes, et une seule chose s’est produite entre eux : l’HN a fermenté pendant 38 minutes.

Les excuses données méritent d’être notées, car elles fournissent de nombreuses informations supplémentaires : les détails du mécanisme, les causes de l’épidémie, les commandes pour fermer, tout cela n’était pas présent dans les deux premières réponses. En d’autres termes, ce que les utilisateurs voulaient savoir au premier tour, les mainteneurs ont réussi à répondre, mais ils ont choisi de fermer la discussion plutôt que de continuer.

Les anciennes histoires ont également été réexaminées. Les commentateurs HN janice1999 et someguydave ont identifié que frenck, il y a quelques années, dans la controverse du PR #126326 de NixOS, avait le même attitude de « soyez libre de modifier ou non, c’est votre décision ». Ils considèrent que c’est leur mode de communication habituel. Selon les critères établis, cela est identifié par les internautes, mais cette critique n’est pas certaine. Un autre commentateur, hypfer, pense que réexaminer les anciennes histoires est de mauvaise foi, ce qui est également noté ici.

Il y a aussi le RGPD. Le commentateur Rygian suppose que cette intégration pourrait être illégale dans l’UE en raison du RGPD, sous prétexte que « l’extraction de PII sans fondement légal » ; les commentateurs deadbunny, Matticus_Rex et nicce répliquent qu’il s’agit simplement d’un préfixe de hachage, ce qui ne constitue pas de PII. Les arguments sont valables, mais cette analyse n’est pas définitive.

Comment le public comment ?

Parmi plus d’un cent commentaires, en plus des mouvements mentionnés ci-dessus, il y a aussi plusieurs voix qui méritent d’être enregistrées.

Contraste constructif : Certains internautes ont identifié le fondateur de HA, balloob, qui affirme que cette fonctionnalité existe depuis cinq ans et fournit un lien vers le document correspondant. CSoghoian, qui se présente comme un spécialiste en privacité, suggère qu’il serait préférable d’ajouter le support de passkey plutôt que de continuer avec cette fonctionnalité, car les utilisateurs ont longtemps demandé une telle fonctionnalité et même soumis des patchs, mais ceux-ci ont été rejetés. Aucune des deux identités n’a été vérifiée de manière indépendante ; les informations sont donc basées sur les dires des internautes.

Le coût de la confiance est particulièrement frappant. Les commentateurs onionisafruit et fg137 ont tous deux indiqué qu’ils étaient sur le point d’acheter du matériel HA Green, mais cette décision les a amenés à hésiter, soulignant que ce qui les a freinés n’était pas le fait de fournir des hash à haveibeenpwned, mais plutôt les réactions reçues sur GitHub. La manière dont un projet open source communique affecte directement la décision d’acheter du matériel ; c’est là l’exemple le plus concret du coût de confiance au sein de la communauté.

Il faut également prendre en compte le point de vue adverse. Le commentateur ragall estime que la réponse des développeurs est très raisonnable et modérée, tandis que les utilisateurs se montrent plutôt impolis. altairprime, quant à lui, compatit avec les maintaineurs, affirmant que « les créateurs de logiciels déterminés perdent en popularité au milieu d’une vague d’opposition arrogante ». Ces opinions sont en contradiction avec celles du projet principal, mais elles font partie intégrante de ce débat, et ne seront donc pas retirées.

Les utilisateurs ordinaires peuvent faire trois choses.

Premièrement, pour ceux qui utilisent HA et ne veulent pas être détectés comme vulnérables, il suffit d’activer cette option. L’instruction est ha security options --pwned=false, tirée de la note d’excuse publiée par le mainteneur. La fiabilité de cette option n’est pas sujette à controverse. Cela indique également une autre chose : cette option n’était pas précédemment mentionnée dans les documents ; le fait que vous ne puissiez pas la trouver ne signifie pas qu’elle n’existe pas.

Deuxièmement, profite de l’occasion pour vérifier la configuration de vos mots de passe. Bien que cette alerte soit effrayante, elle fait également une chose utile : elle examine toutes les champs marqués comme « mot de passe » dans vos configurations d’add-on sur HIBP. Sans tenir compte de l’attitude, le contenu est correct : les mots de passe qui apparaissent dans la base de données des fuites doivent être changés. Remplacer les mots de passe faibles est plus avantageux que de discuter du bien-fondé de cette action.

Troisièmement, considérez la posture de réponse des mainteneurs comme un signal de choix du modèle. Dans cet incident, la sécurité de la fonctionnalité elle-même et les documents existants ne sont pas le problème ; ce qui vraiment perturbe les utilisateurs, c’est le processus par lequel les issues sont fermées de manière stricte à deux reprises. Lorsque vous évaluez un projet open source dont vous devrez confier les données familiales, consultez la manière et les mots utilisés pour fermer les issues ; la culture de gestion cachée là-bas est plus honnête que le README.

Conclusion

Déclaration de mesure : Cette publication ne condamne aucun parti. Les identités de Viss, balloob et csoghoian sont rapportées par eux-mêmes ou identifiées par les internautes ; le texte est limité dans sa portée. Frenck répond en tant que membre, ce qui peut être considéré comme une réponse officielle. Les attaques théoriques sont rapportées selon la version des auteurs de l’article, sans indiquer les failles existantes. La thèse concernant le GDPR est une supposition du commentaire, présentée de manière équilibrée. Le chemin de code dans les excuses est incomplet à cause de la coupure de la page, donc il n’est pas indiqué de manière définitive. Les anciennes affaires concernant NixOS sont enregistrées selon les identifications des internautes. Les faits vérifiés sont : le timestamp complet de l’issue #49314, quatre phrases clés, la commande d’arrêt, le mécanisme de K-anonymity et les documents officiels, ainsi que les données de diffusion de HN (plus de 150 votes d’appui en snapshot du 17 octobre), tous provenant de l’issue GitHub et de HN. Deux points à surveiller : premièrement, si HA ajoute une explication sur le mécanisme d’arrêt dans le document, afin que les utilisateurs suivants ne doivent pas consulter l’issue pour savoir leurs droits ; deuxièmement, si la fonctionnalité est modifiée comme souhaité par Viss en opt-in, ou au moins une indication d’arrêt est donnée dans le message d’avertissement. Si cela se produit, une version v2 sera publiée.

Source de référence

• Problème GitHub #49314 (home-assistant/home-assistant.io) : Source directe, tous les timestamps et l’origine des textes sont respectés. Ouvert le 16-10-2026, état final “Closed”, frenck est en haut de la liste.
• Histoire HN 50124251 : Envoi le 16-10-2026 à 20:33 UTC, snapshot du 17-10-2026 à 155▲/104💬. Le texte mentionne “plus de 150 votes de soutien, le nombre augmente encore”. Les commentaires de mcmcmc/jackpepsi/Rygian/deadbunny/Matticus_Rex/nicce/onionisafruit/fg137/balloob/csoghoian/ragall/altairprime/janice1999/someguydave/hypfer sont des descriptions personnelles des commentateurs, le texte est attribué à chacun d’eux.
• Documentation officielle HA sur la page more-info/pwned-passwords : Explication officielle du mécanisme K-anonymity, avec vérification complète du contenu.
• Blog de Cloudflare validating-leaked-passwords-with-k-anonymity : frenck a fait une première évaluation de son propre commentaire, prouvant que ce même mécanisme est utilisé dans le secteur.
• Excuse publiée par frenck en haut de la liste : Dans le problème, à 21:11 UTC du 16-10-2026, l’ordre de fermeture et l’origine du mécanisme sont dévoilés. Les commentaires ont été interrompus sur la page, et les liens source n’ont pas été vérifiés complètement.