Hashing
One-way fingerprints for integrity
Encryption unlocks. Hashing does not.
Symmetric and asymmetric crypto are two-way with keys. Hashing is a one-way digital fingerprint. Same input → same hash. Tiny change → totally different hash (avalanche). There is no "decrypt hash" button. That is why download pages publish SHA-256 checksums — and why password storage is a specialized hashing problem, not a place for raw SHA-256 alone.
1. What a hash is
A cryptographic hash function maps any-size input to a fixed-length digest. SHA-256 produces 256 bits (shown as 64 hexadecimal characters). Good hashes are deterministic, one-way in practice, and collision-resistant enough that finding two different inputs with the same digest is infeasible for attackers.
Hashing is not encryption. Encryption hides data so an authorized key can reveal it later. Hashing creates a fingerprint so you can compare or verify — you do not get the original bytes back from the digest. If you need to read a contract next month, encrypt (or keep the file). If you need to detect tampering or compare secrets without storing them in plaintext, hash (with the right construction).
- Deterministic: Identical file → identical digest every time.
- Avalanche effect: Change one bit → digest looks unrelated.
- Not encryption: No key to reverse it. Need recoverability later → encrypt, do not only hash.
2. Integrity: verifying downloads and files
Publishers post SHA-256 (or similar) digests so you can confirm an installer or firmware image was not corrupted or swapped in transit. You compute the digest locally and compare character-for-character. A one-character mismatch is a hard stop — Integrity in the CIA Triad. This lesson's lab uses openssl dgst for exactly that ethical check on files you own.
3. Password storage: salt, KDFs, and why raw SHA-256 fails
Servers should never store user passwords in plaintext. On login they should transform the typed password and compare against a stored verifier. But "just SHA-256 the password" is a classic amateur mistake. Fast general-purpose hashes were designed for integrity and speed — attackers love speed. With GPUs and huge wordlists, billions of SHA-256 guesses per second are realistic against unsalted password hashes.
Salt: a unique random value stored beside each password hash and mixed into the hash input. Salt does not need to be secret like a key; its job is uniqueness. Without salt, every user who chose "Summer2024!" produces the same digest. Attackers precompute rainbow tables (huge dictionaries of password → hash) once and crack many accounts instantly. With a unique salt per user, those tables stop working — each password must be attacked separately.
Key Derivation Functions (KDFs) for passwords — bcrypt, scrypt, Argon2 — go further. At a concept level they are intentionally slow and/or memory-hard: each guess costs the attacker real time and RAM, not a free GPU sprint. Argon2 (winner of the Password Hashing Competition) and bcrypt/scrypt are the family names you will see in secure frameworks. Professionals say: use a password KDF with unique salts (and modern parameters), never raw SHA-256/MD5 as your password "encryption." Also: password reset flows replace forgotten passwords — admins should not be able to email you the old one.
- Unsalted fast hash: Same password → same digest; rainbow tables and mass cracking thrive.
- Salted hash: Unique random salt per user breaks precomputed tables; still too fast if the hash is SHA-256 alone.
- Password KDF (bcrypt / scrypt / Argon2): Slow/memory-hard by design so guessing each password hurts the attacker's budget.
4. Wrong vs right: unsalted password hashes
Worked failure mode — "we store SHA-256(password), we're fine":
- Wrong: A startup hashes every password with raw SHA-256 and no salt. A database leak dumps digests. Attackers run rainbow tables and GPU wordlists; reused and common passwords fall in minutes. Admins who also stored reversible "encrypted" passwords so they can "email it back" make it worse.
- Right: Store a unique salt + a password KDF output (bcrypt/scrypt/Argon2 via a vetted library). On login, recompute and compare. Offer reset links, never recoverable plaintext passwords. Separately: keep files, encrypt backups for confidentiality, and use SHA-256 digests to detect tampering — hashing for verify/compare, encryption for hide/reveal.
5. Practical: local openssl digest (ethical lab only)
Run these only on files you own, on your own machine. Do not hash or attack other people's data. This lab is for file integrity (avalanche effect), not for inventing a password storage scheme by hand.
Command guide
openssl SHA-256 — local integrity demo only
Create a tiny file YOU own under cyberlium-lab, then hash it Linux / Kali / macOS
Command — copy this
mkdir -p "$HOME/cyberlium-lab" cd "$HOME/cyberlium-lab" echo Cyberlium hash lab > file.txt openssl dgst -sha256 file.txt
Change one character, hash again — digest should fully change
Command — copy this
echo Cyberlium hash Lab > file.txt openssl dgst -sha256 file.txt
Windows PowerShell (prefer Get-FileHash; openssl if on PATH)
Optional command
New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\cyberlium-lab" | Out-Null Set-Location "$env:USERPROFILE\cyberlium-lab"
"Cyberlium hash lab" | Out-File -Encoding ascii file.txt
Optional command
Get-FileHash .\file.txt -Algorithm SHA256 openssl dgst -sha256 file.txt
Compare two downloads later:
Optional command
openssl dgst -sha256 installer.iso
Match the publisher's published SHA-256 exactly — or do not trust the file.
Password storage reminder (concept — use libraries, not DIY): BAD: SHA-256(password) with no salt GOOD: unique salt + bcrypt / scrypt / Argon2 (framework defaults)
Mission: watch the avalanche
On your own PC, create file.txt, run openssl dgst -sha256 file.txt, change one letter, hash again. Write both digests side by side and note they differ wildly. Then write one sentence: "I would not store passwords as raw SHA-256 because ___ (speed / rainbow tables / no salt)." Delete the practice file if you want.
Stuck? Ask Cyberlium AI Mentor
Unsure when to hash vs encrypt, or why salt beats rainbow tables? Ask Cyberlium AI Mentor for a hint — not a password-cracking walkthrough. Try: "Hint only: I need to read the file next month — hash or encrypt?" Or: "Hint only: why is salted Argon2 better than SHA-256(password)?"
You now treat hashing as one-way integrity tooling, you understand salt and password KDFs at concept level, and you can run a safe local SHA-256 check. Next — HTTPS, SSL, and TLS — encryption in transit with the browser padlock.
APPLY: Fundamental difference between encryption and hashing?
APPLY: Why is storing unsalted SHA-256(password) a bad password design?
APPLY: You download firmware; the vendor lists SHA-256. Your openssl dgst result differs by one character. What should you do?