TL;DR: Encoding (Base64, URL encoding) changes representation and has no key, so it provides no security. Encryption hides content and is reversible with a key. Hashing is a one-way fingerprint with no key, used to detect change against a trusted reference and, with slow functions, to store passwords. Signing proves who produced data and that it is unchanged: a private key signs, a public key verifies. Pick by the property you need: confidentiality means encryption; integrity and origin mean signing (or a MAC); format means encoding.
How to approach it
Organise the answer around keys. Encoding has none, hashing has none, encryption uses a key to reverse, and signing uses a private key to create and a public key to verify. Then give one use for each, and the classic misuse for each.
A strong answer
Encoding
Base64, URL encoding
- No key, fully reversible
- Representation only: zero security
Encryption
AES-GCM, RSA-OAEP
- Key required to reverse
- Confidentiality; with AEAD also integrity
Hashing
SHA-256, Argon2id
- No key, one-way
- Detects change against a trusted reference
Signing
ECDSA, Ed25519
- Private key signs, anyone verifies
- Integrity plus origin
| Operation | Reversible? | Key? | Protects | Typical use | Classic misuse |
|---|---|---|---|---|---|
| Encoding (Base64, hex, URL) | Yes, by anyone | No | Nothing | Putting bytes into text formats such as JSON or URLs | Treating a Base64 "token" or "obfuscated" secret as protected |
| Encryption (AES-GCM, TLS) | Yes, with the key | Yes | Confidentiality (AEAD also integrity) | Data in transit and at rest | Keeping the key next to the data |
| Hashing (SHA-256; Argon2id for passwords) | No | No | Integrity against a trusted reference | File checksums, content addressing, password storage with slow functions | Fast hashes for passwords; trusting a hash served next to the file it checks |
| Signing (Ed25519, ECDSA) | Not applicable (verifies) | Key pair | Integrity, authenticity, non-repudiation | Code and model signing, certificates, signed tokens | Verifying with a public key fetched from an untrusted place |
Three points separate a strong answer:
- Encoding is not security. A JWT's payload is Base64url-encoded, not encrypted; anyone can read it. Security comes from its signature.
- A hash proves integrity only relative to something trusted. A hash published on the same compromised server as the file proves nothing. For keyed integrity between two parties, use a MAC such as HMAC; for verifiable origin, use a signature.
- Signing does not hide anything. A signed message is readable. If you need confidentiality and origin, you encrypt and sign (or use a protocol such as TLS that does both).
AI example. A model artifact pulled from a hub: the download travels over TLS (encryption in transit), the file is checked against a hash in a manifest (integrity), and the manifest is signed by the publisher (origin). Each step answers a different question.
What interviewers probe next
- "Is a JWT encrypted?" Usually not: a signed JWT (JWS) is readable by anyone; only an encrypted JWT (JWE) hides its contents.
- "Why not SHA-256 for passwords?" It is designed to be fast, which helps attackers test guesses; use a slow, salted, memory-hard function such as Argon2id.
- "What does HMAC add over a hash?" A secret key, so only key holders can produce a valid tag.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A developer stores customer API tokens Base64-encoded in a database column and says they are 'encrypted'.
Start here
Why is Base64 not encryption?
What secret is needed to decode Base64?
Encoding changes representation and has no key, so anyone can reverse it instantly. Base64 tokens in a leaked database are plaintext tokens. Encoding is for transport and formatting, never for security.
Carry it forwardEncoding has no key and gives no security.
Weak answerCalling encoded data protected.
Constraint changes
What does encryption provide?
Where would the key be stored?
It hides content and is reversible with a key. Protection then depends on where the key lives: if it sits next to the data or in the application config that leaks with it, encryption helps little.
Carry it forwardEncryption is only as good as key separation.
Weak answerEncrypting with a key stored in the same table.
Constraint changes
Would hashing the tokens be better?
Does the service need the original token back?
If the service only needs to verify tokens presented to it, yes: store a hash and compare on use, so a leak does not reveal usable tokens. If it must send the tokens to a third party, it needs encryption instead.
Carry it forwardHash what you verify; encrypt what you must reuse.
Weak answerEncrypting tokens that only need verification.
Constraint changes
Where does signing fit?
Does a signature hide the content?
Signing proves who produced data and that it is unchanged: a private key signs, a public key verifies. It does not hide anything, so it suits tokens or messages whose integrity and origin matter, not secrecy.
Carry it forwardSignatures prove origin and integrity, not secrecy.
Weak answerUsing signatures for confidentiality.
Constraint changes
What would you recommend for these tokens?
Which kind of tokens are they?
If they are tokens your service issues and verifies, store salted or keyed hashes. If they are third-party tokens you must use, encrypt them with envelope encryption and keys in a KMS, restrict decryption to the service and rotate them.
Carry it forwardChoose the primitive by what the system needs.
Weak answerOne primitive for every case.
Now defend it
How would you explain and fix it?
Base64 is encoding, not protection. For tokens the service verifies, store keyed or salted hashes; for third-party tokens it must use, encrypt with KMS-managed keys and restricted decryption; use signatures only where integrity and origin matter; and rotate the exposed tokens.
How it's scored
Weak: Calls Base64 encryption or hashing "encryption that can't be reversed"; confuses signing with encrypting.
Hire: Distinguishes all four by keys and reversibility, gives one correct use each.
Strong Hire: Names the classic misuse of each, explains that hashes need a trusted reference, and combines them correctly in one realistic flow.
Common mistakes
- Saying data is "encrypted with SHA-256".
- Treating Base64-encoded secrets in config files as protected.
- Assuming a signature provides confidentiality.
- Forgetting MACs exist between hashes and signatures.