Choosing the Right Hashing Algorithm (SHA-256 vs HMAC vs Password Hashing)

SHA‑256 is not a silver bullet for every problem. Different hashing scenarios—integrity checks, message authentication, password storage—require different primitives. Using the wrong one can leak secrets or enable offline cracking.

Three broad categories

Fast unkeyed hash: e.g. SHA‑256 for integrity (detect accidental corruption) and content addressing.
Keyed hash (MAC): HMAC SHA‑256 for authenticity (prove a message came from someone holding a secret key).
Password hashing / KDF: bcrypt, scrypt, Argon2 to slow attackers with adaptive cost + memory hardness.

When to use SHA‑256

Great for deterministic fingerprints: file integrity, caching keys, verifying downloaded binaries (paired with a signature), building Merkle trees, or deriving short IDs after truncation (with collision risk considerations). Never store user passwords as raw SHA‑256 hashes—GPU cracking devastates static fast hashes.

When to use HMAC

Need to guarantee that a message was produced by a holder of a secret key? Use HMAC. It combines a secret with the message in a construction resilient to length extension attacks affecting naive keyed hashing. Use cases: API webhook signing, short‑lived token validation, anti‑tamper checks for query params or cookies (server verifies authenticity).

When to use password hashing algorithms

These deliberately add cost. bcrypt (CPU + configurable rounds), scrypt (adds memory), Argon2 (modern multiple variants, memory + parallelism). This cost makes large‑scale brute force impractical. Selecting a cost: target ~100ms per hash on your production hardware, revisiting periodically.

Salts, peppers, and iteration

Salt: Unique per password; defeats rainbow tables and password reuse correlation.
Pepper: Optional application‑wide secret stored separately (e.g. HSM / env) to add another barrier.
Adaptive cost: Increase difficulty over time; Argon2 offers memory + time parameters.

Common mistakes

Using plain SHA‑256 for stored passwords.
Omitting HMAC and concatenating a secret: sha256(secret + message) (risk: length extension patterns elsewhere).
Double hashing instead of using a proper KDF.
Skipping salt (enables reverse lookup across breaches).

Sample flows

// File integrity
sha256(file_bytes) -> compare to published hash

// Webhook verification (server side)
expected = hmac_sha256(secret, body)
provided == expected ? accept : reject

// Password storage (server)
hash = argon2(password, unique_salt, memory, iterations)
store(hash, salt, params)

Related tools

SHA256 Generator – compute digests for integrity checks.
HMAC SHA256 – derive keyed message authentication codes.
Password Generator – produce strong random credentials before hashing server‑side.