Cryptoencodinghashingencryptionbase64misconceptions

Hashing vs Encryption vs Encoding

Encoding is reversible without a secret, hashing is one-way, encryption is reversible with a key — three different tools that are routinely confused, and the confusion produces real vulnerabilities.

▶ Run the labFollow the failure

Frame the problem

Security starts with a concrete asset, attacker capability and trust crossing.

Asset
The correctness of the protection you believe you applied.
Attacker & capability
Anyone who notices that "encrypted" data is base64, or that a "hashed" value can be reversed.
Trust boundary
Between representation, integrity and confidentiality.
Asset→Threat→Attack Surface→Trust Boundary→Vulnerability→Exploit Path→Impact→Mitigation→Defense in Depth→Residual Risk

Three operations

Base64 in a token is not protection; a URL decoder in a browser tab reverses it. A hash of a phone number is reversible by hashing every phone number — hashing only hides *high-entropy* input. Encryption with the key in the same config file as the ciphertext protects against nothing that has the config file.

The comparison that prevents a class of bugs
EncodingHashingEncryption
PurposeRepresent data in another formFingerprint data; one-wayHide data from those without the key
Reversible?Yes, by anyoneNoYes, with the key
Needs a secret?NoNo (a salt is not a secret)Yes — the key
ExamplesBase64, URL-encoding, hexSHA-256, Argon2 (password)AES-GCM, ChaCha20-Poly1305
ProvidesNothing security-wiseIntegrity check; password verificationConfidentiality (+ integrity if authenticated)
Common misuse"Encrypted" tokens that are base64Fast hashes for passwords; hashing low-entropy dataKey stored next to the data; unauthenticated modes

Choosing

Need to transport bytes safely in text? Encode. Need to verify a password or detect modification of something you also hold? Hash (slow hash for passwords, keyed MAC if the attacker could rewrite the hash too). Need to read the data back later and keep others out? Encrypt, authenticated, with the key in a separate system.

Key points

  • Encoding provides no security.
  • Hashing hides only high-entropy input; hashing an email is not anonymisation.
  • Encryption protects only against parties without the key — so where the key lives is the whole question.
  • "Encrypt the password" is a red flag; passwords are hashed.

Boundary control exercise

This lesson uses the shared boundary-control exercise.

Boundary control check
Untrusted input / identity
→
Trust boundary
→
Privileged asset
Prevention may fail silently.

Follow the attack

Safe conceptual simulation: capability → missing control → crossed boundary → asset impact.

  1. 1
    Attacker → decode the "encrypted" token; or enumerate the domain of a hashed low-entropy value; or find the key beside the data.
Blast radius
  • Protection that was believed to exist did not; data is effectively plaintext.

Defend, detect, recover

One prevention is a single point of security failure. Layer it and make failure observable.

Prevent
  • • Name the property needed; pick the operation that provides it.
  • • Keys in a key-management system, not config.
  • • Slow hashes for passwords; MAC when an attacker could rewrite the hash.
Detect
  • • Review for base64 called "encryption"; hashes of identifiers used as anonymisation.
Respond & recover
  • • Treat the data as exposed; re-protect properly.
Residual risk
  • • Correct primitives still fail with wrong key handling.
← Cryptography FundamentalsSymmetric Encryption →