Hashing

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).

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.

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.

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.

# Create a tiny file YOU own, then hash it (OpenSSL installed)
echo Cyberlium hash lab > file.txt

# Linux / macOS / Windows (OpenSSL in PATH)
openssl dgst -sha256 file.txt

# Change one character, hash again — digest should fully change
echo Cyberlium hash Lab > file.txt
openssl dgst -sha256 file.txt

# Compare two downloads later:
# 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)

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.