Home Assistant token secrets are stored in plain text, according to a researcher who goes by theknell. The researcher’s post to the oss-security mailing list, dated 8 November 2026, says refresh tokens and their per-token JWT signing keys sit unhashed in one file. It adds that a password change revokes none of them, and that tests ran against home-assistant/core 2026.11.0 with no CVE assigned as of 9 November 2026.
No public reply from Home Assistant or its cloud partner Nabu Casa is on record. Theknell’s post cites the vendor’s own published count of two million homes running the platform, where it can hold the locks, the alarm, the garage and the camera feeds.
What Is a Refresh Token, and Why Doesn’t a Password Change Revoke It?
A password proves who a user is at login. A refresh token is a separate secret the app keeps afterward, so the user does not have to log in again every time.
Most systems store a password as a hash, a one-way scramble that cannot be reversed. Home Assistant does this for passwords, theknell’s post says, using bcrypt in a separate store from the token file.
- Refresh tokenA long-lived secret an app trades for a new short-lived access token, so the user is not asked to log in again.
- JWT signing keyThe secret that proves a signed token is genuine; whoever holds it can mint tokens that look valid.
- Long-lived access tokenA token type Home Assistant’s own docs recommend for scripts, meant to keep working for a long time without a login.
- Token revocationDeliberately invalidating a token so it stops working, separate from, and in addition to, a password change.
A leaked token on an ordinary web account can expose a database. Theknell’s post notes that Home Assistant’s own documentation calls the password the key to your home, while a leaked token is what a password change does not reach. That includes the locks, the alarm, the garage and the camera feed.
What theknell’s Home Assistant Token Secrets Post Says
theknell’s post says every refresh token’s secret, and its per-token JWT signing key, is saved in one file for every user: config/.storage/auth. It says that file holds the secrets as plain text, validated by a direct comparison, while the password file next to it uses bcrypt hashes.
Two of the three token classes never expire, the post says. Long-lived access tokens, the kind Home Assistant’s documentation recommends for scripts, are valid for ten years. The post also says the core API accepts a caller-chosen lifespan in days, with no upper bound stated.
- Password storeBcrypt-hashed; a password change rehashes only this record, theknell’s post says.Who can change itThe user, at any time
- Token store (.storage/auth)Holds refresh-token secrets and JWT signing keys as plain text, checked by direct comparison.Who can change itNo one; the post found no revocation call
- Settings backup (export)Carries .storage/auth inside it, so a restore brings back old tokens too; .storage/backup itself holds a plaintext backup password, the post says.Who can change itWhoever restores the backup
How a Stolen Token Outlives a Password Change
A password change does not touch any of these tokens, theknell’s post says. It lists four entry points, self-service, administrator, Supervisor reset and the command line, and says all four rehash the password record without making any token call.
theknell’s live test used the researcher’s own instance only. A refresh token copied out beforehand still minted fresh access after a real password change, and a ten-year long-lived token kept working too. The post adds that the automatic-backup password sits in plain text next to the token file, inside the same directory every backup archives. Every settings backup carries that file inside it too, so restoring an old backup brings its tokens back, even ones from before a password change.
theknell is careful about scope: this is not an unauthenticated network break. It begins with a read of the config directory or a backup. That read could be a support file shared by a user, a config folder synced somewhere it should not be, or one other file disclosure anywhere in the stack.
theknell’s post says any such read turns into durable access that survives a password change, which is the one fix most users reach for first. Eleven documented claims about the system were checked: three hold, five hold with a bound, and three do not, the post says.
The post credits what holds at the same weight: it calls the system’s token generation entropy impeccable, and it says access tokens themselves expire after thirty minutes. Neither finding changes who can use a stolen token today.
What Changes for Defenders
None of this changes what we recommend for any system that mixes long-lived tokens with a password reset flow. If theknell’s description is right, the safe assumption is that a password change alone does not revoke anything else.
- Rotate the long-lived tokensRevoke and reissue long-lived access tokens and refresh tokens directly, since a password change does not reach them on this account.
- Check backup handlingTreat a shared or synced backup as carrying live tokens, not just a password, per the post’s description of the backup file.
- Set a real lifespanAvoid a caller-chosen token lifespan with no upper bound; use the shortest duration the automation actually needs.
- Watch the restore pathA restored backup can bring back an old, already-exposed token, so review tokens again after any restore.
This sits in the same family as stealing secrets from configuration files, where a single file read outlasts a password change. It is also a reminder that leaked credentials and leaked tokens call for the same response: rotate first, do not assume a password reset covers it.
For backup hygiene specifically, see our note on immutable backups, which keep a restore point from being quietly altered. Our own playbook on responding to leaked credentials covers the rotation order step by step.