Security

Decoupled identity

Every user is identified internally by a randomly-generated UUID, not by your email or any value derived from your real identity. The financial tables store that UUID; the email column on the users table is encrypted (see layer 2). Linking a UUID back to a real person requires both database access AND the encryption key — which is stored separately, outside the database.

For deterministic email lookup at sign-in we also store an HMAC-SHA256 hash of your email; the HMAC secret lives outside the database, so a database breach cannot turn the hash back into your address.

PII encryption

Every personally identifiable field — account names, institution names, owner names, and bank connection tokens — is encrypted with AES-256-GCM before it touches the database. Each value gets a unique random initialization vector and a tamper-proof authentication tag. Each ciphertext is also bound to its row identity (table, row id, column) via AES-GCM associated data, so an attacker with database write access cannot move an encrypted value from one row or column onto another.

AES-256-GCM is the same standard used by governments and financial institutions worldwide. The “GCM” part means any tampering with the encrypted data is detected automatically.

Credential isolation

Your bank login never enters our system. Connecting an account is handled by Finicity (a Mastercard company) or MX — the bank-data networks that securely link your accounts — never by a form on Torv. Torv receives only an encrypted access token and read-only data. We never see your username or password, and we cannot log into your bank or move money.

Database-level tenant isolation

Even if application code forgot to filter a query by user, the database itself would reject it. The application connects to Postgres as a restricted role (torv_app) with row-level security enforced on every table that holds user data. Each request sets the active user’s pseudonymized ID as session context; the database returns only rows tagged with that ID.

A second role (torv_admin) is reserved for trusted background jobs (sync, cron) where there is no user request to scope to, and is never bound to a request that originates from a browser.