Hashing, made tangible.
Change one character. Compare the fingerprints. See why unique salts matter. Three hands-on experiments turn a core security concept into something you can explain.
One word. Three different security decisions.
A cryptographic hash maps input data to a fixed-length digest. It is useful for comparing data, but hashing alone does not prove who supplied a file - and fast SHA-256 is not a password-storage scheme.
Compare a trusted digest.
A changed input produces a changed SHA-256 digest. Compare against a trusted expected value to detect alteration.
Same rules for every input.
Each line below is hashed independently. Identical inputs produce identical unsalted SHA-256 outputs.
Slow down guesses.
Real password storage needs a unique salt and an appropriate, costly password-hashing scheme - not SHA-256 alone.
Change one character. Watch everything move.
Compare password with Password, then try your own sample words. A small input change should produce a substantially different digest.
Comparing the two digests...
A digest is deterministic: identical input gives identical output. A changed digest flags a difference, but it does not identify who made the change or authenticate the source.
One line in. One fingerprint out.
Hash sample values one per line. Change one item and compare again. This demonstrates fast digest generation, not a safe password database.
- Run the sample to see each digest.
Without a salt, the same input has the same digest wherever it appears. That is one reason a plain fast hash is a poor choice for stored passwords.
Same sample. Different salt. Different result.
Both users begin with the same sample word. Compare two illustrative salt values, then generate a fresh one for User B.
For actual password storage, use a unique random salt with a password-hashing scheme designed to make offline guesses costly, such as Argon2id (or an appropriate alternative). Store the salt and algorithm parameters alongside the resulting verifier.
The interview-ready distinction.
When someone says "hash it," ask what problem they are solving. Integrity checking and password verification are related - but not interchangeable - jobs.
Compare to a trusted expected hash.
Compute a digest such as SHA-256 for the file and compare it with a trusted value from a reliable source. A match supports integrity; it does not by itself authenticate the publisher.
Use a salted, costly password hash.
Use a suitable scheme such as Argon2id with unique salts and tuned cost parameters. Do not store passwords as SHA-256(password).
From concept to capability.
Apply the same decision-making habit in another Sec Guy lab, then turn the result into a story you can explain.
Explore Experience BuilderTechnical references: OWASP Password Storage Cheat Sheet | NIST SP 800-63B. This educational lab runs locally in the browser using Web Crypto; it is not a credential-handling service.