MD5 and SHA-256 are both fast hashes — why is neither right for storing passwords?

Notice the question concedes that SHA-256 is cryptographically strong — so the candidate cannot fall back on "MD5 is broken." The trap is thinking collision resistance is the relevant property. For password storage, speed is the property that matters, and speed is the enemy.

Why fast is the wrong goal

General-purpose hashes are optimised to be fast on huge inputs. That is great for file integrity and terrible for passwords. If an attacker dumps your hash table, they run an offline attack: dictionary words and brute-force candidates fed through the same fast hash. A modern GPU computes billions of SHA-256 hashes per second, so weak and even moderate passwords fall quickly. The hash never needs to be reversed — the distractor about "decrypting" misunderstands that hashes are one-way; attackers guess and compare.

The correct tool: slow, salted KDFs

Use a password hashing / key-derivation function built to be slow and resource-intensive:

• bcrypt — deliberately slow with an adjustable cost factor.
• scrypt and Argon2 — additionally memory-hard, which blunts GPU/ASIC parallelism because attackers cannot cheaply scale memory the way they scale compute. Argon2 is the current recommendation.

Two more essentials:

• A per-user salt so identical passwords produce different hashes, defeating precomputed rainbow tables (note: a salt does not slow a targeted single-user guess).
• A tunable work factor you raise over time as hardware gets faster.

What interviewers look for

The insight that speed — not reversibility or collisions — is the flaw, plus naming bcrypt/scrypt/Argon2, salting, and a work factor. Anyone who says "just use SHA-256, it's secure" has missed the threat model entirely.