What it does not protect against
The eleven things the design does not defend, stated in full: the unlocked device, the delivered code, the host, owners and admins, metadata, and more.
These are the limits of the design, the same list the product README carries.
- An unlocked browser and the device it runs on. While your vault is unlocked, the keys are in that tab's memory. Malware on the device, or a browser extension allowed to read the page, can read what you can.
- The code the server delivers. The web application is loaded from the server you sign in to. Whoever controls that server can serve a modified application that captures your unlock password. It ships no third-party code, sets a strict content security policy and will publish the hash of every release's assets so that a change can be noticed, but a web client cannot prove to you that it is honest.
- The server host. Someone with control of the host can read the database-side keys and session tokens in the service's memory and see everything in item 5. Without your unlock password they still cannot decrypt a record.
- Your company's owners and admins. Owners hold the company's recovery key, so they can restore any member's access and can therefore read every record shared with members of that company. Admins hold the keys of the company's departments and teams, so they can read every record shared with a department, a team or the whole company, but not records shared only with individual people. Every member is shown this.
- Metadata. The server sees who belongs to which company, department and team, who shares which record with whom, record types, sizes, counts and timestamps, and when records are fetched. Names of records are encrypted; their existence is not.
- Someone who already read a secret. Removing a person stops their future access and rotates the record's key. It cannot make them forget a value they saw. Change the secret at its source.
- A restored old copy. Someone who can write to the database can put back an old version of a record. Your browser refuses a version older than one it has already seen, but cannot detect an old version it has never seen newer of.
- A weak unlock password. Anyone holding the database and the server's key file can try to guess your unlock password offline. Each guess costs a memory-hard key derivation, but a short or common password still falls.
- Your sign-in provider. A compromised identity provider can sign you in, but it cannot unlock your vault: the unlock password is separate and never leaves your browser.
- Files kept in an external object store. When a deployment stores files in TessariDB S3 instead of the database, those files carry the browser's encryption but not the database's second layer, and their removal follows that store's own lifecycle.
- Timing and traffic analysis, and future quantum computers against today's ciphertext. The key exchange is classical X25519 in this version; the format names its algorithms so it can move.
To report a weakness, write to security@tessaridb.com.