Hashing is not encryption
One way stamps for passwords, reversible locks for files. Unix got this right in /etc/shadow.
People say “encrypted password” when they mean a hash. They are different tools. Mixing them up is how you get a database that can be unwound, or a backup you cannot read on purpose.
Encryption is a lock with a key
You scramble data with a key. You unscramble with the same key (symmetric) or with a matching private key (asymmetric). The point is reversibility. Disk encryption, HTTPS, a zip with a password: someone with the key gets the original bytes back.
If you encrypt the password file and the web server needs the key to check logins, the key sits next to the file. An attacker who takes the disk takes both. Encryption of passwords at rest is not the same as doing it right.
Hashing is a one way stamp
A hash takes any input and spits a fixed size string. You cannot walk it backwards in any useful way if the hash is slow and salted. When you log in, the site hashes what you typed and compares stamps. It does not store the password.
Salt means each password gets a unique extra string before hashing, so two people with “password1” do not look the same in the dump. Slow hashes (bcrypt, scrypt, argon2) make guessing expensive. Fast hashes (plain SHA256 on the password alone) make guessing cheap. The old MD5 password table is a museum of that mistake.
What to do with this
- Sites should hash passwords, not encrypt them.
- You should not “decrypt” a password. You reset it.
- File vaults and HTTPS are encryption. Login storage is hashing.
- If a breach notice says they stored passwords in plain text, believe them and change every reuse of that string.
This distinction is older than the web. Unix stored hashes in `/etc/shadow` for a reason. The reason still holds.