Hash Deep-Dive

Operate real hash functions — MD5 through SHA-512, PBKDF2, HMAC — and understand each one's purpose and limits

FIPS 180-4 · RFC 2104 · SP 800-132 · SY0-701 1.4
Missions 0 / 5
Security+ Hub
This lab needs the Web Crypto API, which requires a secure context (HTTPS). Open it at https://hexworth.com.

Mission 1 — Algorithm Tour

Hash the same input through MD5, SHA-1, SHA-256, and SHA-512 and observe the digest, bit-length, and relative speed. MD5 is computed with a built-in JS implementation (Web Crypto does not offer MD5); SHA-1 through SHA-512 use the real crypto.subtle.digest API. Understand why MD5 and SHA-1 are retired and when SHA-256+ is required.

Objective: run all four algorithms on the same input, read the digest lengths and speed bars, then confirm you understand which algorithms are broken before proceeding.

MD5 (128-bit) and SHA-1 (160-bit) have known practical collision attacks. FIPS 180-4 mandates SHA-256 or higher for new work. Speed is displayed for educational context; for passwords speed is the enemy — see Mission 3.

Mission 2 — MD5 Collision Demo

A hash collision occurs when two different inputs produce the exact same digest. MD5 collisions are computationally practical since Wang and Yu (2004). Below are two short binary inputs (Lenstra et al., 2005) that produce the same MD5 digest. The lab computes both hashes in your browser using the same MD5 engine as Mission 1 — you can verify the result is real.

Objective: compute the MD5 of both collision inputs, confirm the digests match, then confirm you understand why this breaks MD5 for integrity.

Message A (different content)

MD5 of A:
not yet computed

Message B (different content)

MD5 of B:
not yet computed
Both MD5 digests are identical:
Two messages with different bytes hash to the same MD5. An attacker who can find a collision can substitute a malicious document that passes an MD5 integrity check. This is why MD5 must not be used for any security-relevant integrity check.

Reference: Wang & Yu (2004) "How to Break MD5"; Lenstra et al. (2005) chosen-prefix collision construction. SHA-256 has no known practical collision attack as of NIST SP 800-107r1.

Mission 3 — Salting and Password Storage

Hashing a password naively (even with SHA-256) is dangerous: rainbow tables pre-compute millions of common-password hashes. A random per-user salt defeats this. PBKDF2 (Password-Based Key Derivation Function 2, NIST SP 800-132) adds iterations to make each guess expensive. This lab uses real crypto.subtle.deriveBits with PBKDF2-SHA256, 200,000 iterations.

Objective: store the same password twice (producing different salted hashes), then verify a correct login and reject a wrong password.

User account 1

Salt (random, 16 bytes):
not yet generated
Stored PBKDF2 hash:
not yet generated

User account 2

Salt (random, 16 bytes):
not yet generated
Stored PBKDF2 hash:
not yet generated

NIST SP 800-132 recommends PBKDF2 with at least 600,000 iterations (SHA-256). This demo uses 200,000 for browser performance. Argon2id and bcrypt are also preferred options for new systems (memory-hard).

Mission 4 — HMAC: Keyed Integrity and Authenticity

A plain hash proves a message has not changed, but anyone can recompute it. HMAC (RFC 2104) wraps a hash with a shared secret key, producing a tag that requires the key to compute or verify. It provides both integrity (message not altered) and authenticity (came from someone who holds the key). This lab uses crypto.subtle.sign / verify with HMAC-SHA256.

Objective: compute an HMAC-SHA256 tag, verify it against the original message (pass), then verify against a tampered message (fail — forgery caught).
compute the tag first
Sender
Sends: original message + HMAC tag.
tag not yet computed
Receiver — verify original message
Recomputes HMAC with the shared key; compares tags.
Tampered message used: "Transfer $9,999 from acct 0482 to acct 9931 on 2024-12-01"

RFC 2104: HMAC-SHA256 is the standard for API authentication tokens, TLS record MAC, and S/MIME. Unlike a signature, both sides hold the same key (symmetric). HMAC does not provide non-repudiation (either party could have computed it).

Mission 5 — Capstone: Match Primitive to Requirement

You have operated each primitive. Now specify the right hash primitive for each real-world requirement. Wrong choices — MD5, SHA-1, raw SHA-256 for passwords, a plain hash for message authentication — fail the review. The engine evaluates your config; a single mismatched or weak choice blocks certification.

Objective: assign the correct primitive to every requirement. MD5, SHA-1, and raw-SHA256-for-passwords are traps. Only a fully correct config certifies.

Hash Deep-Dive — Certified

You operated MD5, SHA-1, SHA-256, and SHA-512 with real computation; witnessed a live MD5 collision; used PBKDF2 with random salts for password storage and verified a login; computed and broke HMAC-SHA256 to prove keyed authentication; and matched every requirement to the correct primitive with no weak links. That is the foundation of hashing as a security control.

Hashing · FIPS 180-4 PBKDF2 · SP 800-132 HMAC · RFC 2104 SY0-701 1.4