Separate encoding, hashing, and encryption

Base64 is not encryption. A hash is not a way to hide data you need to recover later. Mixing these up is one of the most common security mistakes in real codebases.

Three different operations, three different jobs:

• Encoding changes representation so data survives a channel. Anyone can reverse it. No key, no secret.
• Hashing produces a fixed-size fingerprint and is designed to be one-way. Same input, same output, no way back.
• Encryption protects confidentiality using a key, and modern encryption must also protect integrity, so nobody can silently modify the ciphertext.

See the difference

echo -n "customer record" | base64
# Y3VzdG9tZXIgcmVjb3Jk        <- reversible by anyone

echo -n "customer record" | shasum -a 256
# 6cc3c... a fixed-size fingerprint, one-way

The Base64 output looks scrambled, which is exactly why it fools people. Scrambled-looking is not protected.

The mislabeled backup

A backup tool Base64-encodes customer records and labels the result encrypted. Anyone who downloads the file can decode it without a key — one base64 -d away from every record. The label created false confidence, which is worse than no protection, because nobody adds real encryption to something already marked “encrypted.”

The other two operations would also be wrong here. Hashing the backup would prevent recovery: you cannot restore customers from fingerprints. Encryption without integrity could allow silent changes to the ciphertext. The correct operation follows the security goal we started with — recoverable confidentiality with tamper detection, which means authenticated encryption.

Pick by goal, not by function name

Classify by asking what you need afterwards:

need                               operation
send binary data inside JSON       encoding (Base64)
detect file corruption             hash (checksum)
check passwords at login           password hash (bcrypt/argon2, slow on purpose)
store data we must read back       authenticated encryption

Passwords get a special row. They use dedicated slow hashes, never plain SHA-256 and never encryption — you should be unable to recover a user’s password even with every key you own.

Take a session token, a file checksum, a password record, and a recoverable backup from your own system and classify each by goal and operation. Then decode the encoded one, alter one byte of the protected one, and record which checks detect the change.