Why SHA-1 Is Deprecated — and What to Use Instead

SHA-1 was the default cryptographic hash for two decades. It signed every TLS certificate, every Git commit, every Microsoft binary. Then on February 23, 2017, Google and CWI Amsterdam published SHAttered — two different PDF files with identical SHA-1 hashes. The countdown to deprecation, which had already been ticking, hit zero.

In 2026 SHA-1 is gone from most security contexts but lingers in a few places where backwards compatibility wins. Knowing which is which is the difference between writing reasonable legacy code and writing a vulnerability.

The SHAttered attack

SHAttered was the first practical SHA-1 collision: two different PDFs with the same SHA-1 hash. Google and CWI Amsterdam constructed them deliberately, using about 6,500 CPU-years and 100 GPU-years of computation — roughly $110,000 of cloud compute at 2017 prices.

This sounds expensive, but two things matter:

1. It was the worst case for the attacker. Subsequent research drove the cost down sharply. In 2020, researchers demonstrated chosen-prefix collisions for SHA-1 — far more powerful than identical-prefix collisions — at a cost of $45,000.
2. Cloud computing keeps getting cheaper. In 2026 the same attack costs a few hundred dollars to a few thousand, depending on GPU availability.

For comparison: the SHA-256 collision attack remains at 2²⁵⁶ work, which is roughly the number of atoms in the observable universe. It is not happening with any conceivable technology.

Where SHA-1 was deprecated, and when

Year	Event
2005	Wang, Yin, Yu publish first theoretical SHA-1 collision attack (2⁶⁹ work)
2011	NIST formally deprecates SHA-1 for digital signatures (effective 2014)
2014	Google announces Chrome will phase out SHA-1 TLS certificates
2016	Mozilla, Microsoft, Apple all stop accepting SHA-1 TLS certificates
Feb 2017	SHAttered: first practical SHA-1 collision demonstrated
2017	Microsoft deprecates SHA-1 code signing in Windows Update
2020	Chosen-prefix SHA-1 collisions demonstrated at $45K cost
2022	OpenSSH disables SHA-1 in default configuration
2023	NIST formally deprecates SHA-1 for all applications by 2030

Where SHA-1 still lives (and whether that's OK)

HMAC-SHA1: still fine

HMAC is a construction that uses a hash function as a building block but doesn't rely on collision resistance — only on the hash function being a good pseudorandom function. HMAC-SHA1 is still considered cryptographically sound and is used in many existing APIs (older AWS signature versions, OAuth 1.0a, some legacy webhooks).

That said, for new code, prefer HMAC-SHA-256. It's not vulnerable to anything, it's not slower in any meaningful sense on modern hardware, and you don't have to explain to a security auditor why you chose the deprecated option.

Git commit IDs: still SHA-1 (mostly)

Every Git commit, blob, and tree is identified by its SHA-1 hash. Git's vulnerability to SHAttered was the subject of intense discussion in 2017. Linus Torvalds (Git's creator) noted that Git's content model — which includes file paths and metadata in the hashed content — makes practical SHAttered-style attacks on Git repositories much harder than on bare PDFs.

Git has implemented a "SHA-1dc" variant (SHA-1 with hardened collision detection that aborts on detected collisions) by default since 2017. A migration to SHA-256 is underway but slow — most existing repositories still use SHA-1. For now, this is acceptable; the practical risk is low.

Some older internal protocols

SHA-1 still appears in legacy NTLM authentication, some Active Directory operations, and old enterprise systems. These should be migrated when feasible, but they're rarely the highest-risk item on a security review.

Where SHA-1 is dangerous in 2026

• TLS certificates. Banned by all major browsers. Don't even try.
• Code signing. Banned by Microsoft Authenticode, Apple notarization, Linux package signing.
• Software download checksums. If you publish a SHA-1 next to a download link, an attacker who controls your CDN can substitute a collision-crafted backdoor. Use SHA-256.
• Document signing. Adobe disabled SHA-1 for PDF signatures in 2017.
• SSH host keys. Modern SSH defaults to Ed25519 or ECDSA; SHA-1 RSA host keys are increasingly rejected.

What to use instead

• SHA-256 — the default replacement. Universal library support, hardware-accelerated, no known practical attacks.
• SHA-512 — when you want more security margin or are on a 64-bit system where it's actually faster than SHA-256.
• BLAKE2 / BLAKE3 — modern, very fast cryptographic hashes. Library support is improving but not as universal as SHA-2.
• SHA-3 — the newest NIST standard, structurally different from SHA-2. Use if you specifically need diverse algorithms for defense in depth.

Migration playbook

If you have SHA-1 in your system, here's the order to address it:

1. External-facing signatures and certificates first. These are where attackers can exploit collisions to forge identity. Highest risk.
2. Download checksums next. Anywhere users compare a hash to confirm authenticity.
3. API signing. Migrate from HMAC-SHA1 to HMAC-SHA256 — usually a config flag change.
4. Internal data integrity. Lower priority if the integrity check is just guarding against accidental corruption.
5. Storage layer (Git, etc.). Follow the upstream migration timeline; don't reinvent.