Cryptographic Hashes: MD5, SHA-1, SHA-2, SHA-3 Explained

Cryptographic hashes are everywhere in modern software — file checksums, password storage, digital signatures, blockchain, JWT signatures, content-addressable storage. Yet most developers can't confidently say which hash to use when, or why MD5 keeps showing up despite being "broken." This is the practical guide.

What a hash function actually does

A cryptographic hash function takes any input (string, file, or arbitrary bytes) and produces a fixed-size output. For SHA-256, the output is always 32 bytes (64 hex characters), regardless of input size — could be 1 byte or 1 GB.

Three properties matter:

1. Deterministic: same input always produces the same output.
2. One-way: computationally impossible to reverse the hash to find the input.
3. Collision-resistant: finding two inputs that produce the same hash should be infeasible.

When property 3 breaks for a hash function, that hash is "broken" for security purposes — but may still be useful for non-security uses like cache keys.

The five hashes you'll encounter

MD5 (1992) — broken but everywhere

128-bit output. Designed in the early 90s. Cryptographically broken since the mid-2000s — collisions can be found in seconds on a laptop.

Still safely used for:

• Non-security file checksums (verifying a download wasn't corrupted in transit).
• Cache keys and deduplication.
• Generating non-security identifiers (avatar URLs, etc.).

Never use MD5 for: password hashing, digital signatures, anything where an attacker might benefit from a collision.

SHA-1 (1995) — also broken

160-bit output. NSA-designed successor to MD5. Collisions demonstrated practically in 2017 (Google's "SHAttered" attack). Still better than MD5 in some ways but considered broken for security.

Found in:

• Git commit IDs (chosen for performance, not security — and Git is moving toward SHA-256).
• Old TLS certificates (deprecated).
• Legacy systems.

SHA-256 (2001) — the modern default

256-bit output. Part of the SHA-2 family. No practical attacks known. Used by:

• TLS certificates (since 2016).
• Bitcoin and many blockchains.
• Software signatures (Apple, Microsoft, Linux package managers).
• JWT signatures (HMAC-SHA256 is the most common).
• Generally anywhere a secure hash is needed in 2026.

SHA-384 and SHA-512

Longer outputs from the SHA-2 family. SHA-512 actually runs faster than SHA-256 on 64-bit hardware because it processes 64 bits at a time vs 32 bits. Use SHA-512 if:

• You need a longer hash for collision-resistance margin.
• You're hashing on 64-bit servers and care about throughput.

SHA-3 (2015)

Different algorithm (Keccak-based), included in case future attacks on SHA-2 emerge. Solid choice but not yet widely used. SHA-256 remains the default for almost all use cases.

HMAC — the signing wrapper

HMAC stands for Hash-based Message Authentication Code. It combines a hash function with a secret key to produce a signature that proves both:

• The data hasn't been tampered with.
• The signer knew the secret key.

Stripe webhook signatures, GitHub webhook signatures, AWS API request signatures — all use HMAC. Specifically HMAC-SHA256.

Verifying: recompute the HMAC on the message using the shared secret. If it matches the signature sent with the message, the message is authentic.

The Hash Generator has an HMAC mode for verifying webhook signatures during development.

Why MD5 and SHA-256 are NOT enough for passwords

The single most common misuse of hashes: storing user passwords as SHA-256(password). This is insecure for a specific reason: hashes are designed to be fast. A modern GPU can compute 30+ billion SHA-256 hashes per second.

When a database leaks, attackers don't need to "reverse" the hash — they just hash every common password and dictionary word and compare. 12-character passwords from a typical word list fall in minutes.

For passwords, use slow, salted, memory-hard functions designed for the job:

• bcrypt — the safe default. Tunable cost factor.
• scrypt — memory-hard, resistant to GPU attacks.
• Argon2 — the modern winner. Argon2id is the recommended variant in 2026.

None of these are hash functions like SHA-256 — they're password hashing functions. Different category, different purpose.

Salting — and why it matters

A salt is random bytes appended to the password before hashing. It does two things:

• Makes precomputed "rainbow table" attacks useless (every user has a different salt).
• Makes two users with the same password have different hashes.

bcrypt/scrypt/Argon2 automatically generate and embed a salt in the output. You don't have to manage it manually — but you must store the full output, not just the hash portion.

File integrity verification

Common practice: software vendors publish a SHA-256 hash alongside the download. You compute the hash of your download and compare. If it matches, the file is bit-identical to what was published.

MD5 is still used here for legacy reasons. It detects accidental corruption fine — what it can't detect is a malicious attacker who replaced the file with one engineered to have the same MD5. For software downloads in 2026, prefer SHA-256.

Hashing vs encryption — they're different

• Hashing: one-way. You can't get the input back from the output. Used for verification.
• Encryption: two-way. You can recover the plaintext with the key. Used for confidentiality.
• Encoding (Base64, etc.): two-way and no key. Just changes representation. Used for transport.

Confusing these is a security anti-pattern. "Encrypt my password" usually means "hash my password" — the words matter.

The quick reference

• File checksum (non-security): MD5 is fine.
• File integrity (security): SHA-256.
• Webhook signature verification: HMAC-SHA256.
• Password storage: bcrypt, scrypt, or Argon2 — NOT raw SHA-256.
• Cache keys, deduplication: MD5 or SHA-256 (either is fast enough).
• Cryptocurrency / digital signatures: SHA-256.
• Future-proofing: SHA-256 is the safe default for 2026.