Three operations, constantly used as synonyms, with completely different guarantees.
Encoding: reversible by anyone
Base64, URL encoding, hex. These change the representation of data so it survives a particular channel. There is no key and no secret. Anyone can reverse them instantly.
Purpose: compatibility. Security value: none.
Encryption: reversible with a key
AES, RSA, ChaCha20. Encryption transforms data so that only someone with the correct key can recover it. It is designed to be reversed, that is the point.
Purpose: confidentiality. Requires: key management, which is the hard part.
Hashing: not reversible at all
SHA-256, bcrypt, Argon2. A hash function maps input of any length to a fixed-size output, deterministically, with no way back. There is no "dehashing", because the function discards information, infinitely many inputs map to each output.
Purpose: verifying that something is what you expect, without storing the thing itself.
What makes a hash function good
- Deterministic, same input, same output, always.
- Fast to compute (for integrity uses) or deliberately slow (for passwords, see below).
- Avalanche effect, flipping one input bit changes about half the output bits.
- Preimage resistance, given a hash, you cannot find an input producing it.
- Collision resistance, you cannot find two different inputs with the same hash.
Which functions are still safe
MD5, broken. Collisions have been practical since 2004 and can be produced in seconds. Acceptable only as a non-security checksum against accidental corruption. Never for anything an attacker touches.
SHA-1, broken. Google demonstrated a practical collision (SHAttered) in 2017. Git still uses it for object identity for historical reasons, with hardening; do not choose it for anything new.
SHA-256 / SHA-3, current standards for integrity, signatures and general-purpose hashing.
bcrypt, scrypt, Argon2, password hashing specifically. Different job, see below.
Passwords need a different kind of hash
This is the distinction that causes the most damage in practice.
SHA-256 is fast, that is a feature for verifying a file and a catastrophe for passwords. A modern GPU computes billions of SHA-256 hashes per second. Against a leaked database of SHA-256 password hashes, an attacker recovers every common password essentially immediately.
Password hashing functions are built to be slow and memory-hard:
- Argon2id, the current recommendation, winner of the Password Hashing Competition. Tunable in time, memory and parallelism.
- bcrypt, older, extremely well-tested, still perfectly acceptable. Note its 72-byte input limit.
- scrypt, memory-hard, also fine.
They also salt automatically: a unique random value per password, stored alongside the hash. Salting means two users with the same password get different hashes, and it destroys the economics of precomputed rainbow tables.
Never store passwords with SHA-256, MD5, or any general-purpose hash, salted or not.
The email test
If a service can email you your existing password, it is storing it either in plaintext or reversibly encrypted. A correctly built system cannot do this, because it does not have your password, only a hash of it. That is why real password recovery always means resetting, never retrieving.
It is a two-second assessment of how seriously a service takes this.
Where each belongs
| Task | Use |
|---|---|
| Store user passwords | Argon2id or bcrypt |
| Verify a downloaded file | SHA-256 |
| Detect duplicate files | SHA-256 (or MD5 if only accidental corruption matters) |
| Protect data at rest | AES-256 encryption |
| Send binary through a text channel | Base64 encoding |
| API request signing | HMAC-SHA256 |
Computing hashes locally
Browsers expose SHA-256 through the Web Crypto API, so a hash can be computed without sending anything anywhere. Use hash generation for text and file checksums for files, and compare the result with the value the publisher lists.