DB Browser (SQLCipher) — Windows

1) Strong keys and key management

• Prefer long passphrases (12–20+ characters) or randomly generated secrets.
• Avoid reuse across services. Use a password manager to generate and store secrets.
• Rotate keys when personnel change or compromise is suspected. Back up and verify after rekeying.
• Never hardcode secrets in source code or store them in the DB itself.
• Consider OS secret stores or managed vaults for applications.

2) SQLCipher versions and parameters

• Align the SQLCipher version (e.g., v3 vs v4) across tools. Mismatches cause open errors.
• Record parameters like kdf_iter (PBKDF2 iterations) and page_size. Keep them consistent across environments.
• When migrating, export → import to move between versions or parameter sets safely.
• Verify support with PRAGMA cipher_version; in Execute SQL after opening.

3) Backups and integrity

• Keep regular backups. Test restore procedures, not just backup creation.
• After risky operations (rekey, migration), run PRAGMA cipher_integrity_check; (or PRAGMA integrity_check; for plain DBs).
• Store exports securely. Delete plaintext dumps after use.
• Consider versioning backups and protecting them with OS-level encryption.

4) Performance trade‑offs

• Higher kdf_iter strengthens key derivation but slows opening. Choose a balanced value for your environment.
• Adjust page_size for workload characteristics; larger pages can help some read patterns.
• Use appropriate indexes and consider WAL mode depending on workload.
• Avoid unnecessary vacuuming on very large encrypted DBs; plan maintenance windows.

5) Threat model

• SQLCipher protects data at rest. It does not protect data in memory while the DB is open.
• Combine with Windows BitLocker/device encryption and OS hardening for defense‑in‑depth.
• Limit access to the key and DB file with proper file system permissions.

Operational checklist

• Back up → change → verify → decommission old copies.
• Document version/parameters alongside your project.
• Audit who has access to keys and DB files.
• Test opening the DB on a second machine/tool before going live.

FAQ