Hashing, HMAC & Checksums Explained

A cryptographic hash turns any input — a word, a file, a gigabyte of video — into a short, fixed-size fingerprint called a digest. It’s one of the most useful primitives in computing: it powers integrity checks, digital signatures, webhooks, version control and password storage. This guide explains what hashing is, which algorithms to trust, and how HMAC and password hashing differ from plain hashing.

What a cryptographic hash is

A good cryptographic hash function has these properties:

• One-way — you cannot reverse the digest back into the input.
• Fixed-size output — SHA-256 always produces 256 bits (64 hex characters) no matter how big the input is.
• Deterministic — the same input always produces the same digest.
• Avalanche effect — changing a single bit of input flips about half the output bits, so similar inputs give completely different digests.
• Collision resistance — it’s infeasible to find two different inputs with the same digest.
• Preimage resistance — given a digest, it’s infeasible to find any input that produces it.

Crucially, hashing is not encryption (encryption is reversible with a key) and not encoding (encoding like Base64 is reversible by anyone). A hash throws information away on purpose — there is no key and no way back.

The hash families

MD5 (1992) and SHA-1 (1995) are considered broken for collision resistance. Practical collision attacks exist for both, so they must not be used for signatures, certificates or any security decision. They survive only as fast, non-adversarial checksums and legacy hash-table keys.

SHA-2 (2001) — the family SHA-224/256/384/512 — is the current default. SHA-256 is the everyday workhorse; SHA-384/512 offer larger digests. No practical attacks exist, and it’s what you should reach for unless you have a specific reason not to.

SHA-3 (2015) is a newer standard built on a completely different internal design (the Keccak sponge construction). It’s not a replacement for SHA-2 but a diversified alternative in case a future weakness is found in SHA-2’s structure.

BLAKE2 / BLAKE3 also exist — modern, extremely fast hashes that are as secure as SHA-2/3 and popular where raw speed matters (e.g. BLAKE3 for large-file hashing).

Comparison

Algorithm	Output size	Status	Typical use
MD5	128-bit	Broken (collisions)	Legacy checksums only — never for security
SHA-1	160-bit	Broken (collisions)	Legacy; git object IDs (being migrated)
SHA-256	256-bit	Secure	Default for integrity, signatures, checksums
SHA-384 / 512	384 / 512-bit	Secure	Higher-security signatures, TLS
SHA-3 (256/512)	256 / 512-bit	Secure	Alternative to SHA-2, defence in depth
BLAKE2 / BLAKE3	variable	Secure	High-speed hashing, large files

HMAC — keyed hashing for authenticity

A plain hash proves integrity (the data wasn’t changed) but not authenticity (who sent it) — anyone can recompute a plain hash over tampered data. HMAC (Hash-based Message Authentication Code) fixes this by mixing a secret key into the hashing process.

Only someone holding the shared secret can produce a valid HMAC, so the recipient knows the message is both intact and from a trusted sender. HMAC is written as HMAC-SHA256, HMAC-SHA1, etc., naming the underlying hash. You’ll meet it in:

• Webhook signatures — GitHub, Stripe and others sign each payload with HMAC-SHA256 so you can verify it really came from them.
• JWT HS256 — the HS256 algorithm is HMAC-SHA256 protecting the token’s integrity and authenticity.
• API request signing — AWS Signature v4 and similar schemes.

Note that HMAC is not the same as simply hashing key + message; its two-pass construction (defined in RFC 2104) is specifically designed to resist length-extension and related attacks.

Password hashing is different

Do not hash passwords with SHA-256. General-purpose hashes are built to be fast, and speed is exactly what an attacker wants — a stolen database of SHA-256 hashes can be brute-forced at billions of guesses per second on a GPU.

Password storage needs purpose-built, slow, salted functions:

• Argon2id — the modern first choice (memory-hard, tunable).
• scrypt — memory-hard, a solid alternative.
• bcrypt — older but still acceptable and widely supported.

Two ideas make these work:

• Salt — a unique random value added to each password before hashing. Salts ensure identical passwords produce different stored hashes and defeat precomputed rainbow tables. (Modern password hashers generate and store the salt for you.)
• Deliberate slowness / cost factor — these functions are tuned to take a meaningful fraction of a second per hash. That’s negligible for one login but makes mass brute-forcing of a leaked database economically infeasible.

Checksums for file integrity

A checksum is just a hash used to verify that a file downloaded or copied without corruption or tampering. Projects publish a SHA256SUMS file; you hash your downloaded copy and compare:

sha256sum ubuntu.iso
# compare the output against the published SHA-256 sum

If the digests match, the file is intact. Use SHA-256 for this — MD5/SHA-1 sums still appear on some sites but only guard against accidental corruption, not a malicious swap.

Best practices

• Use SHA-256 or stronger for integrity and general-purpose hashing.
• Use HMAC (with a secret key) when you need to prove authenticity, not just integrity.
• Use bcrypt, scrypt or Argon2id for passwords — never a plain SHA, and always salted.
• When comparing a computed hash/HMAC against an expected value, use a constant-time comparison (e.g. crypto.timingSafeEqual) to avoid leaking information through timing.
• Retire MD5 and SHA-1 from any security-sensitive path.

References

• FIPS 180-4 — Secure Hash Standard (SHA-1, SHA-2 family).
• RFC 2104 — HMAC: Keyed-Hashing for Message Authentication.
• NIST: SHA-1 deprecation / hash function policy — guidance retiring MD5 and SHA-1.
• OWASP Password Storage Cheat Sheet — Argon2/scrypt/bcrypt and salting.

Try it: generate digests and signatures right in your browser with the Hash, HMAC and MD5 tools — everything runs client-side via the Web Crypto API.