MD5, SHA-256, and Why Hashing Isn't Encryption

The Downloaded File I Almost Didn't Verify

Late 2023. I'm downloading a Linux distro ISO, Ubuntu, nothing exciting. The mirror page shows an SHA256 checksum next to the download link. I almost skip it. Who actually checks these, right?

Two weeks later, news drops that a mirror got compromised. Attackers had replaced the ISO with a modified version containing some lovely malware. Anyone who downloaded from that mirror and didn't verify the hash... well, they had a bad time.

I happened to use a different mirror. Pure luck. But now I check hashes religiously. Takes 10 seconds. Could save you from a rootkit.

What's a Hash? (No, Not That Kind)

A hash function takes input, any input, any size, and spits out a fixed-length output. Same input always produces the same output. But you can't reverse it. Given the output, you can't figure out the original input.

MD5("hello")    → 5d41402abc4b2a76b9719d911017c592
SHA256("hello") → 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c...

Change literally one character:

MD5("Hello")    → 8b1a9953c4611296a827abf8c47804d7

Completely different. This is the "avalanche effect", tiny input changes create totally different outputs. That's what makes hashes useful for detecting modifications.

The Alphabet Soup of Hash Algorithms

MD5 . 128 bits, fast, broken. You can manufacture collisions (different inputs producing same hash) with consumer hardware. Still fine for non-security stuff like file integrity checks, but never use it for passwords or authentication.

SHA-1 , 160 bits, also broken. Google demonstrated a practical collision in 2017. Chrome started rejecting SHA-1 certificates that same year. Dead algorithm walking.

SHA-256 , 256 bits, part of the SHA-2 family. Currently the standard for most things. No practical attacks known. This is probably what you want.

SHA-3 , Different algorithm entirely (Keccak internally). Considered more "future-proof" because it's architecturally different from SHA-2. Not widely deployed yet because SHA-256 works fine and nobody's panicking.

bcrypt, scrypt, Argon2 , These are specifically for password hashing. They're intentionally slow, running them takes time on purpose to prevent brute-force attacks. If someone says they hash passwords with SHA-256, that's... technically functional but not ideal. Use the password-specific ones.

When You'll Actually Use Hashing

Verifying downloads. Hash the file you downloaded, compare to published hash. If they match, file wasn't corrupted or tampered with. If they don't match, something's wrong.

Password storage. Store hashes, not passwords. When someone logs in, hash their input and compare to the stored hash. If it matches, they're in. If your database leaks, attackers get hashes, not passwords. (Use bcrypt or Argon2 though, not raw SHA.)

Finding duplicates. Got 50,000 files and want to find duplicates? Hash them all. Same hash = same file. Way faster than comparing byte-by-byte.

Git commits. Every commit is identified by its SHA-1 hash. (Yes, that's the broken one. Git is slowly migrating to SHA-256. Slowly.)

Blockchain stuff. Every block contains a hash of the previous block. That's the "chain" part. Modifying old data would change the hash, breaking the chain. I'm not a crypto colleague but the cryptography is actually clever.

Hashing Is Not Encryption

I'm going to say this louder for the people in the back: hashing is not encryption.

Encryption: reversible with the right key. Put data in, get scrambled data out. Put scrambled data + key in, get original data back.

Hashing: one-way. Put data in, get hash out. That's it. No key. No way to get the original data from the hash. You can only guess inputs and check if they produce matching outputs.

If someone tells you they "encrypted" data with MD5, they don't understand what they're doing. Run.

The Tool

Hash Generator: paste text, get MD5, SHA-1, SHA-256, and SHA-512 hashes instantly. Runs in your browser. we do not process your input.

I use this mostly for verifying file checksums and occasionally generating deterministic IDs from strings (SHA-256 of a URL makes a decent unique key).

Common Screwups

MD5 for passwords. Rainbow tables exist: precomputed hashes for common passwords. MD5 without salting is instantly crackable. Use proper password hashing algorithms with salts.

Assuming hash = secure. If someone can try millions of inputs per second, they'll find matches eventually. That's why password hashes need to be slow on purpose.

Case sensitivity. ABC123 and abc123 as hex strings represent the same value. Always normalize to lowercase before comparing. I've seen bugs from this exact issue.

Ignoring the algorithm. "Verify the hash" means nothing if you don't know which algorithm was used. MD5 and SHA-256 hashes look different. MD5 is shorter. Always check.

Generate hashes now and maybe go verify that ISO you downloaded last month. Just in case.

How password hashing actually works in production

When you store a user's password, you never store the plain text. You hash it first. But raw hashing isn't enough because of rainbow tables, which are precomputed lookup tables for common password hashes.

Here's the secure approach:

1. Generate a random salt for each user. A salt is a unique random string added to the password before hashing.
2. Hash the password combined with the salt using a slow algorithm like bcrypt, scrypt, or Argon2.
3. Store both the salt and the hash together.

When the user logs in, you take their input, add the stored salt, hash it, and compare to the stored hash. If they match, the password is correct.

The key difference from regular hashing is that password hashing algorithms are intentionally slow. bcrypt takes about 250 milliseconds per hash. That sounds terrible for performance, but it's exactly what makes brute-force attacks impractical. An attacker trying to guess a password would need 250 milliseconds per guess instead of nanoseconds.

If you're building authentication today, use bcrypt with a cost factor of 12 or higher. Argon2 is even better if your runtime supports it. Never use MD5 or SHA-256 alone for password storage.

Hashing for data integrity in CI/CD

Most developers don't think about hashing outside of passwords and file verification, but it shows up in CI/CD pipelines too. When you pin a dependency to a specific hash, you ensure that the package hasn't been tampered with since you last reviewed it.

npm, pip, and Go modules all support hash verification. When you run npm install, the lock file contains hashes of every installed package. If someone compromises a package on the registry and pushes a malicious version, the hash won't match and npm will refuse to install it.

This is why lock files matter. They're not just about version pinning. They're a security layer that prevents supply chain attacks. Never delete your lock file to "fix" an installation problem. Find the real issue instead.

GitHub Actions also supports hash pinning for actions. Instead of referencing an action by version tag, which can be moved, reference it by commit hash. This prevents an attacker from tagging a malicious commit with a legitimate version number.

Choosing the right algorithm

The algorithm you choose depends on your use case:

File verification and checksums: SHA-256. Fast, secure, and widely supported. Every major operating system includes sha256sum or a similar tool.

Password storage: bcrypt or Argon2. Slow by design. Never use fast hash algorithms for passwords.

Data deduplication: Any fast hash. SHA-256 or even MurmurHash if you're working with millions of items and need speed over collision resistance.

Digital signatures: SHA-256 or SHA-3 with RSA or ECDSA. The hash is part of the signature algorithm.

HMAC for API authentication: SHA-256 with a secret key. This proves that the message came from someone who knows the key without revealing the key itself.