What a matching hash actually proves
Publishing a checksum next to a download is standard practice. What it demonstrates is narrower than most people assume, and the gap is where the risk lives.
Integrity, not authenticity
A hash is a fixed-length fingerprint of an input. Run the same input through the same algorithm anywhere in the world and you get the same output; change a single bit and roughly half the output bits change. Comparing your computed hash against a published one therefore proves one specific thing: the file you have is bit-for-bit the file the hash was computed from.
It proves nothing about who computed it. If an attacker can replace the download, they can usually replace the checksum published beside it, and both will match perfectly. Integrity and authenticity are different properties, and a bare hash only ever delivers the first.
What makes a hash useful
Three properties matter. It must be deterministic, so the same input always produces the same output. It must be one-way, so the input cannot be recovered from the output. And it must be collision-resistant, so no two different inputs can practically be made to produce the same fingerprint.
Collision resistance is the one that fails first, and it fails long before anyone can reverse the function. Once an attacker can construct two files with the same hash, they can have a benign version signed or approved and substitute the malicious one afterwards — with every checksum still matching.
Why MD5 and SHA-1 are retired
Both are broken for security purposes, and not theoretically. Practical collisions have been demonstrated for MD5 for many years and for SHA-1 more recently, including pairs of files with identical hashes and different contents. Neither should be used where an adversary might benefit from a collision.
They survive as fast checksums against accidental corruption — a truncated download, a bad disk sector, a mangled transfer. That is a legitimate use, because random corruption has no incentive to construct a collision. Using them to verify a download against tampering is not.
How to verify a download properly
The checksum needs to reach you by a different route from the file. A hash published on the same page as the download, served from the same server, adds very little — anyone who can alter one can alter the other. A hash published on a separate domain, in a signed release note, or in a repository with its own history is meaningfully better.
Stronger still is a cryptographic signature rather than a bare hash. A signature is a hash encrypted with the publisher's private key, so verifying it with their public key proves both that the file is unchanged and who produced it. That is the property a checksum alone cannot give you.
Passwords are a different problem
General-purpose hashes are designed to be fast, and speed is exactly wrong for password storage. An attacker with a stolen database can compute billions of candidate hashes per second on commodity hardware, so a fast hash offers little protection even when the passwords were never stored in plain text.
Password storage needs a deliberately slow, memory-hard algorithm designed for the job, combined with a unique random salt per password so identical passwords do not produce identical hashes. Using SHA-256 to store passwords is a common and serious mistake, and it looks responsible while offering far less than it appears to.
Where hashes turn up quietly
Version control systems identify commits by hashing their contents, which is what makes history tamper-evident. Deduplication systems recognise identical files by fingerprint rather than comparing bytes. Content delivery networks use hashes as cache keys. Blockchains chain blocks together by including the previous block's hash.
In every case the same property is being exploited: a short value that changes completely if anything about the input changes, and that can be compared far more cheaply than the data it represents.