Security architecture

What Velora Vault protects - and what it cannot.

Security claims should be inspectable. This page describes the encryption and access controls implemented today, along with the recovery and device-level risks they do not solve.

Get started freeFollow the security model
Protected through four distinct stagesVault data is encrypted locally, checked against account access, and returned only for local unlock.
  1. Readable input
  2. Ciphertext
  3. Access gate
  4. Sealed storage
CipherAES-256-GCM
Key derivationPBKDF2-SHA-256 · 600,000 iterations
Per operationFresh 16-byte salt · fresh 12-byte IV
Key handlingMaster key held in memory while unlocked

Protection in practice

Security beyond encryption.

These controls protect the device session, authorize stored data, and keep account billing state trustworthy without changing what the vault encryption can and cannot do.

This device

Local unlock stays with the signed-in account.

PIN and biometric wrappers are bound to the authenticated account. Velora re-checks that account after a biometric prompt before it commits setup or unlocks. Auto-lock and optional clipboard clearing reduce how long readable secrets remain available on this device.

Account and data

Authorization is checked independently.

Supabase row-level security, active-membership gates, and private document storage policies limit access to owned ciphertext and files. Settings lists each active session by device, so you can recognize one you don’t and sign it out individually - or sign out every other device at once, while the current browser stays signed in.

Billing integrity

Subscription updates are verified and ordered.

Razorpay webhook signatures are verified before processing. Events are handled idempotently, and stale subscription events cannot replace newer state. This protects account entitlements; it does not encrypt vault data.

01 · Stored vault data

Encryption happens in your browser before storage.

Password records, secure notes, wallet records, bank records, and document contents are encrypted with AES-256-GCM before Velora Vault sends them to database or object storage. Each encryption operation uses PBKDF2-SHA-256 with 600,000 iterations, a fresh 16-byte salt, and a fresh 12-byte IV.

The master key is held in browser memory while the vault is unlocked. It is separate from the account password and is not written to the account, database, or normal server logs.

Encrypted before storageReadable vault data becomes ciphertext before it leaves the browser.
  1. Vault data
  2. Encrypted payload
  3. Sealed storage

02 · Access control

Encryption and authorization do different jobs.

Supabase row-level security policies require record ownership and active membership before encrypted vault rows or document objects are returned. This limits which ciphertext an authenticated account can reach; the master key is still required to decrypt it locally.

  1. 1Signed-in account
  2. 2Active membership
  3. 3Owned ciphertext
  4. 4Local unlock
Account access is checkedA signed-in account must pass authorization before vault data is returned.
  1. Signed-in account
  2. Authorization gate
  3. Authorized vault

03 · PIN and biometrics

Local unlock is a convenience layer, not a second vault.

A six-digit PIN derives a local wrapping key. A supported platform authenticator can also protect a local wrapper. Either method recovers the master key into memory for the active unlocked session; neither replaces the master key or sends it to Velora Vault.

PIN attempts are limited in the interface, but a copied local wrapper is still exposed to offline guessing because six digits have a small keyspace. Protect the device itself and use the master key when local unlock is unavailable or reset.

Unlock stays on this deviceA local PIN or platform authenticator recovers the wrapped master key into memory.
  1. This device
  2. Local check
  3. Key in memory

04 · Recovery

Velora Vault cannot recover a lost master key.

Resetting the account password only restores account sign-in. It does not change, reveal, or recover the vault master key. Without the same master key, previously encrypted contents cannot be decrypted by you or by Velora.

Changing your master key on purpose is different, and it is supported: Settings > Security includes a rotation flow that decrypts every vault record with your current master key and re-encrypts it under a new one, committed atomically so nothing is left partially rotated. It still requires the current master key to start - it changes a known key, it does not recover a lost one.

Keep a protected offline copy of the master key. Do not store it in the same vault as the data it unlocks.

No master-key recovery pathVelora cannot reveal or recover a lost master key.
  1. Master key
  2. Not recoverable
  3. Protected offline copy

05 · Threat boundaries

Storage encryption cannot secure a compromised endpoint.

Velora Vault’s current model does not protect against:

  • An unlocked device used by another person
  • Device malware or a malicious browser extension
  • Phishing, screen capture, clipboard monitoring, or keylogging
  • A weak, reused, shared, or exposed master key
  • Content deliberately exported or copied after local decryption

06 · AI-assisted import

Selected import material is processed before encrypted storage.

AI-assisted import is optional. When you choose text or an image for processing, that selected source material is sent through Velora Vault’s configured processing service so draft records can be extracted. Your master key is not included. You review the drafts before the approved results are encrypted and saved.

If source material must never leave the browser in readable form, use manual entry instead of AI-assisted import or image scanning.

Selected sourceReview draftsEncrypt & save

Get started

Review the boundaries before creating your account.

Security is strongest when the product and the user each know their part.

Read the privacy policy