Code RoomSession token fixation detection
HardPrep Room Coding #292

Session token fixation detection

CodingSecuritySenior–Staff~30 min

Replay a session-token lifecycle to detect fixation. Process an ordered list of events; each is one of ['issue', token], ['auth', token] (privilege elevation / login), or ['use', token]. Rules: an 'issue' registers a token as valid+unauthenticated. An 'auth' on a currently-valid token must ROTATE it: the old token is invalidated and a new token (given as a third element ['auth', old, new]) becomes valid+authenticated; auth on an unknown/invalid token is ignored. A 'use' of a token is SECURE only if the token is currently valid. Crucially, a token that was authenticated without rotation (i.e. the SAME token id appears both before and after auth) is a fixation risk. Return the count of 'use' events that operate on a valid token that was authenticated via proper rotation (old != new) — i.e. count secure authenticated uses.

Implement
count_secure_uses(events: list[list]) → int
Examples
in[[["issue","t1"],["auth","t1","t2"],["use","t2"]]]out1
What a strong answer looks like

State your approach and its time/space complexity out loud before you optimize. Handle the edge cases (empty input, duplicates, overflow), and say why you chose this over the brute force. Green tests are the floor, not the grade.

0:00 of about 30 min
InputExpectedGot
[[["issue","t1"],["auth","t1","t2"],["use","t2"]]]1not run yetsample