Choosing a hash algorithm: digests, password hashing, and MACs are three different jobs

问题

A field guide to SHA-2, SHA-3, BLAKE2, MD5, bcrypt/Argon2, and HMAC — which one fits integrity checks, password storage, and message authentication, and why they are not interchangeable.

Schritte

1. 1. Three jobs that get confused

   Integrity digests answer 'did these bytes change?' (file checksums, cache keys, content addressing). Password hashing answers 'is this the password?' while deliberately being slow and salted. Message authentication (HMAC) answers 'who produced this and did it change in transit?' — it requires a shared secret. Each job constrains the algorithm differently, and most hash-related incidents come from using a tool built for one job in another.

2. 2. Integrity digests: SHA-256 as the default

   For checksums, content addressing (git objects, OCI layers, IPFS), and signatures over data, SHA-256 is the sane default: fast in hardware (SHA-NI instructions), universally available (Web Crypto, every language's stdlib), and collision-resistant in practice. SHA-3 and BLAKE2/BLAKE3 are excellent alternatives — BLAKE2 in particular is faster than MD5 while being cryptographically modern. MD5 and SHA-1 remain acceptable only for detecting accidental corruption (legacy checksum files, de-duplication), never for collision-sensitive uses: both have demonstrated chosen-prefix collisions.

3. 3. Password hashing: the opposite design goal

   A password verifier wants to be expensive, because the attacker's cost is your user's risk. Fast digests (even SHA-256) hash billions of guesses per second on commodity GPUs. Dedicated password hashing — Argon2id (the current recommendation), scrypt, bcrypt, or PBKDF2 as the compatibility floor — applies tunable work factors (memory, CPU, iterations) and unique per-password salts. Salt is not optional: without it, identical passwords produce identical hashes and rainbow tables work. Salt is not secret: it is stored alongside the hash; the work factor is the defense. Revisit cost parameters every few years — they should track hardware, which only gets faster.

4. 4. HMAC: authenticity needs a secret

   A plain digest of 'data + timestamp' does not stop an attacker from recomputing it. HMAC pairs the hash with a shared secret (HMAC-SHA256 being the default) so only key holders can produce a valid tag — the basis of webhook signatures, JWT HS256, and signed URLs. Two rules: use a real HMAC construction rather than naive concatenation (length-extension attacks), and compare tags with a constant-time equality check, not '=='.

5. 5. A decision table

   File checksum / content address → SHA-256 (or BLAKE2/SHA-3). Password storage → Argon2id, else bcrypt or PBKDF2 with high iteration counts. Webhook/API request authentication → HMAC-SHA256. Legacy MD5/SHA-1 → tolerate for corruption checks only, schedule replacement. New designs never start with MD5 or SHA-1, and 'we also Base64 it' never made any of this secret — encoding and hashing remain different layers.

Erwartetes Ergebnis

You can classify a hashing need as integrity, password storage, or message authentication, and pick the right family — SHA-256 for digests, bcrypt/Argon2 for passwords, HMAC for authenticity — instead of reusing one algorithm for all three jobs.