A leaked collector credential is in use right now from an unknown source: do you withdraw it before a replacement exists?
answer
- two orders, two costs
- one cost is bounded, one is not
- outage you choose against access you do not
- narrow reach can justify cutting over first
- name the cost you accepted
basics
~20 sThere are only two orders and each buys one thing at the other's expense. Withdrawing first ends the attacker's access now and costs every holder an outage; cutting over first avoids the outage and leaves a working credential in unknown hands throughout.
solid answer
~40 sWithdraw first and the attacker stops immediately, but every legitimate holder fails until the replacement reaches it — an outage whose length you control. Cut over first and nobody is interrupted, but the leaked value keeps working for the whole cutover, which on a large fleet is hours. The asymmetry decides it: an outage is bounded, visible and ends when you say so, while access you left live is none of those. So the everyday default of replace-then-withdraw inverts when the credential's reach is wide, when you cannot bound what has already been done with it, or when the cutover is long. It holds when the credential is narrow and read-only and the outage would stop work you cannot safely stop. Name the order and the cost you accepted, at the time.
code
pseudocode · 17 lines// choosing the order for ONE leaked credential, under a live exposure
cutoverHours = holderCount / holdersUpdatedPerHour // 800 / 50 = 16
reachIsNarrow = rights(oldValue) == READ_ONLY and scope(oldValue) == ONE_SERVICE
activityIsKnown = canEnumerate(uses(oldValue))
if reachIsNarrow and activityIsKnown and outageStopsCriticalWork:
mint(newValue)
moveHolders(to = newValue) // no interruption
withdraw(oldValue, at = acceptingSystems)
accepted = "a working credential in unknown hands for " + cutoverHours + "h"
else:
withdraw(oldValue, at = acceptingSystems) // attacker stops now
mint(newValue)
moveHolders(to = newValue) // fleet degraded meanwhile
accepted = "degraded collection for up to " + cutoverHours + "h"
record(orderChosen, accepted, cutoverHours) // the decision, not just the outcomego deeper
Recall that stopping the old credential and starting the new one are separate steps, and that doing them in different orders decides who has a bad hour.
Explain each cost concretely: withdrawing first breaks every holder until the replacement lands, while cutting over first leaves a working credential in the attacker's hands for the whole cutover.
Demonstrate that you priced it — how long the cutover takes, what the credential can reach, and which of the two costs you chose to accept, said out loud at the time rather than reconstructed later.
Own the standing rule: which classes of credential are withdrawn on sight regardless of outage, who may make that call at two in the morning, and what the estate has to survive for that rule to be honest.
## Two orders, and only two Under a live exposure the actions are fixed and only their order is yours: withdraw the old value, mint a replacement, move the holders across. There is no third ordering that gives you both properties, because a holder cannot present a value that does not exist yet. Either the attacker keeps a working credential while you cut over, or the fleet is broken while you mint. ## What each order costs | order | the attacker's access | legitimate holders | the cost you accept | |---|---|---|---| | withdraw, then replace | ends at the withdrawal | every holder fails until the new value lands | an outage whose length you control | | replace, move, then withdraw | continues throughout the cutover | uninterrupted | access you cannot see being used | The asymmetry is the whole argument. An outage is **bounded** — you know who it hits, you can watch it, and it ends when the last holder lands. Remaining access to an attacker is none of those things: you do not know what it is being used for, you cannot watch it from the same console, and it ends only when you finally withdraw. Given two costs, prefer the one you can measure. ## What inverts the everyday default Outside an incident, replace-then-withdraw is correct: it is the whole reason overlap exists. Three things push the other way once an exposure is live: - **Reach.** If the credential can write, move money, read customer data, or obtain further credentials, an hour of it is not comparable to an hour of degraded ingest. - **Unbounded uncertainty.** If nobody can yet say what has been done with the value, you cannot price the slow order at all — and an unpriced cost is not a cost you may accept. - **A long cutover.** Population size argues for withdrawing sooner, not later: the bigger the fleet, the longer the graceful order hands the attacker. And three push back toward cutting over first: - the credential is narrow and read-only, so the attacker's remaining hour buys little; - the holders do work that must not stop, or that is expensive and slow to restart; - you can narrow what the old value may do without withdrawing it outright. ## The middle ground, where it exists Some accepting systems let you reduce the old value's usefulness short of refusing it: accept it only from the addresses your own holders use, strip its write rights and leave read, or refuse it for the highest-reach subset while the rest cut over. Each of those is a real reduction and none of them is a refusal — the sequence still ends in a proven refusal of the whole value. The granularity frequently is not there, and designs differ; the honest answer says whether it exists here rather than assuming it does. ## Numbers, not adjectives The conversation gets decidable the moment you compute the cutover. Population divided by the rate you can actually update gives the window. Eight hundred collectors at fifty an hour is sixteen hours — so the graceful order is a proposal to leave a leaked credential working until tomorrow afternoon. Stated that way, most teams change their minds, or discover they can raise the rate for the subset that matters. State the two numbers you assumed; a window nobody computed is not a plan. ## Say the cost out loud Whichever order you take, name the accepted cost at the time and put it in the record: "we withdrew first and accepted up to sixteen hours of degraded collection", or "we cut over first and accepted that a working credential stayed in unknown hands for that window". This matters because both orders look identical afterwards when they work. The stated cost is the only evidence that a decision was made rather than fallen into, and it is what lets someone review the call without re-litigating the night. One trap to name explicitly: a cached copy does not soften the withdraw-first outage. A cached credential that has been withdrawn is refused exactly like a freshly presented one, because the refusal happens at the system being called, not at the holder.
- Is there a middle order between withdrawing first and cutting over first?Only if the accepting system offers granularity: refuse the old value from sources other than your own holders, strip its write rights while leaving read, or withdraw it for the highest-reach subset while the rest cut over. Each narrows the damage without ending it, so the sequence still finishes with a proven refusal of the whole value. Designs differ on what granularity exists — check rather than assume.
- Why is the outage from withdrawing first treated as the cheaper cost?Because you control when it ends, you know exactly who it hits, and you can watch it. The other cost is access being used by someone you cannot see, for purposes you cannot enumerate, ending only when you eventually withdraw. Between a bounded cost and an unbounded one, the bounded one is the one you can actually accept on behalf of the business.
saying these in an interview costs you the question
- States one order as correct without naming the condition
- Claims cutting over first has no cost during an active exposure
- Treats the outage from withdrawing first as unacceptable by default
- Cannot say how long the cutover would actually take
- Thinks a cached copy keeps holders working after a withdrawal