Encryption protects data by transforming it into an unreadable format. Only those with the correct key can decrypt and read the original data. This playground demonstrates encryption concepts for protecting data in transit and at rest.
Uses the same key for both encryption and decryption. Fast and efficient for large amounts of data. Examples: AES, Fernet.
The key must be kept secret and shared securely between parties. Store in environment variables or secret vaults, never in code.
Encrypting data at rest (databases, files), session tokens, API keys stored in databases.
| Aspect | HTTP | HTTPS |
|---|---|---|
| Data Encryption | None | TLS 1.2+ |
| Man-in-the-Middle | Vulnerable | Protected |
| API Keys in Headers | Visible to attackers | Encrypted |
| Production Use | Never | Required |
Client and server exchange certificates and agree on encryption keys. This happens automatically when you use HTTPS.
Trusted third parties (Let's Encrypt, DigiCert) that verify server identity and issue SSL/TLS certificates.
Use platforms like Heroku, Vercel, or AWS that provide HTTPS automatically. Never disable SSL verification in code.
Note: Real hashing uses bcrypt, argon2, or similar. This demo simulates the concept.
| Method | Reversible? | Use Case |
|---|---|---|
| Plain Text | N/A - Exposed! | Never for passwords |
| Encryption | Yes (with key) | Data you need to read later |
| Hashing | No | Passwords, integrity checks |
API tokens, credit card numbers, SSN, health data, any PII that would cause harm if exposed.
Periodically change encryption keys. Re-encrypt existing data with new keys.
Encryption adds overhead. Only encrypt fields that truly need protection, not entire database.