En Home Assistant la contraseña no es la llave

La documentación de Home Assistant dice que la contraseña «es la llave de tu casa». Un informe publicado este fin de semana en la lista oss-security sostiene lo contrario: quien consiga leer la carpeta de configuración o una copia de seguridad puede quedarse con un acceso que sobrevive a un cambio de contraseña. El texto, firmado como «the knell», se ha probado contra la versión 2026.11.0 de home-assistant/core.

No es un asunto menor. Según el propio informe, Home Assistant está instalado en dos millones de hogares, por la cifra que publica el proyecto, y en ellos controla cerraduras, alarmas y puertas de garaje.

Qué ha encontrado el informe

El autor detalla cuatro problemas:

• Tokens en texto plano. El secreto de cada token de refresco, junto con la clave con la que se firma cada uno, se guarda sin cifrar ni resumir en un único archivo, config/.storage/auth, para todos los usuarios. Las contraseñas, en cambio, sí se almacenan con bcrypt. La validación de los tokens es una comparación directa con el valor guardado.
• Tokens que no caducan. Según el informe, de los tres tipos de token de refresco, dos (los de larga duración y los del sistema) se crean sin fecha de caducidad. Los tokens de larga duración que la documentación recomienda para scripts valen diez años.
• Cambiar la contraseña no revoca nada. Las cuatro vías para cambiarla (el propio usuario, un administrador, el reinicio desde Supervisor y la línea de órdenes) actualizan la contraseña, pero ningún token queda invalidado.
• La contraseña de las copias, a la vista. La contraseña de las copias de seguridad automáticas se guarda en texto plano en .storage/backup, dentro del mismo directorio que se archiva en cada copia. Además, toda copia de la configuración incluye el archivo .storage/auth.

El autor asegura haberlo comprobado en su propia instalación: tras un cambio de contraseña real y verificado, un token copiado antes de .storage/auth seguía generando accesos nuevos, igual que un token de diez años.

Lo que no es

El propio informe acota el alcance: no se trata de un fallo explotable desde la red sin autenticación. Todo empieza con la lectura de la carpeta de configuración o de una copia de seguridad. La gravedad está en lo que pasa después: una copia compartida para pedir ayuda, una carpeta sincronizada donde no debía o una fuga de archivos en cualquier punto del sistema se convierten en acceso duradero a la casa. Y la primera reacción de casi cualquiera, cambiar la contraseña, no sirve.

El informe también reconoce lo que funciona: la entropía con la que se generan los tokens es «impecable», según sus palabras. De once afirmaciones de la documentación revisadas, tres se sostienen, cinco se sostienen con matices y tres no. El material disponible no recoge ninguna respuesta del proyecto ni fecha de corrección.

Qué se puede hacer mientras tanto

A partir de lo que describe el informe, la prudencia pasa por tratar las copias de seguridad y la carpeta de configuración como si fueran las llaves de casa:

• No compartir copias de seguridad ni archivos de configuración al pedir soporte en foros o chats.
• Revisar si la carpeta de configuración o las copias se sincronizan con servicios en la nube o con equipos que no se controlan.
• Si se sospecha que alguien ha podido leerlas, no confiar en el cambio de contraseña: según el informe, los tokens siguen siendo válidos y habría que invalidarlos.

El autoalojamiento es la mejor respuesta a la domótica que depende de servidores ajenos, pero tener los datos en casa no los protege por sí solo. Un proyecto de este tamaño, con este tipo de dispositivos bajo su control, también necesita auditorías independientes como esta.

Fuente: oss-security