Security, in plain language

This page summarizes Cellar's security design. The full document, with the threat model and every control's test status, will be public before launch. Until then, this page and that document must agree. If they don't, the document is right and this page is a bug. Tell us.

The claim, and its four limits

Your stored transaction history is sealed to a key that only your devices hold. Cellar's servers store it and send it back to you, but they cannot open it. Neither can someone who steals our database or backups, our cloud provider, or someone who compels us to hand over what we've stored.

That's not end-to-end encryption, and we don't call it that. Four things stay true:

1. New data, and the bank token. To sync with your bank, our servers fetch your new transactions and hold them in memory while the sync runs, usually for seconds, before sealing them to your key. They also hold the token that lets them fetch from your bank. So someone who took over our servers, or compelled us, could capture new transactions as they arrive, and could use that token to download again whatever your bank still provides, up to two years of history, depending on your bank. Disconnecting your bank revokes the token and closes both.
2. The app we serve. The web app and the Excel add-in are served by Cellar. Someone who took over our servers, or compelled us, could ship a modified version that reads your key the next time you open it, and that exposes what's already stored. A client that doesn't load its code from us would avoid this. Cellar doesn't offer one yet.
3. Your spreadsheet is yours. Data you pull into Excel is unencrypted in that file. If it's a OneDrive workbook, Microsoft can read it.
4. Not quantum-resistant yet. The key exchange (X25519) is not post-quantum. Someone who copies the sealed data today could open it if a large enough quantum computer is ever built. We'll move to a post-quantum format once audited implementations are available.

Cellar will run on AWS. Amazon will see only sealed data at rest, but it operates the machines where sync happens, so point 1 applies to Amazon too.

What we can see, and what we can't

Visible to us

Which banks and brokerages you've connected, and whether each connection is healthy, when its consent expires and when it last synced.
How many connections and accounts you have, and a count of accounts by type: checking, savings, credit, brokerage, loan or other.
Sync history: what kind of job ran, whether it succeeded, when it started and finished, how many attempts it took, the bank's error code (never the error text) and how many rows it added or dropped.
When your bank's notifications arrived and whether we processed them.
A log of who did what and when: the event, who did it, the time, the table and column names and the number of rows. It contains no values.
How many users the account has, when you last signed in and how many sessions are active.

Sealed to your key

Transaction amounts, dates, descriptions, merchants and your notes.
Balances, account names and the last four digits of account numbers.
Your category names and rules.
Holdings.

What that gives away, said plainly

Which banks you use. Our tools need the institution to find sync problems, so it isn't sealed.
How busy your accounts are. Row counts show roughly how much you transact, and roughly when your accounts sync. They don't show what any transaction was or when it posted.
Your email address. It's stored unencrypted, so someone who steals our database or a backup can read it. Our operator tools don't read it.
A few bookkeeping fields next to each sealed record. Sealing covers the content, not the row around it. Someone who holds a stolen database or backup can see, for example, which account a record belongs to, whether it's pending and when it was stored. That shows how many transactions each account has, not what any of them says. Our operator tools don't read these fields row by row.

Your keys

When you set up Cellar, your browser makes a key pair. We store the public half. The private half stays on your devices. We hold only copies of it sealed to your devices and to your recovery code.

To add another device, you approve it from a device you've already unlocked, after comparing an eight-word safety code that both screens show.

You get a 12-word recovery code, shown once. Lose every device and the code, and nobody can open your stored history, including us.

Your bank connection

You log in on your bank's own site and approve the connection there. We never see your bank password. We hold an encrypted token that lets us fetch new data. Disconnecting your bank revokes it.

Isolation between customers

Every table is scoped to its customer by the database itself (row-level security). Our own operator tooling uses a separate, read-limited database role.

What we don't claim

We're not zero-knowledge.
We're not end-to-end encrypted.
We don't say "we never see your data". Our servers see new transactions while a sync runs.
No protection from our hosting provider at sync time.
No detection yet if the web app we serve were modified.
Not post-quantum yet.
No recovery without your recovery code.
No third-party audit or certification yet.

Reporting a vulnerability

Email security@cellarmoney.com. We'll acknowledge within 72 hours. We're pre-launch and don't run a bug bounty. Our security.txt has the same details.