Your data is yours.
We can't touch it.
InCaseIDie is built on a simple principle: we should never be able to read what you store. Every architectural decision - from encryption to deletion - follows from that commitment.
The core guarantee
In our database we store only fully encrypted data. We cannot decrypt it without your vault key. We do not store your vault key - not even an encrypted copy. When you unlock your vault, the key exists only for the duration of that session and is never written to permanent storage in a recoverable form.
This means that if you delete something, it is gone forever - including for us. No backups, no recovery, no exceptions.
How we protect your data
End-to-end encryption
Every piece of data you store in your vault - passwords, messages, financial details - is encrypted on our servers using AES-256-GCM before it is ever written to disk. We use scrypt to derive a strong encryption key from your vault key, making brute-force attacks computationally infeasible.
We never see your vault key
Your vault key never leaves your session in a usable form. We store only a bcrypt hash of it - enough to verify it at access time, but mathematically impossible to reverse into the original key. Even if our entire database were compromised, your vault contents would remain unreadable without your key.
Zero-knowledge architecture
Our database contains only encrypted ciphertext. Without your vault key we cannot read, search, or recover any of your vault data. This is not a policy choice - it is a technical impossibility. No employee, no court order, and no attacker with access to our database can read what you have stored.
Deletion is permanent
When you delete a vault item, a file, or your entire account, the data is removed from our database immediately. We do not keep backups of user vault content after deletion. There is no 30-day grace period, no soft delete, no recovery window. Gone means gone.
We don't store what we don't need
We collect only your name, email address, and encrypted vault data. We do not store analytics beyond what is necessary for security (such as IP addresses for access notifications). We do not use advertising trackers. We do not log your activity inside the vault.
Secure transport & headers
All traffic is served over HTTPS with HSTS enforced. We set strict security headers on every response - Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, and a restrictive Permissions-Policy - to protect against XSS, clickjacking, and MIME-sniffing attacks.
Technical summary
| Vault encryption | AES-256-GCM with authenticated encryption |
| Key derivation | scrypt (N=32768, r=8, p=1) - resistant to GPU brute-force |
| Vault key storage | bcrypt hash only - plaintext never stored |
| Account password storage | bcrypt (cost 12) |
| Session token | cryptographically random 48-byte token, httpOnly cookie |
| Transport security | HTTPS + HSTS (2-year max-age, includeSubDomains, preload) |
| Bot protection | Cloudflare Turnstile on login and vault access pages |
| Rate limiting | 5–10 attempts per 15 minutes per IP on all sensitive endpoints |
| Access logging | IP + geolocation logged per vault access attempt, emailed to owner |
Security FAQ
What happens if I forget my vault key?
Your vault contents cannot be recovered. Because we never store the key or any form of it that can be reversed, there is no "reset vault key" option. This is intentional - it is what guarantees that we cannot access your data either. Keep your vault key in a safe place.
Can InCaseIDie read my vault data?
No. The database stores AES-256-GCM ciphertext. Without your vault key we have no way to derive the decryption key. We cannot read your passwords, messages, or any other vault content under any circumstances.
What if InCaseIDie gets hacked?
An attacker who obtained our database would see encrypted blobs, hashed vault keys (bcrypt), and hashed account passwords (bcrypt). They would not be able to decrypt vault contents without each user's individual vault key. Your plaintext data is never stored.
Do you share data with governments or third parties?
We share nothing with third parties beyond what is required to operate the service (Stripe for payments, Proton Mail for email). If we received a legal demand, we could only produce encrypted data that we ourselves cannot read.
How does the emergency contact access work securely?
Emergency contacts must present their access token, their full name, their date of birth (if set), and the vault key. All three factors are verified before any data is decrypted. Access is also gated on your check-in schedule - contacts cannot access the vault while you are actively checking in.
Is InCaseIDie open source?
The codebase is currently private. We welcome independent security researchers to contact us at [email protected] if they discover a vulnerability.
Found a vulnerability?
We take security reports seriously. Please disclose responsibly by emailing us directly. We will respond within 48 hours.
Report a vulnerability