Hash and salt
Websites shouldn’t store your password, only a scrambled fingerprint of it. Type a made-up password and watch what hashing and salting do, and why the way a site stores passwords decides how bad a data breach gets.
Practice for defenders. This lab trains the skills SOC analysts, incident responders and sysadmins use to protect systems. Everything runs in your browser. The companies, people, data and IP addresses are made up, and nothing here touches a real system. Only use security skills on systems you own or have written permission to test.
1. Hash it
SHA-256 turns any text into a 64-character fingerprint. The same input always gives the same hash, but you can’t run it backwards. Change one character and almost every character of the hash changes.
2. Salt it
Two people pick the same password. Without salt, their hashes match, so cracking one cracks both. A salt is a random value stored next to each hash that makes every hash unique.
3. How strong is it?
- Rough time to guess if a site used a fast hash like plain SHA-256
- …and if it used a slow password hash like bcrypt or Argon2
A rough estimate from length and character variety, assuming an attacker with a stolen database and a modern graphics card. Real guessing starts with common passwords, so anything on those lists falls instantly.
What defenders do
- Store passwords with a slow password hash: bcrypt, scrypt or Argon2. Plain SHA-256 is far too fast for passwords; it’s used here only to show the idea.
- Give every password its own random salt. Good password-hashing libraries do this for you.
- Turn on multi-factor sign-in, so a guessed password alone isn’t enough.
- As a user: one long, unique password per site, kept in a password manager.