- #security
- #hashing
- #encryption
- #passwords
Hashing vs encryption: the difference that matters
Encryption is reversible and hashing is not, and that one difference decides how passwords should be stored. It also explains why a site that can email you your old password is a problem.

"Your password is encrypted." I see that line on signup pages and software pitches all the time, and it is usually a sign the person writing it does not know how passwords should be stored. Encryption is reversible by design. Password storage should never be reversible. The right word is hashed, and the difference is worth five minutes of your time.
One-way vs two-way
A hash function takes any input and produces a fixed-size fingerprint, with no way back. Run "hello" through SHA-256 and you get a 64-character string starting with 2cf24dba. Run "Hello" with a capital H and you get something completely different. Same input always gives the same output, but there is no key and no decrypt button. The original is gone.
Encryption is the opposite deal. You scramble data with a key, and anyone holding that key can unscramble it. AES-256 is the common standard. The whole point is that the data comes back out intact.
That gives you a rule of thumb that settles almost every argument:
- If you ever need the original back, encrypt it.
- If you only ever need to check a match, hash it.
Passwords get hashed, not encrypted
Here is the part most people miss. A website never needs your actual password again after you set it. It only needs to answer one question at login: does what you just typed match what you picked before? So a properly built site stores a hash. When you log in, it hashes what you typed and compares fingerprints. Your real password is never sitting in the database at all.
Two details matter in practice. First, plain SHA-256 is too fast for passwords. A single consumer GPU can guess billions of SHA-256 hashes per second, so short passwords fall fast. Password storage should use a deliberately slow algorithm like bcrypt or Argon2, which turns billions of guesses per second into thousands. Second, each password gets its own random salt mixed in, so two users with the same password end up with different hashes and precomputed lookup tables become useless.
Honest limit: hashing does not make a weak password strong. If your password is your dog's name plus the year, bcrypt just means the attacker cracks it in minutes instead of instantly. Hashing protects the storage, not the choice.
Encryption belongs in transit and at rest
Encryption is the right tool everywhere you need the data back.
In transit: when someone fills out the contact form on a dog groomer's site, their name and phone number travel across networks nobody controls. HTTPS, which is TLS under the hood, encrypts that trip so a stranger on the coffee shop wifi cannot read it, and the server decrypts it on arrival. Two-way is exactly what you want here, because the groomer has to actually read the message.
At rest: if a landscaper keeps a client list with addresses and gate codes on a laptop in the truck, disk encryption is what protects it when the truck gets broken into. That is BitLocker on Windows or FileVault on a Mac. The owner holds the key, so the data comes back for them and for nobody else.
Both tools show up in my own work. The password vault in my app has to give your passwords back to you, so it encrypts them on the device. That is a legitimate use of encryption for credentials, because retrieval is the entire point of a vault. A login system has no such excuse.
Why "encrypted passwords" is a red flag
If a company encrypts passwords instead of hashing them, a key exists somewhere that unlocks every password at once. Steal the database and the key, and the attacker has everything immediately. Steal a database of bcrypt hashes and the attacker has to grind each password individually, which buys users time to change them.
There is an easy test any salon or shop owner can run on their booking software. Click "forgot password." If the system emails you your actual old password, it is storing passwords reversibly or in plain text, and I would move my client data somewhere else. A proper system can only send a reset link, because it genuinely does not know your password. That is the good outcome.
This distinction comes straight out of my Security+ SY0-701 study notes, and eJPT prep is largely about finding places where someone got it wrong. I am still studying for both, so I drill this stuff almost daily. If you want to drill it too, the flashcards and quizzes I use are built into Aldo's Toolkit, free on both stores at /app, along with a daily question with streaks and that local-first password vault. No ads, no tracking.
community rating
$ ls ./comments
sign in or create an account to rate and comment.
no comments yet, be first.