Security & Privacy

The short, plain-English version

Can the team running this site see my financial data?

No — not by ordinary means. Your balances, valuations, incomes, date of birth and (optional) account numbers / sort codes, are encrypted before they're written to the database. If the developer opens the database directly, they see scrambled ciphertext, not your money. Decoding it needs a separate secret key that lives in a different, locked-down system.

The honest caveat: encryption protects against database theft, leaked backups, and casual browsing from the development team. A determined site administrator who deliberately combined the database and the key could decrypt — that's true of every hosted service.

What about my password?

Your password is never stored. We only keep a one-way mathematical fingerprint (a BCrypt hash). Nobody, including the developer, can recover it — the only option if you forget it is to reset it via your email.

Can I add a second factor?

Yes. You can turn on optional two-factor authentication from your Profile page. Once enabled, signing in needs both your password and a 6-digit code emailed to you. It's off by default — opt in when you want it.

Could someone else's family see my data?

No. Each family is walled off in the application code, so logging in as a member of family A never returns any data belonging to family B.

Is the connection safe?

Yes. All traffic between your browser and the server uses HTTPS — the same encryption your bank uses. The browser is told to refuse to talk to this site over plain HTTP.

What if I change my mind?

You can delete your family and every piece of data it contains, permanently, from Settings → Danger Zone. There is no "soft delete" — the rows are gone.

Is my data sold or shared?

Data is never sold. Nothing leaves the server except (a) the emails and texts the app sends you, and (b) anything sent to the optional AI advisor feature

Want the full technical detail? Jump to the deep dive ↓

Full security posture (technical detail)

For readers who want the technical detail behind the claims above.

Encryption at rest

• Financially identifying values — anything that says how much money you have, what an account is, or who you personally are (PPI) — are encrypted before being written to the database. A direct database read returns ciphertext, not values.
• The encryption uses an industry-standard authenticated cipher (AES-256 in GCM mode) with a fresh random initialisation vector per value, so identical plaintexts never produce identical ciphertexts.

Key management

• The encryption key is held in a managed secrets store in our cloud environment and fetched only at process start-up. It is never present in source control, environment variables, container images, or backups.

Encryption in transit

• HTTPS is required for every connection; plain-HTTP requests are redirected or refused.
• The site is published with an HSTS policy (Strict-Transport-Security) so that once your browser has visited once, it will refuse to connect over plain HTTP, even if a network attacker rewrites the URL.

Authentication

• Passwords are stored only as a slow, salted one-way hash (BCrypt). Plaintext passwords are never stored or logged.
• Repeated failed logins trigger both per-account lockout and per-source rate limiting, slowing brute-force attempts to the point of impracticality.
• Email-verification and password-reset links are single-use, short-lived, and use a two-step click-to-confirm pattern so that link-preview scanners can't accidentally burn the token.
• Optional two-factor authentication is available per account. When enabled, a successful password check triggers a 6-digit one-time code delivered by email; the session is only fully authenticated once the code is verified. Codes are stored as BCrypt hashes, expire after 10 minutes, allow at most 5 attempts, and enforce a 60-second resend cooldown.
• Users can mark a browser as trusted for 30 days to skip the second-factor prompt on that device. The trust marker is an HttpOnly, Secure, SameSite=Strict cookie scoped to the login path, stored on the server only as a SHA-256 hash, and individually revocable from the Profile page.

Sessions

• Short server-side idle timeout — you'll be logged out automatically after a period of inactivity.
• Session cookies are marked HttpOnly, Secure, and SameSite=Strict — inaccessible to JavaScript, never sent over plain HTTP, and not sent on cross-site requests, which neutralises most session-stealing techniques.
• Changing your password invalidates every other active session for your account.

CSRF

Every state-changing request must carry a synchroniser token tied to the user's session. Requests without a valid token are rejected before reaching any business logic, so a malicious site cannot make your browser submit a request to ours on your behalf.

Content Security Policy & HTTP headers

• A strict Content Security Policy restricts the browser to loading scripts and styles only from this site — no third-party scripts, no inline JavaScript. This is one of the strongest defences against cross-site scripting.
• Standard hardening headers are sent on every response: clickjacking protection (frame-ancestors 'none' / X-Frame-Options: DENY), MIME-sniff protection (X-Content-Type-Options: nosniff), and HSTS as above.
• Output from the optional AI feature is sanitised before it touches the page, so even a hostile model response cannot inject script.

Data isolation

Every database query made by the application is scoped to the authenticated user's family. There is no API path that returns rows belonging to a different family, and the schema's foreign-key relationships enforce the same boundary at the storage layer.

Backups & recovery

• An encrypted snapshot of the database is taken automatically every night and stored in a private, access-restricted bucket in our cloud environment.
• You can also export your own data to Excel at any time from the Backup & Restore page, and re-import it.

Operational guardrails

• Privileged events — backups, restores, family deletions, administrative actions — are written to an append-only audit log so unusual activity is visible after the fact.

What the operator can see, honestly

Encryption protects the data — names, money, everything personal. It does not (and cannot) hide the fact that you have an account. The operator can see:

• Your email address (used as your username) and your assigned role.
• When you signed up, when you last logged in, and from which IP address.
• Audit-log entries describing the type of action — e.g. "a user restored a backup at time Y" or "a user deleted their family". Any values associated with the action are themselves stored encrypted.
• Application error reports, which may include the URL you were on but not the sensitive field values submitted on it.

What the operator cannot see by reading the database is everything that identifies you as a person or describes your money: your first name, surname, phone number and family name; the names, dates of birth, tax bands, financial goals and notes of anyone in your family; and every account, asset, debt, valuation, balance, interest rate, charge, income and pension figure. All of those columns are ciphertext at rest without the key.