Interview replay
Full round replay — password storage
Timed verbal replay with pass/fail criteria per follow-up.
How to run this
The opener
“How should a password be stored?”
Budget: 45 seconds. Going long here is itself a fail signal.
Follow-ups
1. “Why is SHA-256 the wrong choice? It is a strong hash.”
Testing: Do they know which property is under attack?
Scoring
Pass: It is strong against collisions and wrong here because it is fast. An attacker with the leaked table guesses offline at whatever rate the hash allows — billions a second on a GPU. Speed is the attacker's budget.
Fail: Says SHA-256 is broken, or cannot say what makes bcrypt different.
2. “Is the salt secret?”
Testing: A very common misconception.
Scoring
Pass: No — it is stored beside the hash. Its job is to make every stored hash unique so precomputed tables are useless and one cracked hash does not reveal every account sharing that password.
Fail: Says it must be protected, or confuses it with a pepper.
3. “What does a salt NOT fix?”
Testing: Whether the two controls are separate in their head.
Scoring
Pass: Guessing speed. A salted fast hash is still brute-forced per account at millions of attempts a second. Salting fixes precomputation; the work factor fixes speed.
Fail: Treats salting as sufficient.
4. “What is a pepper and where does it live?”
Testing: Beyond the textbook answer.
Scoring
Pass: An application-wide secret held outside the database — a secrets manager or HSM — mixed in before hashing, so a database leak alone is not enough to start cracking. It complicates rotation, so it is a deliberate choice.
Fail: Describes it as a second salt in the same table.
5. “How do you verify a login?”
Testing: That there is no decryption anywhere.
Scoring
Pass: Re-hash the supplied password with the stored salt and compare in constant time. Nothing is decrypted, which is exactly why a password can never be emailed back.
Fail: Talks about decrypting the stored value.
6. “Why constant-time comparison?”
Testing: Timing as a side channel.
Scoring
Pass: equals returns at the first difference, so the response time reveals how many bytes matched. MessageDigest.isEqual compares the full length. The same applies to tokens, API keys and HMAC signatures.
Fail: Has not considered timing.
7. “How would you migrate a table of unsalted MD5?”
Testing: Do they know you cannot recompute?
Scoring
Pass: You cannot without the passwords. Wrap them — store bcrypt over the existing hash so the whole table is protected in one migration — then upgrade properly at each login, with a forced reset and a deadline for dormant accounts.
Fail: Proposes a batch job that rehashes, which is impossible.
8. “Your compliance regime requires FIPS, and bcrypt is not approved.”
Testing: Whether they know the approved option.
Scoring
Pass: PBKDF2-HMAC-SHA256 is FIPS-approved, is a password-based KDF with a tunable iteration count, and is in the JDK. Around 600,000 iterations. The constraint does not force a bare hash.
Fail: Concludes SHA-256 is the only option.
9. “Login takes 300ms because of hashing. Problem?”
Testing: Can they defend the cost?
Scoring
Pass: No — that is the design. Logins are rare per user and 300ms is unnoticeable, while being ruinous to someone guessing. If login volume is genuinely the bottleneck, issue a session or token rather than weakening the hash.
Fail: Offers to lower the cost factor.