Why is a leaked bcrypt password hash not reusable the way an NT hash is?
answer
- same word, two different objects
- ask what the verifier accepts as input
- one is an output, one is the credential
- cracking mandatory versus cracking pointless
- the protocol decides, not the algorithm
basics
~20 sOne word names two different objects. An application's bcrypt value is a checker: login submits a plaintext that is re-derived and compared, so the stored string cannot be submitted. A domain's NT hash is the credential the protocol accepts directly.
solid answer
~50 sAsk what the verifier does with the stored value. An application login takes a **plaintext** from the client, recomputes bcrypt over it with the stored salt, and compares. The stored string is an output used for comparison — it is never valid input, so a leaked store is an offline guessing problem, not a login. Domain authentication takes no plaintext at all: the client's proof is computed from the NT hash, and the verifier checks it against the NT hash it holds. There the stored value *is* the credential. Same English word, opposite properties. The practical consequence is that "our passwords are hashed" means something protective in the application and something quite different in the directory, and a leaked application store is serious for password reuse and offline attempts rather than because it hands anyone a session.
code
text · 11 linesAPPLICATION STORE (stored value = a checker)
alice | $2b$12$<22-char salt><31-char derived output>
login: client sends the PLAINTEXT
server re-derives bcrypt(plaintext, salt) and compares
=> the stored string is never accepted as input; it must be cracked
DOMAIN STORE (stored value = the credential)
ALICE | NT hash = MD4(UTF-16LE(password)), unsalted, 16 bytes
login: no plaintext is sent at all
client's proof is computed FROM the NT hash; verifier checks against the same value
=> the stored value IS the credential; cracking buys nothing extrago deeper
Know that an application login sends the password itself and the server re-computes and compares, so the stored string cannot simply be pasted in to log in.
Be able to state the separating question — what does the verifier accept as input — and apply it to both a user table and a directory account without reaching for the algorithm.
Show that storage strength and protocol acceptance are independent axes, and give the correct three-part answer to an application team asking whether their store is a bypass.
Own the vocabulary problem itself: one word covering two objects with opposite properties drives real misallocation, so define which of the two any given control is actually addressing.
## Two objects, one word "Hash" is used for both of these, and conflating them produces two symmetrical mistakes: panic ("a hash leaked, so anyone can log in") and complacency ("it's hashed, so they'd have to crack it"). Each is right about one of the two objects and wrong about the other. The question that separates them is always the same: **what does the verifier accept as input?** ### The application store: a checker A typical web application stores, per user, a bcrypt string that encodes the algorithm, the cost, the salt and the derived output. At login the client sends a **plaintext password**. The server pulls the stored string, re-derives from the submitted plaintext using the salt inside it, and compares the results. The stored value never travels toward the server as a credential, and there is no code path that accepts it as one. Substituting it into the password field simply gets hashed again and fails. So an attacker holding the store holds an *oracle*: they can test candidate plaintexts offline, and nothing more. That is a real and serious problem — people reuse passwords, and offline attempts are unlimited and unobserved — but it is not an authentication bypass, and it does not yield a session against that application. ### The domain store: a credential Domain authentication does not collect a plaintext at all in the reuse case. The client's proof is derived from the NT hash; the verifier's expected value is derived from the NT hash it stores. Both ends need only the derivative. Because the stored value and the client-side input are the same object, obtaining it is obtaining the credential. Nothing needs to be reversed. The same holds one step up: a Kerberos **keytab** on a domain-joined Linux host contains long-term keys derived from an account's password, and the protocol consumes those keys directly. A keytab is on the credential side of the line, not the checker side. ## Why the distinction is not about the algorithm A tempting shortcut is "bcrypt is slow and salted, MD4 is fast and unsalted — that is the difference." It is not, and getting this wrong is the most common way a strong candidate stumbles. Imagine replacing the directory's derivation with a slow, salted, per-user function while leaving the protocol alone. Reuse would still work perfectly, because the protocol would still accept whatever the new stored value is. All that changes is the cost of the *side* activity of recovering plaintext. Now imagine the reverse: an application that stores a fast unsalted digest. It is badly built and its store cracks quickly, but the leaked digest still cannot be submitted at the login form, because the verifier re-derives from what the client sent. The algorithm sets the price of cracking. **The protocol sets whether cracking is even necessary.** Those are independent axes, and this leaf is entirely about the second one. ## Saying it to an application team The conversation this comes up in is usually a team that has just read about credential reuse and wants to know whether their user table is an authentication bypass. The honest answer has three parts: 1. **No, not directly.** Your verifier demands a plaintext and re-derives. Your stored strings are outputs, not accepted inputs. 2. **Yes, it is still bad.** A leaked store is an unlimited offline guessing surface, and a recovered plaintext works everywhere the person reused it — including, sometimes, against your own privileged paths. 3. **The other store is a different animal.** Where the protocol accepts the derivative, exposure is immediate compromise of that identity with no cracking step, and the only things bounding it are how long the material stays valid and how many systems accept it. ## Edge cases worth knowing - **A client-side "hash the password in the browser" scheme** converts a checker into a credential. If the server compares what the client sent against what it stored, the stored value has become the accepted input, and a leaked store is now a login. This is why that pattern is discouraged. - **A cached derivative used for offline logon** is not the same object as either. Whether it is reusable depends on whether some verifier will accept it, which again is a protocol question, not a storage question. - **A password vault's wrapped material** is not a verifier at all; it is encrypted data, and what matters is who holds the key. The portable takeaway for an interview: never answer "is this hash dangerous?" from the algorithm. Answer it from the verifier.
- If the application's stored value cannot be replayed, why is a leaked bcrypt store still serious?Because it is an unlimited, unobserved offline guessing surface, and people reuse passwords. Every plaintext recovered from it works wherever that person used the same string — often including systems with far more privilege than the application that leaked. It is a slow oracle, not a bypass, and both halves of that matter.
- Which side of the line does a Kerberos keytab fall on?The credential side. A keytab holds long-term keys derived from the account's password, and the protocol consumes those keys directly, so reading one is equivalent to holding that identity's credential for as long as the password stands. It is not something you crack; it is something you use.
- A team proposes hashing the password in the browser so plaintext never reaches the server. What happens to this distinction?It collapses in the wrong direction. If the server compares what the client sent against what it stored, the stored value has become the accepted input, and a leaked store turns into a working login. The scheme moves the application from the checker side of the line to the credential side.
One store keeps a photocopy of your signature to compare against the one you write in front of them. The other store keeps the pen that only you were supposed to own, and hands it to whoever asks for it.
saying these in an interview costs you the question
- Says any leaked password hash is an authentication bypass
- Explains the difference by algorithm speed or salting alone
- Claims the domain store would be safe if it used bcrypt
- Treats a leaked application store as harmless because it is hashed
- Confuses an offline guessing surface with a working session