Security by Design
Housing Vault is built so that the people who run the server
cannot read your case files โ even if they wanted to.
Here is how that works, in plain language.
๐
Encryption stays in your browser
Every note is encrypted on your device using AES-256-GCM โ
the same authenticated encryption standard used by modern
browsers, operating systems, and high-security applications.
The plaintext never leaves your browser. Only the unreadable
ciphertext is ever sent to the server.
๐
Your passphrase is the only key
The encryption key is derived from the passphrase you choose,
using a slow, memory-hard key-derivation function. There is
no master key, no administrator backdoor, and no recovery
email. If the passphrase is lost, the data is permanently
inaccessible โ by deliberate design.
๐ก๏ธ
Write authorization, not just a slug
Knowing a case identifier is not enough to change or delete
a vault. A separate authorization token is derived from your
passphrase at creation time. The server stores only a one-way
hash of that token. Every save and every destroy must prove
possession of it.
โฑ๏ธ
Short sessions, clean exits
After a period of inactivity the vault locks and the key
material is dropped from memory. A dedicated Safety Exit
(button or keyboard shortcut) immediately wipes the session
and forces a clean reload. Concurrent edits are protected
by revision checks so one session cannot silently overwrite
another.
๐๏ธ
Zero-knowledge storage
The server holds ciphertext, a random salt, an initialization
vector, a revision number, and a hash of the write-authorization
token. It has no technical means to decrypt the content.
Vault files themselves are stored outside the web root and
denied by the web server configuration.
๐งฑ
Defense in depth
HTTPS is required. The API rejects other origins. CSP, framing
protection, referrer suppression, and rate limits on visitor IP
(Cloudflare-aware) and vault path reduce abuse. Destroy needs the
write token and a confirmation phrase checked on the server.
Footer status checks do not leak paths or secrets.
๐๏ธ
Host salt is not a backdoor
A server-side host secret maps slugs to filenames. It is created
automatically, or you may paste one into config. It cannot decrypt
notes. Changing it after cases exist makes slugs look empty even
though the encrypted files remain on disk.
Design principles
- Client-side first. Cryptographic operations happen where the user is, not where the data is stored.
- No recovery by design. Convenience features that would let an operator restore access are deliberately omitted.
- Least privilege on the server. The server only needs to store and return opaque blobs; it is never given the means to interpret them.
- Fail closed. Missing configuration, failed authorization, or revision conflicts result in clear errors rather than silent fallbacks.
- Transparency for the user. Session timers, save status, and Safety Exit are visible so you always know the state of the vault.
Ready to work with a vault that only you can open?
Enter Vault