What they're testing
Whether you know why a fast hash is wrong here — the most foundational piece of security knowledge there is.
The short answer~30 seconds
Use Argon2id, bcrypt or scrypt, with a per-password salt (these libraries generate one and embed it in the output string). Not MD5, SHA-1 or SHA-256 — they're designed to be FAST, and fast means a GPU can try billions of candidates a second. A password hash is deliberately expensive in time and memory to make mass cracking economically impractical.
The long answer
The salt defeats rainbow tables: without one, every user with the same password shares a hash, so cracking once cracks all of them. It must be RANDOM and per-record — one system-wide salt returns you to the same problem. Usefully, bcrypt and Argon2 handle this themselves, so hand-rolling salt handling is usually a sign you're implementing something you shouldn't be.
Cost parameters need periodic review because hardware keeps getting faster. OWASP publishes specific per-algorithm recommendations and updates them; the practical rule is picking a setting where one hash takes roughly 250–500ms on your production hardware. And when you raise it, you apply the new cost to new passwords and rehash gradually as users log in — nobody has to change theirs.
Two small details often skipped: hash comparison must be constant-time (libraries handle it), and the login error must be identical for "no such email" and "wrong password" — otherwise you've handed an attacker an account-enumeration oracle. Response time must match too, so the unknown-email path should still perform a dummy hash.
What they'll ask next
?What is a pepper, and do you need one?
A system-wide secret mixed in alongside the salt and stored SEPARATELY from the database (an env var, an HSM). It helps when the database leaks and the key doesn't: the hashes become useless to the attacker. Rotating a pepper is awkward, so it's an advanced step rather than a requirement.
?What password complexity rules do you require?
Current guidance (NIST SP 800-63B) favours a minimum LENGTH plus checking against breached-password lists, rather than mandated special characters and periodic rotation — those two rules produce Password1! followed by Password2!. Don't impose a low maximum length, and don't block pasting from a password manager.
These lose points
- "Salted SHA-256 is fine." The salt stops rainbow tables but doesn't slow cracking — a GPU still tries billions a second.
- Implementing the hashing scheme yourself. This is a domain where hand-rolling is nearly always worse than the library.