ハッシュアルゴリズムの選び方:ダイジェスト、パスワードハッシュ、MAC は 3 つの異なる仕事

问题

SHA-2、SHA-3、BLAKE2、MD5、bcrypt/Argon2、HMAC のフィールドガイド。整合性チェック、パスワード保管、メッセージ認証のそれぞれに何が適し、なぜ互換性がないのかを解説します。

ステップ

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.

期待される結果

ハッシュ化の必要性を、整合性検証・パスワード保存・メッセージ認証のいずれかに分類し、それぞれに適した方式(ダイジェストには SHA-256、パスワードには bcrypt/Argon2、認証には HMAC)を選べるようになります。1 つのアルゴリズムを 3 つの用途に使い回すことはありません。