Why can a stolen NT hash authenticate an attacker without ever being cracked?

## The property that makes this work Authentication protocols differ in **what the verifier accepts as proof of possession**. That single design choice decides whether a stolen stored value is a login or merely a puzzle. In NTLM authentication, the password itself is never transmitted and never compared. The account's password is turned into a fixed 16-byte value — the **NT hash**, `MD4(UTF-16LE(password))`, unsalted — and that value is what both ends work from. The client derives its response from the NT hash; the verifier recomputes the expected response from the NT hash it stores for that account. Neither side needs, sees, or checks the plaintext. Call this **verifier equality**: the thing stored at the verifier and the thing the client must supply are the same object. Once that is true, whoever obtains the object can authenticate. There is nothing left to break. ## Why cracking is the wrong instinct The reflex answer — "they still have to crack it, and our passwords are strong" — imagines a different protocol, one where a human types a secret that gets re-derived and compared. That is how an application password store works, and there cracking is mandatory because the stored value cannot be submitted. Here it is not mandatory, and it is usually not even worth doing: - **Time is the operator's scarcest resource.** A criminal contractor paid per completed intrusion loses money on every hour spent on a GPU. Reuse is instant; cracking is speculative. - **Success is not guaranteed.** A genuinely random 24-character service account password will not fall. But the hash of that password works exactly as well as the hash of `Summer2026!`. Password strength is simply not in the path. - **The plaintext adds only side value.** It is worth having when some *other* verifier demands typed text — a web SSO form, an SSH password prompt, a password manager, a helpdesk identity check — or when the human reused the same string on systems that have nothing to do with the domain. That is a bonus, not the objective. So the correct mental model is: the hash is not "an encrypted password you must undo". It is **the credential, in the form the protocol actually consumes**. ## The same property, one layer up: issued tickets Kerberos moves the accepted proof around but does not remove the property. The account's long-term key is derived from its password, and on a Linux fleet that key is commonly written to a **keytab** so services can authenticate unattended. Reading a keytab therefore yields the same kind of object: material the protocol accepts directly, with no plaintext anywhere in the story. A cached **ticket** is the same idea with a shorter life. A ticket is already-minted proof; presenting it is accepted because the issuer vouched for it, not because the presenter demonstrated knowledge of anything (`T1550.003`). So an operator on one compromised host can end up authenticated as a service identity across dozens of hosts having never learned, guessed, or cracked a single password — and that access ends on the ticket's own clock rather than when anybody decides it should. ## What the answer is *not* Be precise about direction, because the common wrong statements are all reversals: - It is **not** that the hashing is weak. Substituting a modern, salted, slow function for MD4 in that position would change the cracking economics and change nothing about reuse — the new value would still be what the protocol accepts. - It is **not** that the attacker "logged in with a hash instead of a password" through some flaw. The verifier behaved exactly as specified. There is no bug being exploited; the design accepts a static long-lived derivative. - It is **not** universal. "A hash leaked, therefore a login" is wrong just as often as the reflex it corrects. Whether a stolen digest is reusable depends entirely on whether the verifier accepts it as input, and plenty do not. ## The consequence worth stating in an interview Because the accepted proof is static, every control aimed at the *plaintext* misses. Length, complexity, character classes, lockout after failed guesses, and a stronger storage function all address guessing — and no guessing is occurring. What bounds this class of reuse is the lifetime of the accepted material, how widely one copy of it reaches, and ultimately whether the verifier can be moved to a proof it cannot store and an attacker cannot replay.