Contexte et découverte
Une analyse réalisée sur Home Assistant version 2026.11.0 (frontend 20261028.4, hass-nabucasa 2.8.1) révèle que les secrets des tokens d’authentification sont conservés en texte clair dans le fichier config/.storage/auth. La documentation officielle indique que le mot de passe est la clé du domicile, mais les tests montrent que le mot de passe ne révoque aucun token et que les secrets ne sont pas hachés, contrairement aux mots de passe qui utilisent bcrypt.
Mécanisme de stockage des tokens
Chaque token de rafraîchissement possède deux éléments : un secret et une clé de signature JWT propre au token. Ces deux valeurs sont sérialisées sans aucune transformation cryptographique dans .storage/auth. La validation s’effectue par comparaison directe de chaîne, ce qui rend la compromission du fichier suffisante pour générer de nouveaux accès. Deux classes de tokens – les long‑lived refresh tokens et les system refresh tokens – sont créées avec expire_at = None, c’est‑à‑dire sans date d’expiration. Les tokens d’accès à longue durée, recommandés pour les scripts, sont configurés pour une validité de dix ans, et l’API accepte un paramètre de durée en jours sans plafond, permettant théoriquement des tokens valables indéfiniment.
Implications sécuritaires et limites
Le scénario d’attaque ne nécessite aucune interaction réseau. Un acteur qui accède au répertoire de configuration – par exemple via une sauvegarde partagée ou une synchronisation de dossiers – peut extraire les secrets, créer de nouveaux tokens et conserver un accès persistant même après un changement de mot de passe. Les tests en conditions réelles ont confirmé que, après une modification de mot de passe, un token de rafraîchissement préexistant continue de générer des accès valides, et un token à longue durée reste authentifié. De plus, le mot de passe de sauvegarde automatique est stocké en texte clair dans .storage/backup, et chaque archive de paramètres inclut le répertoire .storage/auth. Ainsi, la restauration d’une sauvegarde réintroduit automatiquement les tokens compromis.
Recommandations et mitigations
Les mesures de mitigation doivent d’abord viser la protection du répertoire .storage. Le chiffrement au repos du fichier auth ou son déplacement hors d’un répertoire accessible aux sauvegardes résout le vecteur principal. En outre, l’implémentation d’une rotation obligatoire des tokens lors d’un changement de mot de passe éliminerait la persistance décrite. Limiter la durée maximale des tokens d’accès à une valeur raisonnable (par exemple 30 jours) et imposer une date d’expiration explicite pour les tokens de rafraîchissement réduirait la surface d’exposition. Enfin, la documentation doit refléter la réalité du mécanisme d’authentification afin d’éviter une fausse confiance des utilisateurs.
gpg --import knell-public.asc
gpg --verify paper-ha-FINAL-2026-11-04.md.asc
