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.

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: AES-256-GCM with a server-side Key Encryption Key (KEK), format prefix kek1$.

In transit: TLS 1.2 or higher, HSTS enabled.

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.

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.

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.

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.

Read-only members: metadata (title, username, URL) is visible to read-only members, but encrypted credentials are designed not to be returned for users without write access.

Database-level compromise: vault keys are designed to remain protected by AES-256-GCM with KEK. The KEK itself is derived from an environment variable separate from the database.

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: vault KEK sourced from VAULT_KEK environment variable (64-char hex). Fallback derives from JWT_SECRET via HMAC-SHA256.

Audit logging: non-sensitive metadata logged for all operations. Logs do not contain plaintext credentials or key material.

Key rotation: supported via server-side key rotation utilities. Rotated keys are flagged and rejected on next load.

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 encryption, KEK operations).

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.

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.

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.

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.

For security concerns, privacy-related requests, or complaints, please use the Contact us page.