Home Assistant tokens stay valid after password changes

Home Assistant’s own documentation calls the account password “the key to your home.” A report posted to oss-security argues that is not how the system actually behaves.

Against Home Assistant core 2026.11.0, the reporter showed that refresh-token secrets and per-token JWT signing material for every user are stored in cleartext in the instance’s auth storage, while neighbouring password records use bcrypt. Validation of those token secrets is a direct string comparison. Two token classes (long-lived and system refresh tokens) are created with no expiry; documentation-recommended long-lived access tokens last ten years, and the API accepts a caller-chosen lifespan in days with no upper bound.

Changing the password, through self-service, admin, Supervisor reset, or the command line, rehashes only the password record and revokes none of the outstanding tokens. The automatic-backup password is likewise kept in plaintext beside the same storage that backups archive, so a settings backup carries the auth material and a restore can bring old tokens back to life.

The issue is not a remote unauthenticated break. It starts with a read of the config directory or a backup file. Once that material is obtained, a password change does not cut off access: tokens copied beforehand still minted fresh sessions after a verified password change on the reporter’s own instance. Given Home Assistant’s published footprint of roughly two million homes controlling locks, alarms, cameras, and occupancy data, any leaked backup or mis-synced config folder becomes durable, password-resistant control of the home.

The disclosure was published the same day without prior coordination with the project. List replies said the Open Home Foundation had been unaware until the message was forwarded, and several participants criticised the no-notice policy. The reporter stated that day-of publication is intentional and invited public correction of any inaccurate claim.