SHA-1 is a cryptographic hash function published in 1995 by NIST, producing a 160-bit (40-hex-character) digest. The tool above computes SHA-1 in your browser; the input never leaves your machine.
Status: broken for collisions, otherwise intact
SHA-1’s collision resistance is broken. The 2017 SHAttered attack demonstrated two different PDF files with the same SHA-1 digest. Subsequent attacks have made finding collisions cheaper.
What remains intact:
- Pre-image resistance. Given a digest, you still cannot recover the input.
- Second-pre-image resistance. Given an input, you cannot find a different input with the same digest. (This is harder than finding any collision.)
What’s broken:
- Collision resistance. An attacker can construct two different inputs with the same digest in feasible time.
The implications mirror MD5: SHA-1 is broken for code-signing, certificate fingerprints, and any use where an attacker chooses both inputs. It’s still adequate for accidental-corruption checksums and applications where inputs are not adversarially chosen.
Where SHA-1 still appears
- Git internal object IDs. Git uses SHA-1 to identify commits, trees, blobs. Git has been migrating to SHA-256 since 2020, but SHA-1 is still the dominant default for existing repos.
- HMAC-SHA-1. Used in some legacy authentication protocols (older AWS Signature versions, OAuth 1.0a). HMAC’s security depends on the underlying hash being collision-resistant for one of the inputs only — and SHA-1’s pre-image resistance is intact, so HMAC-SHA-1 is still secure.
- TOTP / two-factor codes. RFC 6238 defaults to HMAC-SHA-1. Time-based one-time passwords (Google Authenticator) typically use SHA-1.
- Older TLS certificates. Browsers deprecated SHA-1 certificates by 2017. Internal/legacy systems may still have them.
- Legacy file checksums. Some software distributions still publish SHA-1 alongside SHA-256.
A worked example
Input: "hello"
SHA-1: aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d
Input: "Hello"
SHA-1: f7ff9e8b7bb2e09b70935a5d785e0cc5d9d0abf0
Avalanche — one bit of input change scrambles the entire output.
SHA-1 vs MD5 vs SHA-256
| Algorithm | Output | Collision-secure | Speed |
|---|---|---|---|
| MD5 | 128 bits | No | Very fast |
| SHA-1 | 160 bits | No (since 2017) | Fast |
| SHA-256 | 256 bits | Yes | Fast |
| SHA-512 | 512 bits | Yes | Faster on 64-bit |
For new code: use SHA-256. SHA-1 is acceptable for backward-compatibility with systems that require it (Git, TOTP, certain HMAC uses) but isn’t a default.
What SHA-1 isn’t
- Not encryption. Hashes are one-way; SHA-1 has no inverse.
- Not safe for password storage. Fast — billions of guesses per second on a GPU. Use Argon2 / bcrypt / scrypt.
- Not safe for code-signing. Use SHA-256 or stronger.
- Not adequate for new TLS certificates. Browsers reject them.
Common pitfalls
- Using SHA-1 for new collision-sensitive applications. Even if “the threat model seems low,” code review will flag it. SHA-256 is the safe default.
- Trusting SHA-1 software-distribution checksums. A determined attacker can construct a malicious binary that matches a target SHA-1. Modern publishers post SHA-256.
- Comparing SHA-1 hashes loosely. Compare all 40 hex characters.
- Confusing SHA-1 with SHA-2. SHA-1 and SHA-256/SHA-512 share a name but are different algorithms. SHA-256 is not a “newer SHA-1”; it’s a different design.
- Using SHA-1 alone where HMAC-SHA-1 is needed. Bare SHA-1 doesn’t authenticate —
sha1(secret + message)is vulnerable to length-extension. Use HMAC, which is properly designed.
For better algorithms, see SHA-256, SHA-512. For the multi-algorithm tool, see hash generator. For verifying file integrity, file hash.