When a database authenticates a client with a password using SCRAM-SHA-256 challenge-response, what does that protocol give you that sending the password over the connection (or sending a simple MD5 hash of it) does not?

## The problem with password authentication A password scheme has to survive three separate threats: 1. **Wire capture / replay** — someone reading the connection must not learn something they can present later. 2. **Server-side theft** — someone who dumps the catalog of stored credentials must not gain the ability to log in, and must face expensive offline cracking. 3. **Impersonation of the server** — a client tricked into connecting to a rogue endpoint must not hand over a usable secret. Naïve schemes fail all three; older challenge-response schemes fix only the first. ## Plaintext The client sends the password; the server compares it to what it stores. Everything hinges on transport encryption. Without TLS, anyone on the path has the credential; with TLS, the database server still sees the real password, which matters when that password is also the user's directory password. ## MD5-style challenge-response A classic improvement: the server stores `hash(password + username)` and sends a random per-connection salt; the client returns `hash(stored_hash + salt)`. Wire capture no longer yields a replayable value for a *different* connection. But two weaknesses remain: - The stored value is **password-equivalent**. It is all the client ever needs to compute a response, so an attacker who reads the catalog can authenticate as that user without ever cracking anything. - The digest is unsalted-per-user in any meaningful sense (the "salt" is the username) and uses a single fast hash pass, so leaked values fall quickly to rainbow tables and GPU cracking. ## What SCRAM changes SCRAM (Salted Challenge Response Authentication Mechanism) does a four-message exchange. Conceptually: 1. Client sends its name and a client nonce. 2. Server replies with the user's **random salt**, an **iteration count**, and a combined nonce. 3. Client derives a key from the password via **PBKDF2(password, salt, iterations)**, then sends a *proof* computed over the full transcript of the exchange. 4. Server verifies the proof and returns its own signature, which the client checks. The consequences: - **No replay.** The proof is bound to nonces contributed by both sides, so it is useless on another connection. - **The stored verifier is not the credential.** The server keeps derived values that let it *verify* a proof but not *produce* one. Stealing the catalog therefore does not hand an attacker a working login — it hands them material for an offline attack. - **That offline attack is expensive.** Per-user random salt kills precomputation and shared work across accounts; the iteration count (tens of thousands of PBKDF2 rounds) multiplies the cost of every guess. - **Mutual authentication.** Because the server must return a valid signature, a rogue server that merely collects the client's proof cannot convince the client, and the collected proof is not replayable elsewhere. - **Channel binding** (the `-PLUS` variant) folds the TLS endpoint into the transcript, so an attacker who terminates TLS in the middle and relays the exchange to the real server fails verification. ## What it does *not* do - It does not encrypt your data. SCRAM protects the credential exchange only; you still want TLS for the session. - It does not make weak passwords safe — iteration counts raise the cost per guess, they don't rescue `postgres123`. - It grants **no privileges**. It only establishes which role you are; every subsequent statement is still authorized against the catalog. - It says nothing about *which* connections are even allowed to use passwords — that is decided beforehand by the host-based rules. ## Operational notes Migrating an installation from an MD5-style scheme to SCRAM is not a config flip: the stored verifier has to be recomputed, which requires each user to set their password again after the new algorithm is made the default. Old client drivers that predate SCRAM cannot authenticate at all and must be upgraded — the failure looks like an outright authentication failure, not a warning. Verify that clients negotiate the intended mechanism rather than trusting configuration. ## What interviewers listen for The distinction most candidates miss is the second threat: they explain that "the password isn't sent in the clear" and stop. The stronger answer separates wire protection from verifier protection, and points out that in older hashed schemes the stored hash is itself sufficient to authenticate.