Servers must keep your credentials safe. Here are three common approaches — and what a hacker actually sees.
Type anything below and watch what happens to the numbers.
Try typing "ab" and then "ba" — do you get the same number? That's a clue!
Can you still find the pattern?
Don't be disappointed if you can't see a pattern in the SHA-256 box! That's actually a good thing — real hash functions (like SHA-256) are designed to look completely random. They turn any message into a fixed-length scrambled string (64 hex characters).
Hashes are also one‑way streets: you can't go backward from the hash to the original password, and you can verify this above. And unlike the easy hash above, good hashes make sure different inputs almost never produce the same output.
Now let's see what happens when servers store passwords using different methods.
In this format, passwords are stored without additional encryption or hashing. The server saves the password exactly as the user typed it.
Here, the server runs each password through a hash function (SHA‑256) and stores only the hash. Since hashes are collision-resistant, servers can check authenticity by hashing an entered password, then comparing it with what is stored.
A unique random list of characters (a salt) is added to each password before hashing. The server stores both the salt and the hash(salt+password).
Test how each method stores a password
[plaintext]
[direct hash]
[salted hash]
Notice: with salted hash, the same password gives a completely different result each time the salt changes.
Testing which storage method is most secure by seeing exactly what an attacker discovers after breaking into the database. Each scenario below shows the same breached data, but the damage varies dramatically.
The database stores passwords as plain text. The attacker sees every password immediately, and can log in as any user without any cracking effort.
| user | password (plaintext) | |
|---|---|---|
| alice | alice@bank.com | ilovecats123 |
| bob | bob@bank.com | password1 |
| charlie | charlie@bank.com | qwerty2024 |
The server stores hashes. Because the same password always produces the same hash, attackers use precomputed rainbow tables — massive databases mapping common passwords to their hashes — to reverse them instantly.
| user | SHA-256 hash |
|---|---|
| alice | loading... |
| bob | loading... |
| charlie | loading... |
Try to crack a hash using a rainbow table simulation
🌈 rainbow table snippet (hash prefix → common password)
Without salt, identical passwords create identical hashes → attackers just look them up.
Each user has a unique random salt. The hash is computed from salt+password. Even identical passwords produce completely different hashes across users, so precomputed rainbow tables cannot work because the salt changes the hash entirely. Hence, salted hashes, like bcrypt or Argon2, are the modern standard.
| user | salt | hash(salt+password) |
|---|---|---|
| alice | x9f2k | loading... |
| bob | m3p7q | loading... |
| charlie | w1z8r | loading... |
Try to guess a password (now near impossible)
Even if you know the correct password, the salt changes the stored hash. An attacker would need to brute-force each user individually — which is extremely expensive.