Exercise 3: Why "SHA-256 Is Unbroken" Doesn't Make It Safe for Passwords — Possible Solution
====================================================================

The developer's reasoning conflates two SEPARATE properties that the
chapter treats as distinct: whether a hash function is
CRYPTOGRAPHICALLY SECURE (resistant to preimage/second-preimage/
collision attacks) and whether it's the right SPEED for a specific
use case. SHA-256 being unbroken only speaks to the first property --
it says nothing at all about the second.

Why speed matters specifically for password storage:

SHA-256 was deliberately designed to be FAST, because most of its
intended uses (file integrity checks, signing large documents,
blockchain mining) benefit directly from speed -- you want to be able
to hash gigabytes of data quickly. That design goal is exactly backward
for password storage.

If an attacker steals a database of SHA-256-hashed passwords, they
don't need to break SHA-256's cryptographic security at all -- they
just need to guess passwords and hash each guess to see if it matches
a stolen hash. Because SHA-256 is fast, modern GPU hardware can compute
billions of SHA-256 hashes per second, which means an attacker can try
billions of candidate passwords (common passwords, dictionary words,
slightly modified common passwords) per second per GPU, entirely
offline, without needing to interact with the real system at all. Most
real user passwords fall within a searchable space at that speed --
not because SHA-256 was cryptographically defeated, but because
BRUTE-FORCE GUESSING against a fast hash is cheap.

The correct fix isn't a "more secure" hash in the collision-resistance
sense -- it's a DELIBERATELY SLOW function (bcrypt, scrypt, Argon2id)
that makes each individual guess expensive to compute, directly
targeting the actual threat (mass guessing) rather than a threat
(finding a hash collision) that isn't the real risk to passwords at
all.

WHY THIS WORKS AS AN ANSWER
------------------------------
This directly expands the chapter's own warn-box, which states that
"SHA-256 being completely uncollided and cryptographically sound says
nothing about whether it's the right tool" for passwords specifically
because of its designed-in speed. The developer's error is treating
"unbroken" and "safe for this use case" as the same claim, when the
chapter treats them as two entirely separate questions -- one about
cryptographic strength, the other about appropriate computational
cost for the threat model actually being defended against.