Collision attacks are a significant concern in cryptography. If you manage password storage, digital signatures, or file integrity checks, you need to know whether the hash function underneath them can be forced into a collision. When it can, an attacker can forge signatures, swap out “verified” files, or make fraudulent documents appear legitimate.
This guide is for developers, sysadmins, and security-conscious readers who need a working understanding of collision attacks. By the end, you’ll know what a collision attack actually is, which hash functions are still safe to use, and exactly what to change if you’re not using them.
The short answer
A collision attack is when someone deliberately finds two different inputs that produce the same hash output, then uses that matching hash to slip a fraudulent file, message, or password past a system that trusts hashes for verification.
What to do about it, in order of priority:
- Stop using MD5 and SHA-1 for anything security-critical. Both have publicly demonstrated collisions.
- Use SHA-256 or SHA-3 (256-bit or higher) for digital signatures, TLS certificates, and file integrity checks. Neither has a known practical collision.
- Never use general-purpose hashes like SHA-256/SHA-3 alone for passwords. Use a dedicated password hashing function instead, such as bcrypt, scrypt, or Argon2. These are deliberately slow, which blunts brute-force and precomputation attacks in a way general-purpose hashes don’t.
- Audit third-party libraries and legacy code. MD5 and SHA-1 tend to linger in legacy checksum scripts, internal tools, and vendor software long after the “official” system has moved on.
Risk note: a collision vulnerability doesn’t mean your system is broken today — it means an attacker with enough computing power and motivation could break it. Treat known-broken algorithms (MD5, SHA-1) as a “fix now” issue, not a “someday” one, especially anywhere they touch digital signatures or certificate authorities.
Related: Check out our article on preimage attacks, closely related to Collision attacks.
How hashing actually works
A cryptographic hash function takes an input of any size — a single character, a PDF, an entire codebase — and produces a fixed-length output called a hash (or digest).
Cryptographic hash functions have several key properties:
- Deterministic output: the same input always produces the same hash.
- Fixed-length output: SHA-256 always outputs 256 bits, whether you hash one letter or an entire book.
- One-way: you can compute the hash from the input easily, but you can’t reasonably reverse a hash back into its original input.
- Fast computation: Hashing must be efficient enough for real-world use at scale.
- Avalanche effect: changing a single character in the input should scramble the entire output.
- Collision-resistant (ideal case): it should be computationally infeasible to find two different inputs that produce the same hash.
You can see the avalanche effect for yourself. Hashing the words “What is hashing?” using SHA-256 produces: 2da0ed1070f7e7306a23785422576c864bdec63a6032482badc26fc5102f9a9c. Change just the punctuation to “What is hashing!” and the output becomes 02a3603765eb85b8aa96aa8c18df75675a0670b33eb2c306e54d13a2baabffa5 — a completely different string, with no visible relationship to the original.
What are hashes used for?
Hashing underpins three things most systems rely on daily:
- Digital signatures, where a sender hashes a message and encrypts that hash with their private key. The recipient re-hashes the message and checks it against the decrypted signature to confirm the message wasn’t altered.
- Password storage, where services store a hash of your password instead of the password itself, so a database breach doesn’t hand over plaintext credentials.
- Data integrity checks, like verifying a downloaded file hasn’t been corrupted or tampered with.
Every one of these depends on the assumption that no one can find two different inputs sharing the same hash. That assumption is exactly what a collision attack breaks.
What is a collision?
A collision occurs when two different inputs produce the same hash value. This is problematic because many security systems assume that collisions are practically impossible.
However, due to the pigeonhole principle, collisions must exist. In essence, there are more possible inputs than possible hash outputs, meaning overlaps are theoretically inevitable.
For SHA-256, there are:
2²⁵⁶ possible hashes ≈ 1.16 × 10⁷⁷ values
This is enormous, but still finite. Inputs, on the other hand, are effectively unlimited. So while collisions must exist mathematically, security depends on them being infeasible to find in practice.
The birthday paradox and collision likelihood
The chances of a collision tend to be smaller than most people assume, thanks to the birthday paradox.
The birthday paradox shows that in a room of just 23 people, there’s a more than 50% chance two of them share a birthday — even though there are 365 possible birthdays. This is because we are comparing all possible pairs rather than just trying to match one specific date.
Applied to hashing, this means an attacker hunting for any matching pair of hashes doesn’t need to search through half of all 2²⁵⁶ possible SHA-256 outputs. Instead, the expected work drops to roughly √(2²⁵⁶) ≈ 2¹²⁸ attempts. That’s still astronomically large, but it is a fundamental reduction in security compared to the brute-force expectation.
The same math drops MD5’s 128-bit collision resistance to about 2⁶⁴ operations in practice, which is no longer considered computationally out of reach for well-resourced attackers.
Types of collision attacks
| Attack type | What the attacker controls | Real-world threat level |
|---|---|---|
| Classical collision | Finds any two different inputs (x ≠ y) where H(x) = H(y) | High where it's possible -- breaks digital signature trust |
| Chosen-prefix collision | Given two specific starting prefixes, finds appended data so both combined messages hash identically | Higher -- lets attackers forge two meaningful, attacker-chosen documents (e.g., two different certificates) rather than random garbage |
| Freestart collision | Chooses the hash function's internal initialization values, which real attackers can't do | Low in practice -- mainly a research tool for probing weaknesses |
| Preimage/ second preimage | Works backward from a hash to find an input, or finds a second input matching a given one | Different problem, generally harder than a collision but equally damaging if solved |
Why chosen-prefix attacks matter more: a classical collision typically produces two nonsense files that happen to share a hash — not very useful for fraud. A chosen-prefix collision lets an attacker start with two real, meaningful documents (say, a legitimate contract and a fraudulent one) and calculate the exact padding needed to make both hash identically. This is the technique that broke MD5 in practice, letting researchers forge two valid-looking X.509 certificates with the same digital signature.
Where each hash function stands today
MD5: broken, do not use for security. Researchers published full collisions in 2004, found in under an hour on standard hardware. In 2007, researchers forged two X.509 certificates sharing a signature, meaning MD5 could no longer be trusted to guarantee certificate authenticity. MD5 hasn’t gotten safer since. In 2022, French utility company EDF was fined €600,000 under GDPR, partly for storing passwords with MD5.
SHA-1: broken, being phased out. SHA-1 fell in stages: reduced-round collisions through the mid-2000s, a full freestart collision in 2015 (known as “SHAppening”), and the first full classical collision in 2017 (“SHAttered”). NIST deprecated SHA-1 in 2011. A chosen-prefix collision followed in 2020. SHA-1 is no longer acceptable for digital signatures or certificates, though it’s still considered acceptable inside HMAC constructions, because the security assumptions differ and collision resistance is not the primary requirement.
SHA-2 (SHA-256/SHA-512): currently secure. The best published attacks reach roughly 38 of SHA-2’s 64–80 rounds, nowhere near a practical break. SHA-256 offers about 128 bits of real-world security against birthday attacks; SHA-512 offers about 256. This is the current default for TLS certificates, code signing, and file integrity checks.
SHA-3: currently secure, structurally different. SHA-3 uses a different internal design (a sponge construction) than SHA-1/SHA-2, so it isn’t vulnerable to the same class of attacks. Published research has only reached six of its 24 rounds. It’s not necessarily “better” than SHA-2 — think of it as a structurally independent backup, so that if a weakness is ever found in SHA-2’s design, SHA-3 likely isn’t affected the same way.
Securing your systems against collision attacks
- For digital signatures and certificates: require SHA-256 or better. If you’re maintaining legacy systems, audit for any code path still generating or verifying MD5/SHA-1 signatures — these show up more often in overlooked internal tools than in primary infrastructure.
- For password storage: don’t use a general-purpose cryptographic hash at all. Use Argon2id (current best practice), or bcrypt/scrypt if Argon2 isn’t available. These algorithms are intentionally slow and resistant to hardware acceleration, which matters more for passwords than raw collision resistance does.
- For file integrity and checksums: SHA-256 is the practical standard. Avoid MD5 checksums even for “low stakes” use — old habits are how MD5 keeps reappearing in new codebases.
- Review on a schedule, not just when something breaks. Collision resistance degrades gradually as research chips away at reduced-round attacks over years, not all at once. Revisit your cryptographic choices every couple of years, and treat academic progress against your chosen algorithm’s reduced-round variants as an early warning sign, not just an academic curiosity.
Conclusion
Collision attacks matter because so much of digital trust rests on the assumption that hash collisions can’t practically be found. MD5 and SHA-1 have both had that assumption disproven in the real world; SHA-2 and SHA-3 haven’t, at least not yet. If your systems still touch MD5 or SHA-1 anywhere security-relevant, that’s the fix to prioritize. Everywhere else, keep an eye on the research, but there’s no need to lose sleep over SHA-256 or SHA-3 today.
Nice article. Very informative – love the analogies used.. made the subject come to life.