โ† Back to Vault
โŒ‚ Housing Vault

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