A junior engineer proposes storing `SHA-256(password)` for a new signup flow, reasoning that SHA-256 is a secure, one-way hash. What's wrong with that reasoning, and what does the fix actually add?

SHA-256 being one-way is true and beside the point: the same password produces the exact same hash every time, on every machine, which means two problems that have nothing to do with reversibility. First, anyone with the stolen table can see which users share a password without cracking anything. Second, an attacker doesn't need to reverse the hash — they hash a list of common passwords once and look the result up, and that precomputed work is reused against every database in the world that made the same mistake. And SHA-256 is fast, which is exactly wrong for this use: a modern GPU computes billions of them per second, so guessing at scale is cheap. The fix — bcrypt, scrypt or Argon2id — adds a random salt per password (so identical passwords produce different hashes, and no table can be precomputed against a salt that doesn't exist yet) and a deliberately slow, adjustable work factor (so each individual guess costs real time, tunable as hardware gets faster).