Vault
Logins, notes, and API keys held as ciphertext. The key is the member's own account password, derived at the moment they type it. An administrator cannot read a secret without proving they are themselves.
Custody, not another wiki page with a padlock on it.
A vault is a folder of secrets for a workspace. The list of titles can show while it is locked. The bodies cannot, and no role in the product changes that.
Most internal secret storage fails in one of two ways. Either it is a wiki page with restricted access, which means the secret is sitting in plaintext in version history and search indexes. Or it is encrypted with one application-wide key, which means anybody the API will serve, and anybody who reads the database, sees plaintext.
Neither is custody. Here the encryption key is derived from the member's own account password at the moment they type it, so the stored ciphertext is not openable by the application on its own. Titles, item type, and ordering stay in the clear so a locked vault can still render a useful list.
There is no separate vault password to invent, rotate, or lose. Signing in already proved the member can type their password; unlocking asks them to prove it again, on the platform's own confirmation prompt, which the vault never sees.
- Key material
- Derived from the member's account password
- Derivation
- Argon2id, 64 MiB memory, 32-byte output
- Salt
- 16 random bytes, per vault, per member
- Data key
- 32 random bytes, generated once per vault
- At rest
- Item bodies encrypted under the data key
- Wrapping
- One data-key wrap per member, under their own key
- Plaintext retained
- Title, item type, position. Nothing else
- Unlock grant
- 10 minutes, then the key is dropped
What happens when somebody unlocks.
The password is never posted to the vault. It is entered on the platform prompt that owns authentication, and the vault only learns that the confirmation succeeded.
The member asks to unlock
Opening a locked vault shows titles and item types. Choosing to unlock starts a confirmation against that specific vault, not a general session step-up.
Identity is confirmed where passwords belong
The platform shows its own prompt, with the member's real name and avatar, and collects the password. The vault has no password field, so there is no second place for a credential to leak from.
The key is derived, the data key unwrapped
On success, the member's key is derived from the password and used to unwrap their copy of the vault's data key. Item bodies decrypt from that point.
The grant expires on its own
The unlock lasts ten minutes. After that the key is dropped and the vault returns to showing titles only. Changing the account password invalidates the old wrap, as it must.
This is the point most secret stores concede. Ownership of the workspace does not unwrap a data key, because the key was never derived from anything the platform holds. An owner who wants a secret completes their own confirmation, as themselves, and it is recorded.
Sharing decides who may ask, not who can read.
The share list and the ability to decrypt are deliberately separate. Being invited gets you the right to attempt an unlock with your own password.
| Level | Can do | Still needs |
|---|---|---|
| Read | See titles, unlock, reveal and copy bodies | Their own password confirmation |
| Edit | Everything above, plus add and change items | Their own password confirmation |
| Manage | Everything above, plus share, revoke, and delete | Their own password confirmation |
| Not shared | Nothing. The vault is not listed | An invitation first |
What each item type holds.
One encrypted payload per item. No document model, no version history of plaintext, no comment threads on secrets.
loginUsername, password, address, and free-text notes.
noteA single free-text body, encrypted whole.
api_keyThe key itself plus free-text notes.
Deliberate limits.
Search
Matches titles and item type. It never indexes a body, because that would undo the encryption.
Events
Carry identifiers and titles only. No secret, no key, ever leaves on an event.
Audit
Unlock, reveal, share, revoke, and every change are recorded, without the secret.
No recovery key
Losing the account password means the wrap must be redone, not bypassed.
No version history
Plaintext is never retained to diff against.
Membership removal
Losing workspace membership purges the share and its key wrap.
Related
Bring the door onto the same epoch as the laptop.
We will walk you through a live portal, a compiled policy pack, and a revocation that closes the turnstile and locks the screen while you watch.