Guides
Security notes
What protects the secrets, what the webview can reach, and how to handle passwords, mnemonics and backups.
The plugin moves secrets between three places: the OS credential store, the Rust process and the webview. Know which data reaches which place.
What protects the data
- The OS store. Entries are encrypted and access-controlled by the platform: Keychain, Credential Manager, Secret Service, the Android keystore, the iOS data-protection keychain. Anyone who can act as your user on the machine (or as your app on mobile) can usually read them. See Platforms.
- Tauri permissions. Only windows whose capability includes the plugin can call it. See Permissions.
- Not the session password.
KeyringSession.load(path, password)does not verify or use the password: any password opens any session. It exists only for Stronghold compatibility. There is no snapshot file encrypted with it.
There is no in-memory or file fallback: if the OS store does not work, calls fail instead of writing secrets somewhere else.
What reaches the webview
| Data | Webview sees it? |
|---|---|
Password secrets (getPasswords, setPasswords) | Yes: they are the API. |
Store records (store.get) | Yes. |
| Vault records | Written from JS with vault.insert, never read back. |
| Private keys made by procedures | No. Procedures return only a chain code, a public key, a signature, or nothing. |
A new BIP39 mnemonic (generateBIP39) | Yes, once, so the user can back it up. |
Plain backup (exportPasswordsPlain) | Yes, in clear text. |
| Encrypted backup | Only the envelope; the passphrase is sent to Rust. |
Anything the webview holds can be read by any script running in it, so:
- Never load remote or untrusted content in a window that has the plugin's permissions.
- Do not keep secrets in global state,
localStorage, logs or error reports longer than needed. - Show a new mnemonic once and drop the reference; never write it to disk or send it anywhere.
- Prefer vault procedures over storing key bytes in the store: keys in the vault never leave Rust.
Reserved kp: accounts
Store records and vault keys are entries whose account starts with kp:. The password commands reject
such accounts in any letter case, so getPasswords cannot read vault keys and setPasswords cannot
overwrite them. This guard is part of the IPC layer; Rust code can still reach every account.
What the plugin does with secrets in Rust
- Passwords, passphrases, decrypted backups, seeds and derived keys are wiped from memory after use
(
zeroize, also insideargon2andchacha20poly1305). - Error messages never contain secret values, key material or mnemonic words; an invalid mnemonic fails with a fixed message.
Debugoutput of the IPC types redacts secrets, mnemonics and passphrases.- Keyring calls run on blocking threads, so an OS prompt does not stall other commands.
Backups
- Plain backups expose every secret to the webview and to wherever you save the file. Use them only in flows the user started on purpose.
- Encrypted backups use Argon2id + ChaCha20-Poly1305 (details). Their strength is the strength of the passphrase: ask the user for a long one, and never store it next to the backup.
- An import validates the whole backup first, so a bad or tampered file changes nothing.
Limits of the design
- The OS stores cannot list entries, so you cannot audit "everything the app stored" from the plugin.
Keep an index if you need to clean up (e.g. on sign-out, call
deletePasswordsfor every known account). - Uninstalling the app does not always remove its entries (desktop keychains keep them). Delete them yourself if that matters.
- On Linux without a desktop session, a locked Secret Service collection can block a call for a very long time, see Linux.