"If the system stores my password encrypted, someone with the key can read it." The sentence sounds reasonable, but it starts from a basic error: in a well-built service, your password isn't encrypted, it's hashed. And that difference —one word almost nobody distinguishes— completely changes what can and can't be done with it. Let's start at the beginning.
What a hash is
A hash is the result of running data through a hash function: a mathematical operation that condenses any input into a short, constant-length string. It doesn't matter whether you feed it a single letter or an entire book; the output is always the same size.
A hash function takes an input of any size and returns a fixed-size string —the hash or digest—. With SHA-256, for example, the output is always 256 bits, no matter what you type.
Three properties define it: it's deterministic (the same input always yields the same hash), it's one-way (you can't go back from the hash to the input), and a tiny change in the input changes the hash entirely (one extra comma and the result is unrecognizable).
That last property is what makes a hash useful: since a single different character produces a completely different hash, comparing two hashes is a cheap, reliable way to know whether two inputs are identical —without comparing them byte by byte—.
Hash vs encryption: the key difference
Here's the heart of the misunderstanding. Encryption and hashing look alike because both turn data into something unreadable, but they exist for opposite purposes.
Encryption is reversible. Its purpose is to protect something you later need to read: you store an encrypted file and, with the right key, you recover the exact original. Without that "way back", encryption would be pointless.
A hash is irreversible by design. There's no "key" that reverts it, because information is deliberately lost during the process. Its purpose isn't to hide-then-recover, but to produce a fingerprint you can recompute and compare. A hash isn't "decrypted" because it was never encrypted.
| Feature | Hash | Encryption |
|---|---|---|
| Reversible? | No | Yes, with the key |
| Uses a key? | No | Yes |
| Output size | Fixed | Depends on the input |
| What it's for | Fingerprint, verification | Confidentiality |
Why passwords are stored hashed
With that clear, the correct practice explains itself. A serious service never stores your password as-is —not even encrypted—: it stores its hash.
When you log in, the system takes what you typed, hashes it with the same function and compares that hash with the one it had stored. If they match, you typed the right password; it never needed to know the original. So even if an attacker steals the entire database, they don't get the passwords: just a pile of irreversible fingerprints.
Hence a consequence many people read backwards: when a site tells you it "can't recover your password, only reset it", that's not an annoying limitation —it's a good sign—. It means it doesn't have it, only its hash.
Salt: why two equal passwords don't look the same
Hashing the password solves a lot, but leaves one flank exposed. Because hashing is deterministic, two users who chose the same password would have exactly the same hash in the database. And since common passwords repeat a great deal, there are precomputed tables —rainbow tables— that already store the hash of millions of typical passwords, ready to revert at a glance.
The salt is a random value, unique per user, added to the password before hashing. Since each user has a different salt, two equal passwords produce different hashes, and precomputed tables stop working: you'd have to rebuild them for every possible salt.
The salt isn't secret —it's stored alongside the hash—; its value lies in being unique. It turns a cheap, mass attack into one you have to repeat user by user, which is exactly the point.
Common mistakes
"I forgot my password, email it to me." If a site can send you your original password, it stores it recoverably —encrypted or in plain text—, and that's a bad sign. A correct site can only let you reset it, because there's no way back from its hash.
Beyond that classic, these are the recurring slip-ups:
- Using a fast general-purpose hash (like SHA-256) for passwords. SHA-256 is designed to be fast, and that speed helps the attacker try millions of candidates per second. For passwords you use slow hashes purpose-built for it —bcrypt, scrypt, Argon2—, which deliberately make each attempt expensive and resist brute force.
- Hashing without salt. It leaves the door open to precomputed tables and reveals which users share a password.
- Confusing "hashing" with "encrypting" when designing a system, and ending up storing passwords recoverably while believing they're protected.
The other use: verifying integrity
Passwords are only half the story. The hash has a second, equally important use: checking that a file didn't change.
If you compute a file's hash before sending it and whoever receives it computes the hash of what arrived, you just compare: if the two hashes match, the content is identical; if a single byte changed —a corrupt download, tampering—, the hash doesn't match and it shows instantly. That's exactly what checksums and integrity verification in file transfer do.
The banking angle
In banking the two uses of the hash intersect daily, on two distinct fronts:
- Credential storage. Online banking and internal-system passwords are stored with a slow hash and salt, never in plain text nor recoverably encrypted. It's a baseline requirement of any security audit.
- Batch integrity. The files exchanged between institutions —payment batches, reconciliations— travel with a hash of the content: on receipt, the counterparty recomputes the hash and confirms the batch arrived unaltered. It's the same integrity principle that underpins a transfer over SFTP.
Encryption and hashing are not interchangeable. One protects so you can read later; the other produces a fingerprint that never reverts. Using one where the other belongs —encrypting a password that should be hashed, or "expecting to recover" a hash— is one of the most expensive and frequent security mistakes there is. And it almost always starts with believing they're the same thing.
