How Otter Teams protects your keys
Last updated 6 October 2026. Otter Teams asks you to store your team's production keys on a server we run. This page explains why that server can't read them, what it can see, what we defend against, where the limits are, and what happens to your keys if Otter goes away.
The short version
- End-to-end encrypted. Keys, their names, sites and key-map details are encrypted on your team's devices before they're uploaded. The server stores ciphertext and never holds the key to open it.
- You decide who joins. Nobody is added to a team, and no new device is trusted, until an admin compares a short code with that person out of band. That code check is what stops even our own server from slipping someone in.
- Leaving locks people out of new changes. Removing a member or device re-encrypts every shared key under a fresh team key.
- Your keys are never locked in. Owners and admins can export every key at any time, and we give 60 days' notice before any shutdown.
- Verify it yourself. The extension, where all of the encryption happens, is public on GitHub, with its tests and threat model.
- No independent audit. This is a young product built by one developer. Instead of an audit, the code is public so anyone can check it, and we fix what's reported.
How the encryption works
- Records: each shared key, together with its label, site, username and key map, is encrypted with AES-256-GCM under the team key. The encryption is bound to its team, vault, record, key version and revision, so the server can't move it, swap it or serve an old version unnoticed.
- Team keys: each device has its own P-256 signing and key-exchange keys, which are sealed inside your personal vault. The team key reaches each device wrapped to that device alone (ECDH P-256 with HKDF-SHA-256 and AES-256-GCM), and every wrap is signed by the admin device that made it.
- Who's on the team: membership is a hash-chained list of entries signed by admin devices. Every client replays and checks it against the team's first entry, so a forged admin or a spliced-in member is rejected.
- The activity log: copies, fills and edits are signed by the device that did them and hash-chained. Each device remembers the last log position it verified, so it notices if events are dropped or rewritten.
- Removing someone: a new team key is made for everyone who stays, every record and name is re-encrypted in a single transaction, and the server refuses writes made with the old key.
- Admins: admin actions need a two-step (TOTP) code on top of Google sign-in. If every admin loses their devices, a printed recovery kit can restore access, but only after a 24-hour hold that the other admins see and can cancel.
Every one of these steps is opened or verified a second time with OpenSSL in the test suite. A hostile server is simulated against the membership list and the activity log, with forged admins, entries spliced in from other teams, dropped or edited log events, and old keys served again. Each defence was checked by switching it off and confirming that a test fails.
What our server sees, and what it never sees
What we defend against
| If someone… | What stops them |
|---|---|
| breaches the server or its database | They get ciphertext. The team keys that would open it are only on members' devices. |
| controls the server and tries to add themselves to a team | Members and devices are added only by signed entries from admin devices, after a code comparison. Clients check every entry. |
| tampers with history: drops log events, serves an old key, moves a record | Signatures, hash chains and the last state each device remembers make it show up as an error, not as silent changes. |
| was removed from the team | The team is re-keyed. They can't read anything added or changed afterwards, and the server refuses writes made with the old key. |
| copied keys before leaving | No vault can stop that. Otter lists every key they could read, which ones they actually used, and where each is deployed, production first, so you know exactly what to rotate. |
| steals a sign-in session | A session is tied to one device and can't decrypt or sign anything. Admin actions also need that session's two-step code. |
| takes over an admin's Google account | Admin actions need the two-step code. Five wrong codes lock it for 15 minutes. |
| steals a printed recovery kit | It only works with that admin's Google account and two-step code, after a 24-hour hold the other admins can cancel. |
| is a website you visit | Web pages can't talk to Teams at all. Only the Teams page inside the extension, and the popup's Copy button, can. |
The limits, stated plainly
- The server sees membership and timing. It can't read what a key is, but it knows who is on a team and when a record was touched.
- The code comparison is the trust anchor. If an admin adds someone without actually comparing codes, a malicious server could substitute keys at that moment.
- A brand-new device trusts the history it's first given, until a code comparison or another member's view confirms it.
- Everyone on a team can read every key in it. There are no per-vault permissions yet.
- The activity log only covers use through Otter. Someone who has a key can paste it anywhere.
- The server can refuse service, and read-only after the trial is enforced by the server, not by cryptography.
- A compromised computer or browser is out of scope, as it is for every password manager.
Who runs it, and what if Otter goes away
Otter is built and run by one developer, Krishna Ganga. The Teams server runs on Cloudflare Workers with a Cloudflare D1 database; payments go through Dodo Payments. Here's what protects your team if Otter ever stops:
- Export any time. Owners and admins can save every shared key, decrypted on their own device, together with where each one is deployed, as a JSON file: open the team's Keys tab and choose Export all keys (Otter 0.6.2 and later). Each exported key shows up in the activity log as copied by them.
- 60 days' notice. If Otter Teams ever shuts down, every team owner gets at least 60 days' notice by email to export. This is in our Terms.
- Your personal vault never depends on our server. It lives on your device and keeps working without Teams.
- Deleting a team. Email us from your sign-in address and we'll delete your account or a team you own within 30 days.
Read the code
Everything that encrypts, signs and checks happens in the extension, and its source is public: github.com/KrishnaG1703/otter-vault. The README maps each claim on this page to the file that implements it, and you can run the tests yourself. It's published under the Functional Source License (FSL-1.1-ALv2): you can read, run and modify it, but not use it to build a competing product, and each version becomes Apache 2.0 after two years. The Teams server isn't published. The design treats it as untrusted, so none of these guarantees depend on it.
Testing and review
On every change, an automated suite runs unit, integration and attack tests. That includes cryptographic known-answer tests, OpenSSL cross-checks, fuzzing, the real server routes run against a database, and static analysis.
Otter has not had an independent security audit. These claims are ours: tested, but not checked by an outside firm. Instead, the extension's source is public, so security researchers and your own team can review exactly how your keys are protected. Every confirmed report gets fixed and credited.
Report a vulnerability
Email krishna091718@gmail.com with "otter vault security" in the subject. Please use made-up credentials only. We acknowledge reports within three days and credit you if you'd like. Machine-readable details are at /.well-known/security.txt.