Your vault stays on your computer

Only the desktop app can open it. The website and the server never receive it. This page explains how the parts fit together, and what is still unfinished.

Three parts, one vault

Sesame has three parts. The desktop app holds your vault. The browser extension asks the app to fill a login. The website publishes releases and runs optional accounts.

Only the desktop app reads your vault. You can create, unlock, import, back up, and restore it without an account or a network connection.

Website and APIReleases and an optional account. Never your vault.

Browser extensionStores no passwords. Asks the app for each fill.

Sesame desktop app
Interface Shows what you ask for.

Tauri IPC

Rust core Holds the key and decides what leaves.

reads and writes

Vault file Encrypted on your disk.

Master password checks for sensitive actions

Exporting, backing up, saving a recovery kit, and showing or copying a password all pass one check in the Rust core.

  1. You askExport, back up, or show a password.
  2. You confirmType your master password. The Rust core checks it.
  3. A short window opensTwo minutes. Locking the vault closes it.
  4. Sesame actsIt writes the file, or shows or copies the one password.

A wrong password is refused. After three wrong tries, Sesame makes you wait five seconds, and the wait grows to at most five minutes.

How the vault file is protected

Encryption
XChaCha20-Poly1305
Master password to key
Argon2id, slow and memory-hard on purpose
Opening
Checked as genuine first. Tampered, relabelled, and newer files are refused.
Saving
Written to a new file, checked, then swapped in

If a save fails or stops halfway, your previous vault stays as it was. A vault larger than 64 MiB is refused before anything is written.

Before each release, the pipeline installs the real package on Windows and Linux. It then opens, restores, restarts, and backs up every supported older backup.

While the vault is unlocked

The key that opens your vault is kept out of ordinary memory. On Windows it is locked out of the page file and encrypted again when idle. On Linux the kernel keeps it out of swap and crash dumps.

Decrypted data is wiped from memory as soon as Sesame is done with it. Locking the vault throws the key away.

The extension cannot fill on its own

The extension stores no passwords and never submits a form. Every fill needs your approval in the desktop app, for that exact tab and site. A web page cannot start a fill.

Saving works the same way. You choose Save this login after a fill, and the desktop app asks you to approve it.

Where downloads come from

Every installer is built in public CI. Sigstore ties each file to the source repository and the exact commit. The releases page lists a checksum for every file.

An in-app update checks a signed receipt against the installer before it runs. Two gaps remain. The Windows installer is not Authenticode signed yet, so SmartScreen warns on first run. Linux packages do not update themselves, so download new versions from the releases page.

What each side stores

On your computer: your vault items and attachments, your master password and derived keys, recovery material, 2FA secrets, and backup codes. All of it is encrypted in the vault file.

On the website, only if you make an account: your email, a password hash, and sessions you can revoke. None of it can open a vault.

Sync is turned off in the current release.

Check it yourself

Every part of Sesame is open source under the GNU Affero General Public License v3.0 or later: the desktop app, the vault core, the server, the portals, the website, and the extension. Each release links to the source and build evidence behind it.

Not done yet

No independent security audit has happened yet. The browser extension is not in the browser stores yet. Until both are done, use test data.