Security Policy

Last updated: July 2026

Security Architecture

Zentra is built with a zero-knowledge, local-first security model. Your master password is the only key to your vault — it is never stored, transmitted, or recoverable.

Encryption: AES-256-GCM with Argon2id key derivation
Key Storage: Encryption key derived from master password at unlock time; never stored
Password Verification: Encrypted sentinel pattern — no password hash stored
Clipboard: Auto-cleared after configurable timeout (default 30 seconds)
Electron Hardening: contextIsolation: true, sandbox: true, nodeIntegration: false
Memory: Encryption key cleared on lock, suspend, sleep, and window blur

Threat Model

Threat	Mitigation
SQLite database stolen	AES-256-GCM encryption, Argon2id derived keys
Renderer compromise	Sandbox, contextIsolation, minimal IPC surface
Clipboard snooping	Auto-clear after timeout, overwrite with dummy data
Weak master password	Entropy requirements, KDF tuning, strength feedback
Brute-force attack	Progressive lockout with configurable thresholds
Corrupted database	Crash recovery, encrypted backup/restore
Lost device	Vault remains encrypted; master password required

Reporting a Vulnerability

If you discover a security vulnerability in Zentra, please do NOT file a public issue. Instead, email the details to security@zentra.dev.

You should receive a response within 48 hours. If you do not, please follow up.

Responsible Disclosure

We ask that researchers follow responsible disclosure practices: allow reasonable time for a fix to be developed and tested before publicly disclosing the issue. We commit to acknowledging receipt within 48 hours and providing regular updates on remediation progress.

Dependencies

Dependencies are regularly reviewed and updated. Critical security patches are prioritized. The application uses Subresource Integrity (SRI) where applicable and Content Security Policy (CSP) headers are enforced in production builds.