skip to content

After withdrawing the leaked collector credential, how do you prove it no longer authenticates instead of assuming it?

level: seniorimportance: should knowfreq 41%

answer

  1. assumption is not evidence
  2. acceptance can live in several places
  3. present the old value, expect refusal
  4. replicas and cached decisions lag
  5. record the time of first refusal

basics

~20 s

Present the actual old value to every system that honours it and require a refusal, then record the time of the first refusal. A withdrawal command that returned success is a request that was accepted, not a result you have observed.

solid answer

~40 s

The claim you need is 'the old value is refused', and the only evidence that matches it is an attempt with that exact value being refused. Run the probe against each system that honours the credential, and against replicas where acceptance is distributed, because a withdrawal can land in one place and leave another honouring it — a second registration, a replica that has not converged, a cached authentication decision. Record the time of the first refusal: that timestamp is the end of the exposure window, and any successful use of the old value recorded after it means the withdrawal is incomplete rather than that someone got back in. Run the probe once, from an identity you control, and announce it so nobody chases your own traffic.

code

pseudocode · 14 lines
pseudocode
cutoff = now()
withdraw(oldValue, at = acceptingSystems)       // a request, not yet a result

for each system in acceptingSystems:            // one attempt per place it is honoured
    assert attemptAuth(system, oldValue) == REFUSED
    for each replica in system.replicas:        // acceptance may be served from several
        assert attemptAuth(replica, oldValue) == REFUSED

firstRefusedAt = cutoff                          // the end of the exposure window

laterUses = readRecords.where(value == oldValue
                          and outcome == SUCCESS
                          and time > firstRefusedAt)
assert laterUses.isEmpty()                       // otherwise a system you never listed honours it

go deeper

for a junior

Recall that a withdrawal is believed only once the old value has actually been refused; a command that returned success is a request that was accepted, not an outcome you observed.

for a middle

Explain where acceptance can hide: several systems honouring the same credential, a second registration nobody listed, replicas that have not converged, and cached validation decisions.

for a senior

Show the probe you would run — the exact old value, once per system, from an identity you control, announced so nobody chases it — and the timestamp you take from the first refusal.

for a principal

Decide what the organisation must be able to prove afterwards, and make the records and the probe answer it together, so nobody has to reconstruct the night from memory a month later.

## Why the assumption fails A withdrawal is a request to a system to stop honouring a value. Between "the request returned success" and "the value is refused everywhere" sit several ordinary mechanisms, each of which has embarrassed a real response: - **More than one system honours it.** A credential shared by a fleet has often been registered in a second place — a standby endpoint, a regional twin, an older integration nobody listed. - **Replicas converge at their own pace.** Where acceptance is distributed, the change is a write that propagates, and propagation is not instant. - **A decision was cached.** Some systems cache the result of validating a credential for a period, so the old value keeps working until that entry expires. - **A session already exists.** A credential refused from now on says nothing about a session that was established with it and is still running. That is a separate thing to end, and forgetting it is why "we revoked it" and "they were still in" coexist. - **The withdrawal landed next door.** Similar account names at two in the morning do what you would expect. ## The probe The evidence that matches the claim is narrow: take the actual old value, present it to the system that honours it, and require refusal. Do it for every system on the list, and for the replicas behind them where that is how acceptance is served. Then take the time of the first refusal and write it down. Things that are **not** this evidence, however comforting: - the store now serves the replacement value; - the withdrawal command returned success; - no holder has reported an error since (the holders that already moved are healthy either way); - the attacker's traffic stopped (they may simply be quiet). ## What the recorded time buys you 1. **A defensible end to the exposure window.** "Refused at 03:14" is a fact; "some time that night" is a reconstruction, and reconstructions get worse every day after the incident. 2. **A test for completeness.** Read records showing a successful use of the old value *after* that timestamp do not mean the attacker returned — they mean some system you did not list still honours it. That is the single most useful query to run the next morning. 3. **A boundary for everything that follows.** Whatever else is decided about the incident, work after the cut-off is about a credential that no longer works, which is a different conversation from work before it. ## Running the probe without making things worse 1. Use the exact old value — not a variation, not a re-derived one. A near-miss proves nothing about the value that leaked. 2. Attempt it once per system. Repeated attempts are noise in exactly the records you are about to read. 3. Do it from an identity you control, and announce it in the response channel with the time, so nobody spends twenty minutes chasing your own probe as a live intrusion. 4. Do not create a new copy of the old value anywhere while probing. Pasting it into a ticket, a chat thread or a script that gets committed re-leaks the thing you are trying to kill. 5. Only test systems you are authorised to test. If a third party honours the credential, the refusal has to come from them, in writing, with a time. ## When you cannot probe Sometimes an attempt is genuinely unavailable — the accepting system belongs to someone else, or a failed attempt triggers a lockout you cannot afford. Then say what you have instead of overstating it: a confirmation from the party that operates the system, the absence of successful use in records you trust, and a note that refusal was not directly observed. That is a weaker claim, and writing it down as a weaker claim is the professional move. The failure mode this whole section exists to prevent is a response that closes with "revoked" in the record and a working credential in the wild, and the gap between those two is exactly one unperformed attempt.

  • What should the probe itself avoid doing?
    Avoid creating a fresh copy of the leaked value: pasting it into a ticket, a chat thread or a throwaway script re-leaks it. Attempt it once per system rather than repeatedly, so your own traffic does not pollute the records you are about to read; announce the attempt with its time so nobody chases it as an intrusion; and never probe a system you are not authorised to test.
  • A successful use of the old value shows up in the records an hour after the proven refusal. What does that mean?
    It means the withdrawal is incomplete, not that someone got back in. Some system, replica or registration you did not have on the list is still honouring the value. Find which one answered that use, withdraw there, and re-run the probe against it — then take the new refusal time as the real end of the window.

saying these in an interview costs you the question

  • Treats a successful withdrawal command as proof of refusal
  • Says no holder has complained, so the old value must be dead
  • Assumes one accepting system when several honour the value
  • Ignores replicas and cached authentication decisions
  • Never records when the old value was first proven refused