Hash Functions: MD5, SHA-256 & Password Hashing

Algorithm

Digest bits

Status

Typical use

SHA-1

160 bit / 40 hex

Broken, avoid for security

Git commit IDs, dedup

SHA-256

256 bit / 64 hex

Recommended

Salted passwords, certs, blockchain

SHA-384

384 bit / 96 hex

Recommended

High-security, TLS

SHA-512

512 bit / 128 hex

Recommended

File integrity, password hashing

Hash Functions: MD5, SHA-256 & Password Hashing

Updated 2026.08.01~3 min read

Hash = one-way fingerprint: same input → same output; infeasible to reverse. MD5 (128-bit) and SHA-1 are BROKEN for security; SHA-256 for integrity; passwords need SLOW salted hashes (bcrypt/argon2) — never fast hashes. Includes collision math and file-verification workflow.

Key Takeaways

One-way: input → fixed-length fingerprint; reversing is computationally infeasible

Broken: MD5 and SHA-1 collisions are practical — checksums only, never security

Integrity: SHA-256 for file verification (compare published hash vs local)

Passwords: bcrypt/scrypt/argon2 (slow + salted) — plain SHA-256 falls to GPU brute force

Core answer: A hash function maps any input to a fixed-size fingerprint: MD5 → 128 bits (32 hex chars), SHA-1 → 160 bits (40 hex), SHA-256 → 256 bits (64 hex). Same input = same output always; change one bit and ~half the output bits flip (avalanche). MD5 and SHA-1 are BROKEN for security (collisions found) — fine for checksums, forbidden for passwords/signatures. Passwords need slow salted KDFs: bcrypt, scrypt, Argon2.

The algorithm lineup

Algorithm	Output	Status	Use for
MD5	128 bit	broken (2004 collisions)	file checksums only
SHA-1	160 bit	broken (2017 SHAttered)	legacy, git internals
SHA-256	256 bit	secure	signatures, blockchain, checksums
SHA-512	512 bit	secure	high-margin apps
bcrypt/scrypt/Argon2	slow+salted	password-grade	password storage ONLY
CRC32	32 bit	not cryptographic	error detection

Hash ≠ encryption ≠ encoding

Hash: one-way; you cannot "decrypt" a hash; verification = re-hash and compare.
Encryption: two-way with a key (AES).
Encoding: two-way without a key (Base64).

Calling base64 "encryption" or expecting to "decrypt MD5" are the two classic confusions.

Worked examples

Example 1 — File integrity. Download page shows SHA-256 abc123...; after download run sha256sum file.iso and compare — one flipped bit anywhere changes the whole hash. Mismatch = corrupted or tampered file.

Example 2 — Password storage done right. Never store SHA-256(password) — attackers brute-force billions/sec and rainbow-table common passwords. Store bcrypt(password, cost=12, random salt): ~250 ms per attempt, salts defeat precomputed tables.

Example 3 — Deduplication. A photo cloud hashes each upload; identical files hash identically → store one copy. Millions of users' identical memes = one object.

Example 4 — Cache busting. app.a3f9c2.js: content hash in the filename means immutable caching (1 year) with instant invalidation on change — the standard frontend deploy pattern.

Common mistakes and myths

MD5 for security — collision attacks are practical (two different PDFs with the same MD5 since 2008); use SHA-256 for anything adversarial.
Fast hash for passwords — SHA-256(password) falls to GPU brute force at billions/s; KDFs exist precisely to be slow and memory-hard.
"Salted MD5 is fine now" — no; migrate legacy hashes on next login: verify old, rehash with Argon2/bcrypt, store new.
Hash = signature — HMAC (keyed hash) proves authenticity; a plain hash proves only integrity against accidents, not attackers who can recompute it.
Believing longer is always better — SHA-512 on 64-bit CPUs is often FASTER than SHA-256 and truncating it is standard (SHA-512/256); pick per platform.

Frequently Asked Questions

What is a hash function?

A deterministic one-way compressor: any input → fixed-length output (SHA-256: 64 hex chars = 256 bits). Properties: same input always same output; one bit changed flips ~half the output bits (avalanche); finding an input from its output (preimage) or two inputs with equal output (collision) should be computationally infeasible. Not encryption — no key, no decryption, by design.

MD5, SHA-1, SHA-256 — which should I use?

MD5 (32 hex chars): broken since 2004 (collisions in seconds) — fine only for non-adversarial checksums/dedup. SHA-1 (40 chars): collision demonstrated (SHAttered, 2017) — deprecated for security. SHA-256/512: current standard for integrity, signatures, certificates. BLAKE3/SHA-3: modern alternates, faster or more conservative. Rule: security context → SHA-256 minimum; speed context without attackers → anything works.

How do I verify a downloaded file?

The publisher posts a hash; you hash the local file and compare. Linux/macOS: sha256sum file.iso; Windows: certutil -hashfile file.iso SHA256 (or Get-FileHash in PowerShell). Match = intact and authentic (assuming the hash page itself is authentic/HTTPS). A single-bit corruption or tamper changes the hash completely — this is how Linux ISOs, blockchain blocks and git commits guarantee integrity.

Why can't passwords use plain SHA-256?

Fast hashes are the problem: GPUs compute ~10 billion SHA-256/s — an 8-char password falls in hours. Password hashing needs SLOW algorithms with memory hardness: bcrypt (cost factor), scrypt, argon2id (current recommendation) — milliseconds per attempt × attackers' trillions of guesses = years. Plus a per-user random SALT defeats rainbow tables. Storing MD5/SHA1/SHA256 of passwords is a breach headline waiting to happen.

What is a hash collision and how likely is it?

Two different inputs, same fingerprint. Birthday math: a 256-bit hash has ~2¹²⁸ collision resistance — write 1 billion hashes/second and expect a collision after 10²² years (sun dies first). MD5's weakness is mathematical, not brute force: crafted collisions cost seconds. Practical impact: git (moving off SHA-1), certificates (SHA-1 banned since 2017), evidence integrity in court (use SHA-256+).

What mistakes happen with hashes?

(1) "Encrypted" passwords that are actually unsalted fast hashes (see the audit section above); (2) MD5 for security decisions; (3) hashing secrets without salt (rainbow tables precompute common inputs); (4) double-hashing as a homemade KDF (use argon2/bcrypt — composition pitfalls are subtle); (5) assuming hash = anonymity (small input spaces like phone numbers reverse by enumeration); (6) truncating hashes without understanding birthday-bound loss; (7) using hashes as IDs for attacker-controlled inputs (collision games).