Hashing vs. Encryption
Two different methods of transforming data for security purposes.
Detailed Explanation
Hashing is a one-way process (you can't 'de-hash' it); it is used for data integrity and password storage. Encryption is a two-way process (it can be decrypted with a key); it is used for data privacy during transmission or storage. A fundamental security rule: 'Hash passwords, encrypt sensitive data (like PII)'.
Quick Summary
Hashing is one-way and used to verify data without storing it; encryption is two-way and used to keep data secret in transit or at rest. Picking the wrong one is a common, dangerous mistake.
Key Takeaways
- Hash passwords, never encrypt them, you should not be able to recover a user's password from your database.
- Encrypt PII, payment data, and other reversible-but-sensitive data, you need to read it back for legitimate use.
- Hashing also powers integrity checks (file checksums, Git commit IDs, blockchain links).
- Cryptographic hashes (SHA-256) ≠ password hashes (bcrypt, argon2). The first is fast; the second is intentionally slow.
- Encryption needs key management, losing the key is losing the data; leaking the key is leaking the data.
When to use it
- Hashing: password storage, file integrity, message authentication (HMAC), content-addressable storage.
- Encryption: TLS in transit, disk and database encryption at rest, end-to-end messaging, JWT signing (HMAC) vs. encrypting (JWE).
- Choosing between them when designing a new field: "Do I ever need the original value back?" If no, hash. If yes, encrypt.
Common Mistakes
- Encrypting passwords "so we can email them back to users", this is the single most common credential-storage anti-pattern.
- Using a fast hash (SHA-256) to store passwords. Use bcrypt/argon2/scrypt instead.
- Confusing encoding (base64, hex) with encryption, encoding is reversible by anyone, not secret.
Hashing vs. Encryption, Frequently Asked
Can hashing be reversed?
Not algorithmically, but if the input space is small (passwords, IDs), an attacker can hash every candidate and look for a match. That's why password hashes need to be slow and salted.
Should JWTs be signed or encrypted?
Signed (JWS) for most cases, the payload is readable but tamper-proof. Encrypted (JWE) only when the payload itself is sensitive and must be hidden from the client; this is rare in practice.