Home / Knowledge hub / Hash collision
Knowledge hub
Hash collision
Two different inputs that produce the same hash, which breaks trust in it.
What it means
A hash function turns any input into a fixed-length fingerprint. A hash collision is two different inputs that produce the same fingerprint. Because there are endlessly many inputs and a limited number of outputs, collisions must exist. A good function makes them practically impossible to find.
NIST describes collision resistance as the property that it is computationally infeasible to find two different inputs with the same hash. Once someone can find collisions on purpose, a hash can no longer be trusted to tell two files or documents apart.
Why it matters
Collisions have been found on purpose. MD5 collisions were shown practical in the 2000s, and researchers produced rogue certificate authority certificates using them in 2008. In 2017 a team at Google and CWI Amsterdam produced the first known collision for SHA-1.
The risk is trust. If a signature or a check relies on a hash that can be collided, an attacker can prepare two files that look identical to the check, show one and ship the other. NIST has set out a plan to phase out SHA-1.
How it shows up
You meet hashes in file integrity checks, digital signatures, certificates, caching keys, deduplication and commit identifiers. The mistakes repeat: MD5 or SHA-1 kept in a signature check because it always worked, or a hash of user input used as a unique ID without thinking about a deliberate clash.
Use SHA-256 or SHA-3 family functions for integrity and signatures. Do not use fast general hashes for passwords at all; use a slow function like Argon2. A collision is different from a rainbow table attack and from a preimage attack, which tries to recover an input from a hash.
Questions people ask
Hash collision, answered
Is a hash collision the same as a hash being reversed?
No. A collision finds two inputs with the same hash. Reversing finds an input for a given hash, which is a harder problem called a preimage attack.
MD5 and SHA-1 are broken for collisions but not generally for preimages.
Is MD5 still safe to use?
Not where collision resistance matters, such as signatures and certificates. For non-security uses like a quick checksum against accidental corruption it may still serve.
Prefer SHA-256 for anything security related.
Is SHA-256 vulnerable to collisions?
No practical collision is known. It is widely used and recommended by NIST for integrity and signatures.
Review this if standards change. It is the usual safe choice today. Use it for new work.
Can collisions affect Git?
Git has used SHA-1 for object names and has added detection for known collision attacks and support for SHA-256 repositories.
Treat commit hashes as identifiers and sign what you trust.
How do we find weak hash use in our app?
Search the code and dependencies for MD5 and SHA-1 calls, then check whether any decision relies on them for trust.
A white-box review does this quickly. Replace them with SHA-256 where trust is involved.
Sources
Where this comes from
Related
Terms that sit next to this one
Hashing
A one-way transformation, so a password can be checked but never read back.
Digital signature
A value that proves who produced data and that it has not changed since.
Rainbow table
A precomputed list of hashes used to reverse unsalted passwords quickly.
HMAC
A hash mixed with a secret key, proving a message is unchanged and from the key holder.
Argon2
A modern password hashing function that is slow and memory-hungry on purpose.
Do you still trust a weak hash?
In white-box mode we read your code while testing the running app, so a weak-hash finding can point to the file and line, with the evidence beside it. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.