Which control class actually stops NT hash and Kerberos ticket reuse?

## Start from what the technique cannot do without The useful habit for any attack question is to name the one input the technique cannot substitute, then ask which control class removes it. For credential reuse the input is a **static secret-equivalent accepted by the verifier**. Three properties have to hold together: 1. The value is the same on every use (static). 2. It stays valid over a long period (long-lived). 3. Presenting it is sufficient — nothing binds the presentation to this session, this client or this relying party (replayable). Break any one of those and reuse degrades. Break the first properly and it disappears. ## The control class that removes it **Asymmetric, challenge-bound proof.** The verifier stores a public key; the client holds a private key and produces a **fresh signature over a fresh challenge** on every authentication. Two consequences follow immediately: - What the verifier stores is not a credential. Stealing the whole store yields public keys, so the entire class of "the store is the login" vanishes. - What the client holds can be made non-exportable — generated in and never leaving a hardware key store — so there is no derivative to lift in the first place. For human authentication this is FIDO2/WebAuthn, which additionally binds the assertion to the relying party's origin, so the proof is not merely unreplayable but also not usable against a different service. For machine and service identity the same shape appears as **short-lived certificates** issued to a host or workload, where the private key is host-bound and the credential expires in hours rather than persisting as a keytab. Note what this is not: it is not "stronger hashing" and not "a better password policy". It is a change to *what counts as proof*. ## The two partial controls, and what each buys Most estates cannot make that change everywhere at once, so it is worth being precise about the fallbacks. **Lifetime.** Shorten ticket lifetimes so issued proof expires sooner; rotate long-term keys often enough that a stolen keytab has a short useful life; let managed identities rotate their own passwords on a machine schedule rather than a human one. This does not stop reuse; it caps the duration of each instance of it. It also has a cost: shorter lifetimes mean more issuance traffic and more operational fragility around clock skew and unattended jobs. **Scope.** This is the underrated one. Reuse hurts in proportion to how many verifiers accept the same object. A single service identity whose keytab sits on sixty hosts means one compromised host yields sixty. Per-host identities, service-specific accounts, and restrictions on which systems an account may authenticate to convert a fleet-wide compromise into a single-host one. Nothing about the technique changes; its yield collapses. ## Controls that feel relevant and are not Being able to say why these miss is usually the discriminating part of the answer: - **Password length and complexity.** They price guessing. Nobody is guessing. A 40-character random password produces a derivative that is accepted exactly as readily as a weak one's. - **Account lockout.** It counts failed attempts. Reuse produces successful authentications on the first try. - **A stronger storage function.** It raises the cost of recovering plaintext, which is the step reuse skips. - **Multi-factor at the interactive front door.** It sits in front of the path that collects typed text. The derivative path does not traverse it, so the identity remains reachable behind the factor. MFA raises the cost of obtaining a first credential; it does not change what the protocol accepts afterwards. - **Rotating after an incident.** Necessary, but it closes acquisition rather than possession, and anything already issued lives out its own clock. ## Choosing, when you cannot do everything If you are the architect for a domain-joined Linux fleet reached through a shared jump host, the ranking is usually: 1. **Scope first**, because it is cheap and it changes the yield of every future compromise, not just this technique. Per-host identity beats one shared identity everywhere. 2. **Lifetime second**, because it is a configuration change with a known operational tail. 3. **Change the accepted proof** as the programme, not the sprint — it touches every service that authenticates, and it is the only one of the three that removes the technique rather than taxing it. The answer an interviewer is listening for is that ordering plus the reason behind it: the first two make reuse less profitable, and only the third makes it impossible.