Cryptography › Module 1 › Lesson 3
Password Hashing & Salting
Store passwords with salts and slow hashes so stolen databases are harder to crack
Opening
Databases leak. Plan for that day.
If an app stores passwords as plain SHA-256 of the password alone, attackers with a stolen database can try billions of guesses offline—especially against common passwords. Salting and slow password hashes raise the cost of every guess.
1. Why Raw SHA-256 Is Not Enough for Passwords
General-purpose hashes like SHA-256 are fast by design. Attackers love speed: GPUs can try enormous password lists quickly. Password hashing algorithms (bcrypt, scrypt, Argon2, PBKDF2) are intentionally slow and/or memory-hard so offline cracking hurts.
2. What a Salt Does
Unique per user
Same password → different stored hash for Alice and Bob.
Breaks rainbow tables
Precomputed “password → hash” tables stop working across users.
Stored beside the hash
Salts are not secret like keys; they just must be unique and random.
Conceptual salted hash (demo only — use bcrypt/Argon2 in real apps)import hashlib, os password = b"correct-horse" salt = os.urandom(16) digest = hashlib.sha256(salt + password).hexdigest() print(salt.hex(), digest)
import hashlib, os password = b"correct-horse" salt = os.urandom(16) digest = hashlib.sha256(salt + password).hexdigest() print(salt.hex(), digest)
Use a library, not a blog snippet
In production, call a vetted password hasher (e.g., Argon2id / bcrypt) via your language’s standard security library. Do not invent your own.
Knowledge Check
A salt’s main job for password storage is to:
Multiple choice
Knowledge Check
True or False: Fast general hashes alone are ideal for storing passwords.
True or False
Knowledge Check
Modern password storage should prefer:
Multiple choice