Home Assistant stores token secrets in cleartext; password changes revoke none, report finds

A researcher has published a full-disclosure report arguing that Home Assistant stores the secrets used for its authentication tokens unencrypted on disk, and that the remedy most users would try first — changing the account password — revokes none of them.

Token secrets sit in cleartext in one file

According to a November post to the Full Disclosure mailing list by a researcher signing as "knell", every user's refresh-token secret and the per-token JWT signing key are serialized in cleartext in a single file, config/.storage/auth. The report states that account passwords in the neighbouring store are bcrypt-hashed, but token secrets are not hashed at all; validation is described as a direct string comparison against the stored value. The findings were tested, the post says, against home-assistant/core 2026.11.0, frontend 20261028.4 and hass-nabucasa 2.8.1.

Tokens that outlive a password change

The report identifies three token classes and claims two of them — long-lived and system refresh tokens — are created with no expiry date. Long-lived access tokens, which the researcher notes are what Home Assistant's documentation recommends for scripts, are said to be valid for ten years, with the core API accepting a caller-supplied lifespan in days and no upper bound.

The post further claims that all four password-change paths in the product — self-service, administrator-initiated, a Supervisor reset and the command line — rehash the password record and make no token-related call at all.

The researcher says this was verified live on their own instance: after a genuine, verified password change, a refresh token copied out of .storage/auth beforehand still minted fresh access, and a ten-year long-lived token created beforehand still authenticated.

Backups compound the exposure

A fourth finding concerns backups. The automatic-backup password is allegedly written in plaintext to .storage/backup, inside the very directory that every backup archives. And because every settings backup carries .storage/auth within it, the post argues, restoring a backup resurrects the tokens that existed when that backup was taken.

What the report does and does not claim

The disclosure is explicit about its limits. It is not an unauthenticated network break; the starting point is the ability to read the config directory or a backup file. The claim is that any such read — a backup handed over for troubleshooting, a config folder synced to the wrong place, or a single file-disclosure bug anywhere in the stack — turns into long-lived access that survives a password change.

The researcher also checked eleven documented claims, reporting that three held, five held with a bound and three fell, and gives the project credit where the analysis supports it: token-generation entropy is described as impeccable, and access tokens reportedly live only thirty minutes. A GPG-signed paper accompanies the mailing-list post. The post itself does not record any response from Home Assistant's maintainers, and the claims rest on a single researcher's testing against their own installation.

Why it matters

Home Assistant's own security guidance leans heavily on choosing a strong, unique password, presenting it as the key to the home — and, by the vendor's published count cited in the report, the platform runs in about two million homes, controlling locks, alarms, garage doors, cameras and records of who is present. If the findings hold, that framing misleads users about where the real key lives: not in the password, but in a cleartext file that a password change never touches. The practical consequence is that a user who suspects a leaked backup or an exposed config directory cannot treat a password reset as incident response; the token material itself has to be considered compromised and revoked or regenerated. For a platform positioned as the security hub of a household, the distance between "I changed my password" and "the intruder is locked out" is the entire story.