By Freddy ·
SHA-256 is a fine hash function; it's just the wrong hash function for passwords. General-purpose cryptographic hashes like SHA-256 and SHA-512 are designed to be fast, because they're used for things like checksums and digital signatures where speed is a feature. Speed is the opposite of what you want when hashing passwords.
If an attacker gets a database of password hashes, they don't need to break the hash function itself; they just guess candidate passwords, hash each one, and compare. Modern GPUs can compute billions of SHA-256 hashes per second, which means a fast hash turns password cracking into a raw throughput problem an attacker can brute-force through in a reasonable amount of time, especially against weak or reused passwords. Salting prevents precomputed rainbow-table attacks, but it does nothing to slow down this kind of brute force.
bcrypt, scrypt, and Argon2 exist specifically to make each guess expensive. They use a configurable “work factor” that controls how many iterations, how much memory, or both, are required per hash, tunable so the cost stays roughly constant (a few hundred milliseconds per attempt) even as hardware gets faster. That's the entire design goal: make one login check tolerably fast for a real user, while making a billion guesses prohibitively slow for an attacker.
For new systems, OWASP's current guidance is Argon2id first, bcrypt as a well-supported fallback where Argon2 isn't available. SHA-256/SHA-512 should never be used alone for password storage, only ever as a general-purpose hash for data integrity, not secrets. This site's own Encrypt / Decrypt tool supports SHA-256 and SHA-1 for exactly that non-password use case, with a warning banner on the legacy algorithms.