Security
How SandPass protects your data
Zero-Knowledge Architecture
SandPass is designed so that we cannot read your data — by design, not by policy. All encryption and decryption happens exclusively on your device. Our servers only store encrypted blobs that are computationally impossible to decrypt without your master password.
Authentication — OPAQUE (RFC 9807)
Unlike traditional login systems where a hash of your password is sent to the server, SandPass uses the OPAQUE protocol — a password-authenticated key exchange where your password is never transmitted in any form. Not even hashed. The server proves it knows your registration data, and you prove you know the password, without either side revealing secrets.
Encryption — AES-256-GCM
Every vault item (password, note, card, identity) is individually encrypted using AES-256-GCM with a unique random 96-bit IV per operation. This is authenticated encryption — any tampering with the ciphertext is detected and rejected.
Key Derivation — Argon2id
Your master password is transformed into an encryption key using Argon2id with 64 MiB memory and 3 iterations. Argon2id is a memory-hard key derivation function that makes brute-force attacks with GPUs or ASICs prohibitively expensive. It is the winner of the Password Hashing Competition and the current state of the art.
6 Layers of Defense
OPAQUE (RFC 9807)
Password never transmitted — not even hashed.
AES-256-GCM
Authenticated encryption with unique IV per operation.
Argon2id KDF
Memory-hard derivation (64 MiB) resists GPU/ASIC attacks.
Dual-Wrap Keys
Symmetric key encrypted under both device key and account key.
HMAC-SHA256 Sessions
Sessions signed server-side. Redis compromise cannot forge sessions.
Replay Protection
Monotonic counter per session prevents replay attacks.
Browser Extension Security
- Content Security Policy: Strict CSP (
script-src 'self' 'wasm-unsafe-eval'; object-src 'none') blocks all inline scripts and plugins. - Closed Shadow DOM: Autofill dropdowns are rendered inside a closed Shadow DOM, preventing malicious websites from reading credentials via DOM observation. No other major password manager does this.
- Phishing protection: Autofill verifies that the website domain matches the stored credential's domain (eTLD+1 matching) before filling.
- Non-extractable keys: Cryptographic keys use Web Crypto API with
extractable: false— they cannot be exported from the browser's internal key store.
Two-Factor Authentication
SandPass supports TOTP-based 2FA (RFC 6238) with backup codes. TOTP secrets are encrypted server-side with AES-256-GCM using a dedicated HKDF-derived key. Trusted devices can skip 2FA for 30 days using CAS-atomic token rotation that detects concurrent use.
Testing & Auditing
SandPass has 287 automated tests covering:
- 161 backend tests (auth, sessions, vault CRUD, security, pentest scenarios)
- 126 extension tests (crypto, TOTP, password generator, import/export)
- Penetration testing: IDOR, SQL injection, rate limiting, CORS, session security
- 0 known vulnerabilities in dependencies (pip-audit + npm audit)
Open Source
Everything described on this page is public and auditable. The browser extension and every line of its cryptography are published under the GPL-3.0 licence at github.com/sandprivacy/sandpass-extension.
A password manager that claims to be zero-knowledge without publishing its client is asking for blind trust. The only way to verify that a secret never leaves your device is to read the code that encrypts it. Every release is tagged, so you can check the published source against the extension you installed — and if you ever find a divergence, that is a security issue we want to hear about.
Responsible Disclosure
If you discover a security vulnerability, please report it privately — do not open a public issue. Use GitHub private vulnerability reporting or email security@sandpass.io. We acknowledge every report within 48 hours, and we will not pursue legal action over good-faith research. Full policy: SECURITY.md.