MD5, SHA-1, SHA-256: which hash should you actually use?

A hash function turns any input into a fixed-length fingerprint, and the same input always produces the same output. The interesting question is not which hash is fastest but which guarantees you actually need — because for passwords, fast is precisely wrong.

What 'broken' means

A hash is broken when someone can produce two different inputs with the same output — a collision. MD5 collisions can be generated in seconds on ordinary hardware, and SHA-1 collisions have been demonstrated in practice. Both remain perfectly good at detecting accidental corruption, and useless against anyone deliberately trying to forge a match.

That distinction matters. Using MD5 to check that a download completed intact is fine. Using it to verify that a file has not been tampered with by an attacker is not, because the attacker can construct a file that matches.

Passwords need a slow hash, not a strong one

SHA-256 is cryptographically strong and still the wrong choice for storing passwords, because it is fast. Modern hardware computes billions of SHA-256 hashes per second, so a stolen database of fast hashes falls to a dictionary attack quickly.

Password hashing functions — bcrypt, scrypt, Argon2 — are deliberately slow and memory-hungry, with a tunable cost factor. They also salt each password, so identical passwords produce different hashes and one precomputed table cannot attack the whole database at once.

Verifying a download

Publishers list a checksum, usually SHA-256, alongside a release. Hash the file you received and compare the two strings character by character; if they differ at all, do not run it.

This catches a truncated or corrupted download reliably. It only catches a malicious substitution if you trust the channel the checksum came from — a checksum published on the same compromised page as the file proves nothing.