26f4ba7e89
Previous entry leaned on filler ("close the door behind it", "what
people expect") and gave only a vague behavioural summary. Replace
it with the actual mechanism: which table is touched, the transaction
boundary, the asymmetry between change (preserves caller) and reset
(revokes all), and why the session middleware needs no change.
Also drop the em dash in the metadata line.
Signed-off-by: Bryan Frimin <bryan@getprobo.com>
1.1 KiB
1.1 KiB
Security Notes
User-facing notes on security-relevant changes to Probo. For the vulnerability reporting process, see SECURITY.md.
Password changes invalidate existing sessions
2026-04-29, IAM
Password changes and resets now revoke existing sessions for the identity.
Previously, rotating a password did not touch iam_sessions rows: a stolen session stayed valid until its idle TTL elapsed, so a user whose account was compromised on another device could not evict that device by changing the password.
Inside the same transaction as the password update:
- A signed-in password change revokes every other active session for the identity and keeps the caller's current session.
- A forgot-password reset revokes all active sessions for the identity. The caller is anonymous (authenticated only by the reset token), so there is no current session to preserve.
The session middleware already rejects rows with expire_reason set, so revoked sessions are kicked out on the next request without any middleware change.
Reported by emimoir.