MoatKey Security
Updated October 1, 2026
Where we stand today
- So far, MoatKey has had internal review only.
- An independent security audit has not happened yet. We plan one and will publish a summary when it is done.
How MoatKey protects your data
- Your master password never leaves your device.
- An account key is derived on your device with Argon2id. It wraps your vault key.
- Records are encrypted on your device with XChaCha20-Poly1305 before upload.
- Shared vaults ("Castles") use a separate key per Castle, sealed to each member with a hybrid of X25519 and ML-KEM-768 (FIPS 203).
- Castle key changes are signed by the owner with ML-DSA-65 (FIPS 204), and members' apps refuse unsigned changes.
- Our server stores ciphertext, public keys and the metadata needed for access control. It never holds a key that can open your vault contents.
- Safety numbers let members check each other's keys.
Some data is not encrypted, for example Castle names, record types, timestamps and your email address. The Privacy Policy lists all of it.
Step-by-step guides to recovery, safety numbers, the Dungeon and unlock options are in the MoatKey Help Center.
Reporting a vulnerability
Please email support@g3nosystems.com with "MoatKey security" in the subject. A machine-readable contact is at /.well-known/security.txt.
Helpful things to include:
- what you found and where;
- steps to reproduce it;
- what an attacker could do with it;
- the version of the app or extension, and your browser or phone.
Please use test accounts and synthetic data only. Don't include real passwords or other people's data in your report.
In scope
- The MoatKey browser extension for Chrome and Microsoft Edge.
- The MoatKey Android app.
- The MoatKey backend on Supabase as configured by us: database access rules, stored functions, authentication settings and edge functions (for example billing webhooks and checkout).
- The cryptographic design and how the clients implement it.
Out of scope
- Social engineering or phishing of our staff or users.
- Denial-of-service or load testing.
- Physical attacks on devices.
- Bugs in Stripe, Google Play or Supabase themselves (please report those to them; our own misconfiguration of those services is in scope).
- Attacks that need a device that is already fully compromised.
- Spam, rate-limit or missing-best-practice reports without a clear security impact.
Safe harbor
If you act in good faith and follow this policy, we will not take legal action against you for your research, will not ask law enforcement to act against you, and will treat your research as authorized under our Terms of Service. To stay within safe harbor:
- only test against accounts you own or have permission to use;
- don't access, change or delete other people's data, and if you reach real user data by accident, stop and tell us;
- don't disrupt the service for others;
- give us reasonable time to fix the issue before you publish details.
This safe harbor cannot bind third parties such as Stripe, Google, Supabase or app stores.
What to expect from us
These are targets, not guarantees:
- acknowledge your report within 2 business days;
- give a first assessment within 7 days;
- aim to fix critical issues within 30 days and others within 90 days;
- keep you updated, tell you when a fix ships, and credit you publicly if you want.
Please wait until a fix is released, or 90 days have passed, before public disclosure. We can agree on a different timeline together.
Bug bounty
We don't have a paid bug bounty yet. We are grateful for reports and will credit researchers who want credit.