Locking, the clipboard, and your disk
Unlocking is not logging in
Section titled “Unlocking is not logging in”Two separate operations, and keeping them separate is a load-bearing property rather than an implementation detail.
Logging in gets you an API token. That token authorises downloading ciphertext. It decrypts nothing.
Unlocking derives keys from your master password and Secret Key, on your device. It never touches the network.
So an attacker holding every session token we have ever issued has the ability to download encrypted blobs. That is the whole extent of it.
What locking does
Section titled “What locking does”Locking drops the in-memory key material and zeroes it — actively overwritten, not left for the garbage collector. Along with it goes the decrypted environment cache, any draft you were editing, and every revealed value on screen.
Then the app returns to the unlock screen. Locked means locked: no content renders.
Your local file survives a lock. It holds public-key pins, sync version markers, and your encrypted account keys — never a secret value — so the next unlock has something to verify against.
When it locks
Section titled “When it locks”| Trigger | macOS | Windows | Linux |
|---|---|---|---|
| 15 minutes idle | yes | yes | yes |
| Machine sleeps | yes | not yet | not yet |
| Display sleeps | yes | not yet | not yet |
| Screen locks | yes | not yet | not yet |
The idle timer works everywhere. The OS-level signals are macOS-only today — the Windows and Linux hooks are stubs, and that is a real gap rather than a rounding error: on Windows and Linux, closing your laptop lid does not itself lock your vault. The idle timer will catch it fifteen minutes later.
Wiring up the remaining platforms goes with the installer work on the roadmap. Until then, lock manually before you walk away.
The status pill in the title bar always shows the current state, on every platform, regardless of where the OS puts its own window controls. Vault state is never something you have to infer.
The clipboard
Section titled “The clipboard”Copying a value clears it after about 20 seconds, and the toast says so — because a promise the interface doesn’t make is a surprise, and a surprise about a credential is a bad one.
It also clears on lock, immediately. And the clear is generation-guarded: if you copy something else within the window, the pending clear won’t wipe your newer clipboard contents.
Cendarum only ever writes to your clipboard. It never reads it.
Your disk
Section titled “Your disk”The local vault file lives at:
| Platform | Path |
|---|---|
| macOS | ~/Library/Application Support/com.cendarum.app/vault.bin |
| Linux | $XDG_DATA_HOME/com.cendarum.app/vault.bin |
| Windows | %APPDATA%\com.cendarum.app\vault.bin |
Its integrity check is a plain digest, not a keyed one — there is no key available before you unlock, and the file holds no secret to key it with. So it reliably detects accidental corruption, truncation, and half-written files, and it fails closed when it finds any: an unreadable file is an error, never a silent reset to a blank slate. That distinction matters, because a silent reset is what would quietly discard your public-key pins and re-trust whatever the server offers next.
What it does not do is resist a local attacker. Two named limits:
- A stolen locked laptop, or a cloud backup of that file, exposes its contents to whoever reads it. That content is metadata — which user IDs you’ve verified, which environments exist, version counters — and it is a subset of what the server already sees. The genuinely sensitive slots inside it are already ciphertext. Mitigation is ordinary: FileVault or BitLocker, and keep the file out of cloud backups.
- Rolling the file back to an older, internally valid copy is not defended. The digest validates the old file, and a keyed MAC would too — nothing inside a single self-contained file can tell “old but real” from “current”. Closing that needs an external monotonic counter such as a TPM or secure enclave.
Both are the compromised-device class, which the threat model does not claim to defend.
Two processes, one file
Section titled “Two processes, one file”The desktop app and the CLI share the file and coordinate through an advisory lock, so a read-modify-write from one doesn’t clobber the other’s.
Advisory is the operative word: it keeps two cooperating Cendarum processes honest. It is not a defence against a hostile process running as your user — but then, a process that can write your vault file is already inside the compromised-device class above.