1. How your account is protected
- Passwords
- Stored only as a bcrypt hash with a per-user salt. We cannot read your password, recover it, or send it to you — a reset link is the only route, by design.
- Two-factor authentication
- Available on every account from Settings. The shared secret is encrypted at rest. Turning it on is the single most effective thing you can do here.
- Session binding
- A signed session token is paired with a non-persistent browser marker. Copying the token out of your browser and into another does not produce a working session. This also enforces one active browser per account.
- Brute-force resistance
- Sign-in attempts are rate limited and an account locks out after repeated failures. Every failed attempt is recorded with the time and the originating IP address. That record is kept for support and investigation — there is no sign-in history screen in your account today, so if you need to know what happened on yours, ask us and we will read it back to you.
- Transport
- Every connection is TLS. Security headers, including a Content-Security-Policy, are applied at the edge on every response.
- Payments
- Settled in crypto through a third-party payment processor, which issues the deposit address, confirms the transfer on the public chain, and notifies us; if that notification never arrives we read the status of that same payment back from the processor. We hold no card number, bank detail, private key, or seed phrase — there is no store for them to leak from. What the processor receives is itemised in the Privacy Policy; the mechanism is described in the Subscription & Billing Terms.
2. What we ask of you
- Use a password you use on no other site. A manager makes this free.
- Turn on two-factor authentication.
- Do not share your credentials. Beyond breaking the Acceptable Use Policy, it is how most account compromises actually happen.
- Treat any email asking for your password as fraudulent. We will never ask for it, by any channel, for any reason.
If you think your account has been accessed by someone else, change the password immediately and tell us at our contact form. You can end every active session yourself from Settings → Active sessions, and we can look up the sign-in record for your account and tell you what it shows.
3. Reporting a vulnerability
We welcome reports from security researchers and we would much rather hear from you than from an attacker. Send your finding to our contact form with:
- the affected URL, endpoint, or feature;
- a description of the issue and its impact;
- reproduction steps, ideally the minimum that demonstrates it;
- any proof-of-concept — a screenshot or a request is usually enough.
What you can expect from us:
- Acknowledgement within 3 business days.
- An initial assessment within 10 business days, including whether we consider it in scope and how severe we think it is.
- Progress updates until it is closed, without you having to chase.
- Credit in our release notes if you want it, and silence if you do not.
We do not currently run a paid bounty programme. We will say so honestly rather than imply a reward that is not coming.
4. Safe harbour
If you make a good-faith effort to comply with this policy while researching, we will treat your research as authorised. Specifically, we will not bring or support a legal claim against you, and we will make it known that your actions were authorised if a third party brings one.
Good faith means, concretely:
- Stop as soon as you have confirmed the issue. Do not pivot deeper, and do not test how far it goes.
- Use only your own account and your own data. If you reach someone else's data, stop immediately, do not save it, tell us, and delete anything you already retrieved.
- Do not degrade the service: no denial-of-service testing, no automated scanning that generates significant load, no spam of real users.
- Do not use social engineering, phishing, or physical access against our staff or providers.
- Give us a reasonable window to fix it before publishing — 90 days is our default, and we will ask for an extension only if we can explain why. We will not use the window to stall you.
- Do not extort. A report conditioned on payment is not a report.
Report in good faith and get the scope wrong, and we will tell you it was out of scope — not treat you as an attacker.
Out of scope
These are generally not accepted, because they cost us more to triage than they protect anyone:
- Reports generated by a scanner with no demonstrated impact.
- Missing headers or cookie flags with no exploitable consequence.
- Email configuration findings (SPF, DKIM, DMARC) with no proof of spoofing.
- Rate-limit findings on unauthenticated public marketing pages.
- Self-XSS requiring the victim to paste code into their own console.
- Vulnerabilities in third-party services — report those to their owner.
- Anything requiring a rooted device, a compromised browser, or physical access.
5. If a breach happens
We will tell affected users what we know as soon as we know it is real, rather than waiting for the investigation to close. Where the law sets a notification deadline for the relevant authority, we meet it. Our commitment is to say what happened, what data was involved, what we have done, and what you should do — in that order, in plain language.
6. Related
Privacy Policy for what data exists to be protected; Acceptable Use Policy for the boundary between research and an attack.