A fingerprint, not a locked box#
Two things people call "scrambling" are doing completely different jobs.
Encryption is a locked box. You put something in, lock it, and later you unlock it and get the original back. The whole point is that it reverses. If it could not be reversed it would be useless, because nobody could read the message.
Hashing is a fingerprint. You can take a fingerprint from a person in seconds. You cannot take a fingerprint and rebuild the person. A hash function is a calculation that turns any amount of data into a fixed-length string, and there is no matching calculation that runs backwards.
That one-way property is not a limitation somebody forgot to fix. It is the entire feature.
| Encryption | Hashing | |
|---|---|---|
| Reversible? | Yes, with the key | No, by design |
| Output length | Grows with the input | Always the same, whatever goes in |
| Needs a key? | Yes | No |
| Serves which goal? | Confidentiality | Integrity |
| Used for | Messages, files, traffic in transit | Passwords, file verification, signatures |
Why passwords are hashed and not encrypted#
Here is the question that makes it click. If a website encrypted your password, the site would need the key to check it at login. The key lives on the server. An attacker who takes the database takes the server, and therefore takes the key, and therefore gets every password in plain text.
Hashing removes the key from the problem entirely:
- You set a password. The server hashes it and stores only the hash. It does not keep your password at all.
- You log in. The server hashes what you just typed and compares the two hashes.
- They match, so you are in. The server still does not know your password.
This is why a site that can email you your existing password has told you something alarming about itself. To send it, they must be able to recover it, which means they did not hash it.
"Reset your password" is normal and safe. "Here is your current password" means it was stored reversibly.
What a salt actually stops#
Hashing alone has a weakness, and it comes from the thing that makes hashes useful: the same input always produces the same output. Hash the password Summer2026! and you get a specific string. Everyone who chose that password has the identical string sitting in the database.
So an attacker does not have to reverse anything. They precompute the hashes of millions of common passwords once, store the results in a lookup table called a rainbow table, and then just look up your stolen hash. No cracking, only searching.
A salt is a random value generated per user, added to the password before hashing, and stored alongside the hash in the clear. It does not need to be secret. It needs to be different.
| User | Password | Salt | Stored hash |
|---|---|---|---|
| ana | Summer2026! | 7f3a... | completely different |
| ben | Summer2026! | c018... | completely different |
Two things follow, and the exam tests both:
- Precomputed tables stop working. A rainbow table would have to be built separately for every salt, which defeats the point of building one.
- Identical passwords stop looking identical. An attacker can no longer scan the stolen database and see that four hundred accounts share one hash, which used to point straight at the most common password.
A salt does not stop someone attacking a single account by guessing. It makes them do that work per user instead of once for everybody.
Fast hashes and password hashes are different tools#
Most hash functions are built to be fast, because verifying a downloaded file should not take ten seconds. For passwords, speed is the enemy: fast hashing means an attacker with your stolen database can try billions of guesses an hour.
So there are two families, and using one where the other belongs is a real finding in an audit:
- General-purpose hashes such as SHA-256. Fast, correct for file integrity and digital signatures. Wrong for passwords on their own.
- Password hashing functions such as bcrypt, scrypt, Argon2 and PBKDF2. Deliberately slow, and tunable so they can be made slower as hardware improves. This deliberate slowing is called key stretching.
Two older names come up as wrong answers you need to recognise. MD5 and SHA-1 are broken for security purposes, because practical collisions have been produced. A collision is two different inputs that hash to the same value, which destroys the guarantee that a matching hash means matching data.
HMAC is a hash with a secret key mixed in. A plain hash proves data was not altered by accident. An HMAC proves it was not altered by anyone who lacks the key.
Where hashing shows up on the exam#
Beyond passwords, three uses account for most questions:
- File integrity. A download page publishes a checksum. You hash the file you received and compare. Matching means the bytes arrived intact.
- Digital signatures. The signer hashes the document and encrypts the hash with their private key. Anyone can verify with the public key, which proves both integrity and who signed it.
- Forensics. An investigator hashes a drive image before and after analysis. Matching hashes prove the evidence was not altered while it was examined.
Note what the signature example is doing: it hashes first, then encrypts the small hash rather than the whole document. That is faster, and it is why integrity and confidentiality so often appear together in one mechanism without being the same thing.
Encryption is meant to be undone and hashing is not, so if the scenario needs the original back it is encryption, and if it only needs to prove nothing changed it is a hash.
Test yourself in the free Kestrel Exams app
Topic-selectable practice — offline, no ads, no account.
Practice this topic →Frequently asked questions#
What is the difference between hashing and encryption?
Encryption is two-way: with the correct key you recover the original data, and it protects confidentiality. Hashing is one-way: it produces a fixed-length fingerprint that cannot be turned back into the input, and it protects integrity. Encryption needs a key, hashing does not.
What does a salt actually protect against?
A salt is a random per-user value added before hashing. It stops precomputed rainbow table attacks, because a table would have to be rebuilt for every salt, and it stops identical passwords producing identical stored hashes. It does not stop an attacker guessing at a single account, it only forces that work to be repeated per user.
Does a salt need to be kept secret?
No. Salts are normally stored in the clear next to the hash, and the scheme still works. What matters is that each user gets a different random salt. A secret value added to a password is called a pepper, and it is a separate idea stored apart from the database.
Why is SHA-256 not recommended for storing passwords?
Because it is fast, and speed helps the attacker. A stolen database hashed with SHA-256 can be attacked at enormous guess rates on ordinary hardware. Password hashing functions such as bcrypt, scrypt, Argon2 and PBKDF2 are deliberately slow and tunable, which is called key stretching.
What is a hash collision?
Two different inputs that produce the same hash output. Collisions destroy the guarantee that a matching hash means matching data, which is why MD5 and SHA-1 are no longer acceptable for security purposes: practical collisions have been demonstrated for both.
Something here not clear? A topic you wish we covered? Tell us. We read every message, and a request is the fastest way to get a guide written — several of these exist because somebody asked.