androidinterview.com

Android System Design Interview Questions

What is the difference between hashing, encrypting and encoding?

Tier: CommonDifficulty: Easy

The difference is whether the transformation can be reversed, and if so, who's allowed to reverse it.

  • Encoding changes the format of data so a different system can read it, and it's meant to be reversed by anyone, no secret required. Base64 turning binary image data into ASCII text for a JSON payload is encoding. Decoding it back is a public, documented operation.
  • Encrypting transforms data so it can only be read back by someone holding the right key. It's reversible, but only with that key. This is what you use for data you need to get back later in its original form, a token stored on disk, a message in transit.
  • Hashing is one-way. It produces a fixed-size digest from any input, and there's no key that turns the digest back into the original data. The same input always produces the same digest, which is what makes it useful for checking that data hasn't changed.

One thing to state carefully, because interviewers listen for it. Collisions have to exist. The digest is a fixed size and the input isn't, so there are more possible inputs than there are digests. What a good hash guarantees is not that collisions are impossible, it's that finding two inputs with the same digest is computationally infeasible. That's precisely what MD5 and SHA-1 stopped guaranteeing, so they're finished for anything security related and survive only as checksums against accidental corruption. Reach for SHA-256 or better.

A bare hash proves data didn't change, not who sent it. If the question is whether a payload really came from your server, the answer is an HMAC, a hash with a shared secret key mixed in, so only a holder of that key could have produced the tag.

The password case is the one that trips people up. You never encrypt a password, because encryption implies someone somewhere can decrypt it back to plaintext, and a password should never exist in plaintext again after the user sets it. So you hash it, but not with a general purpose hash. You hash it with a per-user salt, so two people who chose the same password get different stored values and a precomputed table is useless, and you use a function deliberately built to be slow and memory hungry, Argon2id first, scrypt or bcrypt if that's what the platform gives you. A fast hash is exactly what an attacker with a stolen table wants, because a single GPU will try billions of SHA-256 guesses a second.

Encoding was never about security at all. Base64 keeps no secret and anyone decodes it in one line, so using it to hide sensitive data is a real and common mistake worth calling out. On Android the split shows up in the packages themselves. MessageDigest and Mac come from the security libraries, and Base64 sits in android.util next to the other formatting helpers, which is a fair statement of what it is.

Read more Cryptography (opens in a new tab)