Hash Collision Attacks: MD5, SHA-1 and What to Use Instead

A hash collision lets an attacker make two different files share one digest, so anything that trusts the digest, a signature, a certificate or a commit ID, can be made to vouch for the wrong content. MD5 collisions have been practical since the mid 2000s and were used to forge a trusted certificate authority in 2008 and a Microsoft code-signing certificate in the Flame malware in 2012. SHA-1 followed: the SHAttered collision in 2017 and a practical chosen-prefix collision published in 2020. NIST has set 31 December 2030 as the date by which it will stop using SHA-1 for cryptographic protection in all applications. This guide explains the difference between identical-prefix and chosen-prefix collisions, what each real attack actually did, which uses of MD5 and SHA-1 are dangerous and which are merely untidy, and how to find and replace them, including Git's move to SHA-256. It is for application security engineers, PKI owners and platform teams. For the basics of hash functions, start with the Hashing Guide.

Key takeaways

Collision resistance is the property that broke: preimage resistance of MD5 and SHA-1 is not practically broken, which is why the risk depends on whether an attacker can influence what gets hashed.
Chosen-prefix collisions are the dangerous kind: they let an attacker start from two different meaningful prefixes, such as two certificates with different names, and still make the digests match.
Real attacks targeted signatures: the 2008 rogue CA and Flame both abused a certificate authority that still signed with MD5, and the 2020 SHA-1 chosen-prefix attack forged PGP key certifications.
NIST's deadline is 31 December 2030: SHA-1 was deprecated for new digital signatures in 2011, and NIST will withdraw it for all cryptographic protection by the end of 2030; use SHA-256, SHA-384 or SHA-3.
Inventory first, then replace by risk: signatures, certificates and anything accepting externally supplied data go first; HMAC-SHA-1 and non-security checksums can follow on a normal refresh cycle.

Collisions, preimages and why the distinction matters

Property	What an attacker must do	Status for MD5	Status for SHA-1
Collision resistance	Find any two inputs with the same digest; attacker controls both	Broken: RFC 6151 cites collisions found in about a minute on a 2006-era notebook	Broken: first collision 2017 (SHAttered)
Chosen-prefix collision	Given two chosen prefixes P and P', find suffixes S and S' so that hash(P\|\|S) = hash(P'\|\|S')	Practical by 2008, used in the rogue CA and Flame	Practical since the 2020 "SHA-1 is a Shambles" result
Second preimage resistance	Given someone else's input, find a different one with the same digest	Not practically broken	Not practically broken
Preimage resistance	Given only a digest, find any input that produces it	Not practically broken	Not practically broken; the Shambles authors note SHA-1 preimage resistance remains unbroken

The practical consequence: a collision attack needs the attacker to create or influence both documents before one of them is hashed and trusted. If you hash a file you created and the attacker later tries to substitute a file with the same MD5, they need a second preimage, which remains out of reach. If the attacker submits a document for you to sign, or creates a certificate request that a CA signs, or commits content to a repository, a collision is enough. That is why signature schemes and certificate issuance are where collisions hurt.

An n-bit hash offers at most about n/2 bits of generic collision resistance because of the birthday bound. MD5 (128-bit) and SHA-1 (160-bit) were already modest on that measure; cryptanalysis cut them much further.

Identical-prefix and chosen-prefix attacks

Identical-prefix collision: both messages share the same prefix, then differ in a pair of carefully computed blocks, then continue identically. File formats that let content branch on a hidden byte (PDF, executables, some image formats) turn this into two files that look different. SHAttered produced two visibly different PDFs with the same SHA-1 digest this way.
Chosen-prefix collision: the attacker picks two arbitrary different prefixes, for example a harmless end-entity certificate and a CA certificate, and computes suffixes that bring the digests together. This is far more powerful because the meaningful fields themselves can differ. The researchers behind the 2020 result stated that, with it, all attacks that are practical on MD5 are now practical on SHA-1.

The attacks that matter, with numbers

