Defended
A copied encrypted .ks backup without its password. Reading the persisted database payload while locked. Tampering with AES-GCM backup or attachment payloads. Malformed import files. Brief physical access after the app has locked.
Security / Threat model
A password manager that claims to stop every attack is lying to you. This page is the public summary of the desktop threat model: the attacks the design defends against, the ones it only partially defends against, and the ones it deliberately does not.
The model covers the desktop application running as a local vault: master password setup, unlock, lock and reset; persistence in the wa-sqlite backend and legacy OPFS/JSON stores awaiting guarded migration; encrypted backups; attachment encryption; biometric convenience unlock; and clipboard and revealed-field behaviour while the app is unlocked.
Protected assets include the master password, every vault item secret — passwords, cards, API keys, passkey records, identities, notes, TOTP seeds and ownership-revealing metadata — attachment contents, encrypted backup files and the biometric-wrapped unlock payload.
Trust boundaries are explicit. Browser-like storage APIs count as persistence, not secret storage. OPFS and localStorage fallbacks are treated as attacker-readable at rest unless the app encrypted them. Imported CSV/JSON data and user-selected backup files are untrusted input until parsed and validated.
A copied encrypted .ks backup without its password. Reading the persisted database payload while locked. Tampering with AES-GCM backup or attachment payloads. Malformed import files. Brief physical access after the app has locked.
A process with your OS user account reading application storage: item payloads and attachments are encrypted, but profile settings and some metadata may remain readable. A valid unlocked session: auto-lock and reveal reset reduce exposure, but unlocked is still trusted.
Malware running as your OS user while the vault is unlocked. A compromised OS, WebView or runtime. Memory inspection, keylogging, privileged screen capture and clipboard capture by hostile local software. Losing the master password with no valid backup. Cloud sync, multi-device conflict resolution and enterprise policy are not shipped features and are outside the model.
The native messaging bridge binds only to local loopback TCP (127.0.0.1, port range 49155–49165), authenticates with a 256-bit CSPRNG pairing token stored in an OS-protected file, and then encrypts every frame with XChaCha20-Poly1305 under a session key derived with HKDF-SHA256. Cached credentials carry a five-minute lease and are zeroized on expiry; broad queries return sanitized metadata so a single message cannot bulk-exfiltrate the vault. Malware with your OS privileges can still read the token file — that residual risk is documented, not denied.
Vault session state is a zeroized Uint8Array in process memory. Safer than sessionStorage, but not an OS secret enclave — setup and unlock input still crosses the UI boundary.
Windows builds request WDA_EXCLUDEFROMCAPTURE and Android sets FLAG_SECURE. This reduces ordinary screenshots and task-switcher previews; it does not stop privileged capture software.
Every extension bridge frame carries a fresh 24-byte nonce; unauthenticated or version-mismatched frames terminate the connection immediately.
No. The vault file and backups are ciphertext on disk, and the master password never touches sessionStorage. Malware running in your own session while the vault is unlocked is a different question — that is explicitly out of scope.
Because no local application can win them. Claiming protection from keyloggers or a compromised OS would be false comfort. Writing the boundary down lets you decide what KalderaShield can and cannot be responsible for.
Yes. It is reviewed on every release, and a residual-risk register records each known gap, its status and the planned mitigation — including an accepted, documented trade-off in the extension autofill path.