What happened
After a key leaked, we rotated it and assumed the exposure was over. A while later we realised that sessions issued while the old key was in use were still being accepted, for up to 24 hours after the rotation.
That meant that anyone who had already obtained a valid session could keep using it even though the leaked key itself was dead.
Why it happens
A key and a session are separate things with separate lifetimes. A signed, stateless session carries its own expiry and is accepted until it expires, unless the server also checks a revocation list or a session version. Replacing a key does not automatically invalidate everything that key helped create.
The exact behaviour depends on the setup. If sessions are signed with the leaked secret and the old signing key is removed straight away, they usually stop verifying. If the verifier keeps accepting the old key during a grace period, which is common during rotations, they keep working until that period or their own expiry ends.
What we do now
Our incident checklist now treats rotation as only the first step. We replace the key, then revoke active sessions and tokens that could have been issued under the old one, using a session version bump, a deny list or deleting them from the store.
We then search the logs for any use of the old key or of sessions from the exposure window. That tells us whether someone actually used them, and it feeds the decision on what else to notify or reset.
Quick checklist
- 1Replace the leaked key and remove the old one from verification.
- 2Revoke active sessions and tokens that may have been issued under the old key.
- 3Shorten or skip any grace period for old keys during an incident.
- 4Search the logs for use of the old key and of suspicious sessions.
- 5Record what was found in the incident notes.
Rule of thumb
After a leak, replace the key and also revoke what it signed, then check the logs for use of the old one.