Year	Attack	Hash and type	What it achieved	Cost as reported
2008	Rogue CA certificate (presented 30 December 2008, 25th Chaos Communication Congress)	MD5, chosen-prefix	A legitimate certificate signed by a commercial CA, whose signature was copied onto a rogue intermediate CA certificate that browsers trusted	More than 200 PlayStation 3 consoles, about 18 hours for the birthdaying stage
2012	Flame espionage malware (found May 2012)	MD5, chosen-prefix, a previously unknown variant	A code-signing certificate chaining to Microsoft, obtained through the Terminal Server Licensing Service, used to sign fake Windows Update packages delivered by abusing WPAD as a man-in-the-middle proxy	Estimated lower bound about 2^46.6 MD5 compressions (Fillinger and Stevens)
2017	SHAttered (23 February 2017, CWI Amsterdam and Google)	SHA-1, identical-prefix	Two different PDFs with the same SHA-1 digest	About 2^63.1 SHA-1 compressions, roughly 6,500 CPU years and 100 GPU years; more than 100,000 times faster than brute force
2020	SHA-1 is a Shambles (Leurent and Peyrin)	SHA-1, chosen-prefix	Two PGP keys with different user IDs and colliding certification signatures, so a signature on one key transfers to the other (CVE-2019-14855)	Two months on 900 GTX 1060 GPUs; about USD 75k at the time, estimated USD 45k at publication and projected below USD 10k by 2025

What the rogue CA and Flame have in common

Both relied on a CA that still signed with MD5 and on fields the attacker could predict. RapidSSL issued sequential serial numbers and certificates about six seconds after purchase, so the 2008 team could predict exactly what the CA would sign. In Flame, Microsoft's own analysis led it to revoke trust in the Microsoft Enforced Licensing Intermediate PCA certificates and a Microsoft Enforced Licensing Registration Authority CA by moving them to the Untrusted Certificate Store (Security Advisory 2718704, 3 June 2012). The lesson for any issuer is the one the 2008 researchers gave: stop using the weak hash altogether, randomise serial numbers so the signed content cannot be predicted, and constrain what subordinate CAs can issue (for example path length constraints).

Flame is also an identity lesson. A licensing CA that nobody thought of as part of the code-signing trust chain was the weak point. Signing keys and the certificates that chain to them are non-human identities with enormous reach; inventory them as such. See the Code Signing Security Guide and the Enterprise PKI Design and CA Hierarchy Guide.

NIST's SHA-1 timeline

Year	NIST action
1995	SHA-1 specified in FIPS 180-1
2005	Serious attack on SHA-1 collision resistance announced
2006	NIST encourages rapid move to SHA-2 for digital signatures
2011	SP 800-131A deprecates SHA-1 for generating new digital signatures and restricts other uses to those allowed by protocol-specific guidance
2015	SHA-3 published as FIPS 202
December 2022	NIST announces it will stop using SHA-1 for cryptographic protection in all applications by 31 December 2030
Before 2031	Planned: FIPS 180-5 removing the SHA-1 specification, revision of SP 800-131A, and a transition strategy for the CMVP and CAVP validation programmes

NIST notes that SHA-1 may still be needed after 2030 to process information protected before the deadline, and the specification will remain available for that purpose. Module vendors are told to transition early to avoid validation delays. For FIPS-regulated environments, treat 2030 as the outer limit, not the plan.

Which uses are dangerous: decision guidance

Use	Collision risk	Priority	Replace with
Digital signatures over attacker-influenced content (certificates, code, documents, PGP certifications)	Direct: forged signatures	Immediate	SHA-256 or SHA-384 with the signature scheme; SHA-3 where supported
CA issuance, OCSP and CRL signing with SHA-1 or MD5	Direct: rogue certificates	Immediate	SHA-256 or stronger, random serial numbers
Integrity checks on downloads, artefacts or backups where an attacker can supply the original	Substitution of a prepared twin	High	SHA-256 digests, ideally signed
Content-addressed storage and deduplication (Git, artefact stores, dedup backups)	Two different objects treated as one	High for shared or public repositories	Collision-detecting SHA-1 now, SHA-256 object format as tooling allows
DNSSEC with SHA-1 algorithms (algorithm numbers 7 or lower)	Forged records	High	Algorithm 8 or 13; the Shambles authors explicitly advise upgrading
HMAC-SHA-1, HMAC-MD5	Low: HMAC does not depend on collision resistance in the same way	Planned refresh	HMAC-SHA-256; RFC 6151 advises no HMAC-MD5 in new protocols
Password storage with MD5 or SHA-1	Collision is not the issue; speed is	High, for a different reason	A password hashing function (Argon2id, scrypt, bcrypt, PBKDF2)
Non-security checksums, cache keys, file change detection with no adversary	None in practice	Low	Optional; replacing reduces audit noise

