Data Encryption

Encryption protects data in two states: at rest (stored) and in transit (being transmitted). Understanding both and implementing them correctly is critical to protecting sensitive information.

Encryption at Rest vs In Transit

Encryption at rest: Data stored in a database, file system, or backup is encrypted. If an attacker gains access to the storage medium, they get ciphertext, not plaintext.

Encryption in transit: Data traveling over networks (HTTP requests, database connections) is encrypted. If an attacker intercepts the network traffic, they see ciphertext, not plaintext.

Both are important. Encryption in transit protects data from being intercepted while traveling. Encryption at rest protects data from being read if the storage is compromised. Many breaches involve unencrypted data at rest—encryption in transit didn't protect against attackers who accessed the database directly.

TLS/HTTPS: Encryption in Transit

TLS (Transport Layer Security) is the standard for encrypting traffic between a client and server. When you visit an HTTPS website, your browser and the server establish a TLS connection and negotiate encryption keys.

How HTTPS Works

The browser connects to the server and requests its certificate. The certificate is a public key signed by a trusted certificate authority. The browser verifies the signature and trusts the public key. The browser and server perform a key exchange, agreeing on an encryption key. All subsequent traffic is encrypted with that key.

The server's certificate proves the server is who it claims to be (not an attacker intercepting the connection). The certificate includes the domain name, so the browser verifies it matches the URL you're visiting.

Certificates and Let's Encrypt

Certificates are issued by certificate authorities (CAs). Historically, certificates were expensive. Let's Encrypt revolutionized this by offering free, automated certificates. You can automate certificate renewal—most hosting platforms handle this automatically.

TLS Versions

Use TLS 1.2 or 1.3. TLS 1.1 and earlier have known vulnerabilities and should be disabled. TLS 1.3 is the newest and most secure, but ensure clients support it. Most modern browsers and APIs support TLS 1.3.

Symmetric vs Asymmetric Encryption

Symmetric encryption uses a single key to both encrypt and decrypt. The same key is used by both sender and receiver. If only your app knows the key, you can encrypt data and be confident only your app can decrypt it.

Asymmetric encryption uses a key pair: a public key (anyone can have) and a private key (you keep secret). Data encrypted with the public key can only be decrypted with the private key. This solves the key distribution problem—you can give everyone the public key without revealing the private key.

AES-256: The Standard for Data at Rest

AES-256 (Advanced Encryption Standard with 256-bit keys) is the gold standard for encrypting data at rest. It's secure, fast, and widely supported. If you're encrypting data in your database, use AES-256.

To use AES-256, you need an encryption key. Where do you store it? The key must be available to your application at runtime (to encrypt/decrypt data) but kept secret (not in version control, not in logs). Use a secrets management system like AWS KMS, HashiCorp Vault, or Azure Key Vault.

Field-Level Encryption for PII

Personally Identifiable Information (PII) like names, email addresses, phone numbers, and social security numbers should be encrypted at the field level. Store the ciphertext in the database; only decrypt when needed.

This protects against database breaches. Even if an attacker dumps the database, they get encrypted fields they can't read. The trade-off is that you can't query encrypted fields (you can't search for users by email if email is encrypted). Some applications accept this; others use partially encrypted fields or keep a hash for searching and the plaintext in separate secure storage.

Key Management: The Hardest Part

Encryption is only as strong as your key management. The strongest encryption is useless if you store the key in plaintext in the same database as the encrypted data. An attacker gets both and decrypts everything.

Where to Store Keys

Never in code or version control. Keys in Git are compromised—attackers search public repos for leaked keys.

Never in environment variables alone. Environment variables can be logged and exposed. Use a secrets management system that encrypts secrets at rest and allows fine-grained access control.

In a Key Management Service (KMS). AWS KMS, Google Cloud KMS, Azure Key Vault, or HashiCorp Vault store keys and manage access. Your application requests the key to decrypt data; the KMS logs access and can audit who decrypted what. Keys are encrypted at rest and rotated automatically.

Key Rotation

Periodically generate new encryption keys and re-encrypt data with them. This limits the window of vulnerability if a key is compromised. Modern KMS services rotate keys automatically. For manually managed keys, establish a rotation schedule (e.g., every 90 days).

Hashing vs Encryption

A common mistake: using encryption when hashing is appropriate (or vice versa). They serve different purposes.

Encryption is reversible. Use it when you need to recover the original value (encrypted credit card data, encrypted customer names).

Hashing is one-way. Use it for passwords, API keys, and other values you don't need to recover. You can't decrypt a hash; you can only verify that an input matches a stored hash.

A common mistake: storing passwords encrypted instead of hashed. If the encryption key is compromised, the attacker can decrypt all passwords. If passwords are hashed, they can't be decrypted (in theory)—they can only be cracked offline, which is slow with a good hashing algorithm.

Encrypting Backups

Backups contain sensitive data. If a backup is stolen, unencrypted backups expose all data. Always encrypt backups before storing them, and manage the encryption keys separately from the data.

Many cloud providers offer encryption of backups at rest. Ensure it's enabled. Consider using your own encryption key (Customer-Managed Keys) rather than cloud provider-managed keys, giving you full control.

End-to-End Encryption

End-to-end encryption (E2E) means data is encrypted on the sender's device and decrypted only on the recipient's device. The service provider (you) never has access to plaintext—you can't decrypt messages even if you wanted to.

E2E provides the strongest privacy. WhatsApp and Signal use E2E—the servers store encrypted messages but can't read them. The trade-off is that legitimate uses like content moderation are harder (you can't scan for illegal content if you can't read it).

Managed Database Encryption

Cloud databases (AWS RDS, Google Cloud SQL, Azure SQL) offer encryption at rest. This is better than nothing, but understand what it protects against. The database encrypts data before writing to disk, but while running, data is decrypted in memory.

Managed encryption protects against an attacker stealing the physical disk. It doesn't protect against an attacker connecting to the running database and querying plaintext. If you need field-level encryption, implement it in your application.

Practical Encryption Checklist

For every web application:

✓ Enable HTTPS with a valid certificate (HTTPS on everything)

✓ Use TLS 1.2 or 1.3 only

✓ Hash passwords with bcrypt/Argon2 (never encryption)

✓ Use a KMS for encryption keys (AWS KMS, Google Cloud KMS, etc.)

✓ Encrypt PII and sensitive data fields with AES-256

✓ Encrypt database backups

✓ Never store encryption keys in code, version control, or logs

Encryption is not optional for modern applications. Users trust you with their data. Encrypt at rest, encrypt in transit, manage keys securely, and regularly audit your encryption practices.