cesnimda
32 lines
2.3 KiB
Markdown
32 lines
2.3 KiB
Markdown
# SEC-005A session and recovery revocation verification
|
|
|
|
Date: 2026-08-02
|
|
Status: `VERIFIED LOCALLY`; browser and production verification remain.
|
|
|
|
## Implemented transitions
|
|
|
|
- Logout is anonymous/idempotent, exempt from CSRF gating, best-effort reads valid or expired local session cookies, revokes only the matching `(userId, sid)` row, and always clears session/CSRF cookies.
|
|
- Local JWT validation now requires the principal user ID and `sid` to match the same live row.
|
|
- Successful password reset revokes every target session and trusted device while preserving 2FA configuration; reset mail is sent only for confirmed local-password accounts with a generic response otherwise.
|
|
- Successful password change revokes every old session, creates one replacement session, removes other trusted devices, and retains the current trusted device.
|
|
- Pending 2FA tokens issued by real sign-in flows carry the user's security stamp; password/reset stamp changes invalidate the pending challenge.
|
|
|
|
## Commands and results
|
|
|
|
| Command/check | Result |
|
|
|---|---|
|
|
| focused auth/session/2FA controller suite | Pass; 48/48 after adding the expired-cookie case |
|
|
| full backend Release suite | Pass; 497/497 |
|
|
| copied-principal validation after logout | Rejected as expected |
|
|
| reset with two target sessions/devices plus another user | Target revoked/removed; other user untouched; 2FA preserved |
|
|
| password change with two sessions and three device rows | Old sessions revoked; one new session; current device retained; other-user row untouched |
|
|
| pending 2FA with stale security stamp | Rejected and consumed |
|
|
|
|
## Limitations and rollback
|
|
|
|
- No real email was sent and no browser/multi-tab flow was run.
|
|
- Password change deliberately revokes before issuing the replacement. If replacement issuance fails, the password is changed and the user must sign in again; no old token remains valid.
|
|
- Existing pending tokens issued before deployment have no stamp and retain their five-minute lifetime for compatibility. All tokens issued after deployment are stamp-bound.
|
|
- Production rollout should verify copied-cookie invalidation, session-row counts, reset with 2FA and trusted-device behavior using disposable accounts.
|
|
- Rollback requires application binaries only; no schema changed. Do not restore non-revoking logout/reset behavior.
|