Password storage appears because it is the most common MD5 and SHA-1 finding in code reviews, but the fix is a slow, salted password hashing function rather than a faster cryptographic hash. See the Password Hashing and Key Derivation Guide.

Small organisations: focus on what you sign and what you trust. Check internal CA templates, code-signing and document-signing configurations, and any SSH or PGP keys still using SHA-1 signatures. Most other uses will be fixed by keeping libraries and platforms current.
Large organisations and product vendors: build a cryptographic inventory across code, certificates, protocols and stored data so SHA-1 and MD5 can be tracked to zero, and require FIPS module vendors to show their post-2030 plan. The Cryptographic Inventory and CBOM Guide covers the method.
Choosing the replacement: SHA-256 is the default for interoperability. SHA-384 or SHA-512 fit higher security levels and 64-bit platforms. SHA-3 (FIPS 202) is a structurally different family and a good hedge where it is supported.

Git: from SHA-1 to SHA-256

Git names every object by its hash, so a collision could make one blob, tree or commit stand in for another. Git's own transition document records the response:

Hardened SHA-1 since Git 2.13.0: Git moved by default to a hardened SHA-1 implementation that is not vulnerable to the SHAttered attack. The sha1collisiondetection library by Marc Stevens and Dan Shumow detects cryptanalytic collision attacks using any of the top 32 SHA-1 disturbance vectors, with a false-positive probability below 2^-90, and its README says it detects both SHAttered and the later Shambles attack. Git's document is clear that SHA-1 is still weak and future attacks may not have viable mitigations.
SHA-256 chosen in late 2018: enabled per repository with git init --object-format=sha256, which sets extensions.objectFormat = sha256 with repositoryFormatVersion = 1. SHA-1 remains the default.
Interoperability is the constraint: the git init documentation states that at present there is no interoperability between SHA-256 and SHA-1 repositories. The transition design adds extensions.compatObjectFormat to map names both ways, and strongly discourages SHA-256 storage on public-facing servers until the Git protocol supports it.
Signed commits and tags: a signature over a SHA-1 commit ID inherits SHA-1's weakness. With both object formats configured, Git's design generates both SHA-1 and SHA-256 signatures.

For most teams the practical position today is: run a current Git everywhere (clients, servers, CI runners) so hardened SHA-1 is in use, require signed commits and tags for release branches, and pilot SHA-256 repositories for new internal projects where hosting and tooling support it. See the Git Repository Security Guide.

How to find and remove MD5 and SHA-1

Inventory signatures and certificates: scan internal and public certificates (including intermediates and OCSP responders) for signature algorithms md5WithRSAEncryption, sha1WithRSAEncryption and ecdsa-with-SHA1; check CA templates and code-signing profiles.
Scan code and dependencies: search source for MD5 and SHA-1 calls in each language's crypto API and classify each by use (signature, integrity, HMAC, password, non-security). Static analysis rules for weak hashes are common in SAST tools.
Check protocols and configurations: SSH host and user key signature algorithms, TLS signature algorithm lists, DNSSEC algorithms, PGP key certification digests, SAML and XML signature digest methods, JWT and API signing settings.
Fix the high-risk group first: re-issue certificates, re-sign artefacts and switch signing profiles to SHA-256 or stronger; randomise serial numbers on any CA you operate.
Test in parallel: issue SHA-256 certificates or dual signatures to a pilot group, confirm older clients still validate, and keep the old chain available until the pilot passes.
Disable acceptance, not only issuance: after migration, configure verifiers to reject MD5 and SHA-1 signatures. This is the step most often missed, and it is what actually closes the attack.
Roll back safely: keep the previous configuration documented and time-boxed; if a legacy device fails, isolate it and set a replacement date rather than re-enabling SHA-1 globally.

