1. Zero-Knowledge Security Model
Valtou is designed around a zero-knowledge model: vault contents are encrypted in the browser before they are sent to the service.
In normal operation, Valtou is designed not to receive your master password or plaintext vault contents. Decryption is intended to happen only in your browser.
What this means: a server-side data exposure should yield encrypted vault data rather than plaintext vault contents. Plaintext password recovery is intentionally not part of the design.
2. Encryption Standards
Vault encryption: AES-256-GCM (authenticated encryption). Each vault item has a unique IV.
Key derivation (client-side): PBKDF2 with 600,000 iterations and SHA-256 hash.
Key derivation (server-side): Argon2id — memory-hard, resistant to GPU and ASIC attacks.
Key wrapping: RSA-OAEP-2048 (web client) for wrapping Data Encryption Keys (DEKs).
Vault keys at rest: stored only as RSA-OAEP-wrapped copies, one per authorised user. There is no server-side key-encryption key, and no server-held key of any kind can unwrap them.
In transit: TLS 1.2 or higher, HSTS enabled.
3. Key Hierarchy
Master Password: intended to be known only to you and used to derive the Master Key locally.
Master Key (in-memory only): designed to avoid storage in localStorage, cookies, or any persistence layer. Auto-expires after a configurable inactivity period.
Data Encryption Key (DEK): a unique AES-256-GCM key per vault. The DEK is encrypted (wrapped) with your RSA public key and stored on the server.
Vault DEK decryption: the encrypted DEK is downloaded and decrypted in your browser using your RSA private key. The plaintext DEK is designed to remain client-side.
Key rotation: rotated keys are flagged (isRotated) and rejected on load, forcing re-keying.
4. Client-Side Operations
Sensitive cryptographic operations are designed to happen in your browser using the Web Crypto API: key derivation, AES-GCM encryption/decryption, RSA key generation, RSA-OAEP encryption/decryption.
Encrypted RSA private key: stored in localStorage (encrypted with your master password-derived key). It is safe in localStorage because it remains encrypted at rest.
Logout: your private key reference is cleared from localStorage, the Master Key is purged from memory, and the KeyStore is destroyed.
Session expiry: the Master Key auto-expires after a configurable inactivity period and is cleared on tab switch, minimize, or browser close.
5. Authentication Security
Password verification: Argon2id — a memory-hard key derivation function resistant to brute-force, GPU, and ASIC attacks.
Session tokens: JWT (HS256), expires in 4 hours. Refresh tokens are 64-byte random values stored as SHA-256 hashes in the database.
Two-factor authentication: TOTP (RFC 6238). TOTP secrets are encrypted server-side with AES-256-GCM before storage — a database breach alone does not expose 2FA secrets.
Account lockout and rate limiting: brute-force login attempts are rate-limited and lockout thresholds are enforced server-side.
6. Multi-Tenant Isolation
Each vault has its own unique DEK. This design limits cross-vault exposure if a single vault key is compromised.
Group shared passwords: a Group DEK is generated per group, encrypted for each member using RSA-OAEP, and re-encrypted when membership changes. No cross-group context is shared.
Item names and metadata: the title, username, URL and category of every item are encrypted under the vault key alongside the credential itself, so the server cannot read which accounts a vault holds. Encrypted credentials are additionally withheld from users without permission to view them.
Database-level compromise: the database holds only ciphertext and RSA-wrapped vault keys. Nothing that can unwrap them exists on the server or in its configuration, so a full copy of the database does not yield vault contents.
7. Infrastructure Security
Least privilege: role-based access control (RBAC) enforced server-side on all routes.
Isolation: production environments are isolated; encrypted storage volumes used at rest.
Secrets: no server-side vault key escrow exists. Vault data-encryption keys are generated in your browser and reach the server only as RSA-OAEP-wrapped copies, one per authorised user; the server holds nothing that can unwrap them.
Audit logging: non-sensitive metadata logged for all operations. Logs do not contain plaintext credentials or key material.
Key rotation: your RSA key pair can be rotated from your account settings. Rotation re-wraps every vault key on your own device and is fail-closed — if any vault cannot be re-wrapped, the rotation is refused rather than leaving a vault unreachable.
8. Secure Development Practices
All code changes require peer code review before merge.
Dependency scanning and static analysis on CI.
Encryption logic covered by unit tests (key rotation, RSA key wrapping, envelope encryption and its authenticated-data binding).
E2E tests verify client-side decryption: own passwords, shared passwords, and locked-vault rejection.
Separation of concerns: cryptographic utilities are isolated from business logic, making auditing straightforward.
9. Vulnerability Reporting
We welcome responsible disclosure of security issues.
We ask that vulnerabilities not be publicly disclosed until confirmed and resolved, or 90 days have elapsed from initial report.
If you discover a security issue, please report it to our team.
10. Security Limitations
No system is 100% secure. Residual risks include:
Endpoint compromise — if your device is compromised, the Master Key in memory may be accessible.
Phishing and social engineering — we cannot protect against credential theft through deception.
Weak master passwords — we enforce Argon2id on the server and PBKDF2 client-side, but a weak password remains the weakest link.
We strongly recommend: using a strong, unique master password; keeping your device secure and patched; enabling OS-level protections; never sharing your master password.
11. Standards and Privacy Alignment
Valtou's encryption architecture is designed with reference to AES-256-GCM, RSA-OAEP, PBKDF2 (NIST SP 800-132), Argon2id, and RFC 6238 (TOTP). Privacy practices are intended to be developed with reference to the Australian Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs), where applicable.
12. Contact
For security concerns, privacy-related requests, or complaints, please use the Contact us page.