Detection and measurement

Collision detection on ingestion: where SHA-1 must still be used, use a collision-detecting implementation (sha1collisiondetection's safe-hash mode returns a different hash when an attack is detected, so forged signatures become invalid without other changes).
Certificate monitoring: alert on any newly issued or observed certificate with an MD5 or SHA-1 signature, including in Certificate Transparency logs for your domains.
Verifier logs: log signature verification failures after you disable SHA-1 acceptance; a spike shows a forgotten dependency.

Metric	Target
Certificates in use signed with MD5 or SHA-1 (internal and public)	Zero
Signing profiles (code, documents, PGP, SSH CA) using SHA-1 or MD5	Zero
Verifiers still accepting SHA-1 signatures	Falling to zero, with named exceptions and dates
Code findings for MD5 or SHA-1 in security uses, by age	Downward trend, none older than one release cycle
Cryptographic modules with a documented post-2030 SHA-1 plan	100 percent of FIPS-relevant modules

Common failure patterns

Migrating issuance but not verification: new certificates use SHA-256, yet clients still accept SHA-1 signatures, so a forged SHA-1 certificate remains usable. This is the structural gap Flame exploited: one overlooked service still accepted MD5.
Forgetting non-obvious CAs: licensing, device, test and legacy CAs that chain to a trusted root are part of your signing trust whether or not anyone owns them.
Predictable certificate content: sequential serial numbers and instant automated issuance gave the 2008 team everything they needed.
Arguing that MD5 is "fine because preimages are unbroken": true for files you created and hash yourself; false whenever an attacker supplies content you sign, store or deduplicate.
Replacing password MD5 with SHA-256: it removes the audit finding but leaves passwords cheap to crack.
Treating hardened SHA-1 as the end state: Git and the library authors both describe it as a mitigation, not a fix.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-131A and FIPS 180-4/180-5	Transition of cryptographic algorithms; SHA-1 retirement by 31 December 2030	Primary policy driver for regulated environments
NIST SP 800-53 Rev 5	SC-13 Cryptographic Protection; SC-12 Cryptographic Key Establishment and Management; SR-4 Provenance	Approved algorithms, key and certificate management, artefact integrity
NIST CSF 2.0	PR.DS-01 and PR.DS-02 (data at rest and in transit protected); ID.AM-08 (life cycle management)	Integrity outcomes and crypto asset life cycle
MITRE ATT&CK v20	T1588.004 and T1587.003 Digital Certificates; T1553.002 Code Signing; T1557 Adversary-in-the-Middle	Forged certificates and signing abuse, as in Flame
ISO/IEC 27001:2022 Annex A	A.8.24 Use of cryptography	Cryptography policy and approved algorithms
IETF	RFC 6151 (MD5 and HMAC-MD5 security considerations)	MD5 not acceptable where collision resistance is required

Practitioner checklist

Inventory every certificate, CA template and signing profile and record its signature hash.
Re-issue anything signed with MD5 or SHA-1 and set SHA-256 or stronger as the only permitted signing hash.
Configure verifiers (TLS clients, code-signing checks, PGP, SSH, SAML) to reject MD5 and SHA-1 signatures.
Use random serial numbers and path length constraints on any CA you operate.
Upgrade DNSSEC zones away from SHA-1 algorithms.
Run current Git on clients, servers and CI; require signed release tags; pilot SHA-256 repositories where tooling allows.
Classify code findings for MD5 and SHA-1 by use and fix signature and integrity uses first; move password storage to a password hashing function.
Ask cryptographic module and product vendors for their SHA-1 removal plan ahead of 31 December 2030.

Hash collision attacks: how MD5 and SHA-1 broke and what to use