Security
Designed so that we cannot see your passwords.
Vault contents are encrypted and decrypted only on your devices. This page explains how, exactly what the server sees, and the design's limits. We do not pretend the product does what it cannot.
Core principles
Zero knowledge
Every secret sent to the server is encrypted. Nobody at the server can read passwords, notes, item titles, addresses, usernames or SMS contents.
libsodium only
We do not write our own encryption schemes. All cryptography is done with the widely reviewed libsodium library.
A signed chain of trust
Who holds which key is verified by signatures starting from the organisation's root key; the server cannot add a fake member.
A record that cannot be changed
Access and changes enter a chained audit log; entries cannot be updated or deleted.
Secure by default
A new vault is shared with nobody, a new member can reach nothing, a new code channel is open only to its creator.
No outside scripts
The web app and the extension load no outside scripts, fonts or analytics; they run under a strict content security policy.
Transparency
What the server sees and does not see
This table is the product's security statement. If it changes, the change is tied to a decision record and disclosed to you.
| Data | Server sees it? | Note |
|---|---|---|
| Password, TOTP seed, secure note, custom fields | No | Encrypted with the item key |
| Item title, address, username, tags | No | Encrypted with the vault meta key |
| Vault name | No | Encrypted with the vault meta key |
| SMS sender, body, code | No | Sealed to the channel's public key |
| Master password | No | Only a hash of the derived authentication key |
| Recovery kit | No | |
| Member name, e-mail, role, status | Yes | |
| Group name, channel name, line label, sender rules | Yes | Configuration |
| Item type, category, criticality, whether it has a TOTP and a password | Yes | To raise warnings and tasks |
| Who accessed which item, when and for what purpose | Yes | The product's function |
| Which channel received a message when, and who opened it | Yes | |
| Vault, item and message counts and sizes | Yes | |
| Items a member marked as favourites (IDs) | Yes | A personal preference; the content stays encrypted (K-037) |
| IP address, browser details | Yes | For the audit |
| TOTP secret for signing in | Yes (encrypted with the server key) | The server has to verify it |
| Integration tokens | Yes (encrypted with the server key) |
Key hierarchy
From your master password to an item in a vault.
Your master password becomes a master key on your device with Argon2id. Two keys derive from it: an authentication key that proves who you are to the server, and a wrapping key that opens your user key. The master password and master key are never sent anywhere.
Each vault has its own key, sealed separately to the public key of every member who can reach the vault. Each item has its own key too. When someone's access is removed, the vault key is due for renewal; once renewed, the old key cannot open new items.
Owners and admins can see vault names and item titles with the admin key; to see passwords they need a permission on that vault.
Account and session security
Master password rule
At least 12 characters and a sufficient strength score; a password derived from your name, e-mail or company name is refused.
Two-step sign-in
Sign-in with an app-based code; required for owners and admins, who can do nothing else until it is on.
Automatic lock
The vault locks when idle; decrypted data stays only in memory and is wiped on lock.
Devices and sessions
See which devices are signed in and end any session; changing the password ends the other sessions.
Recovery kit
Printed when the organisation is created, the kit opens the account of a member who forgot their master password. Whoever holds it can also open shared vaults; it belongs in a physical safe.
Bulk access warning
An account that opens or exports many passwords in a short time produces a security warning in the audit log.
Audit chain
Prove that the record was not changed afterwards.
Each audit entry carries the hash of the one before. The organisation's owners receive the chain's last entry by e-mail every day. Even if someone rewrote history in the database, the chain would no longer match the hash you hold.
You can verify the chain at any time, or export it as a file and check it offline with the command-line tool.
Ownership and complianceInfrastructure and development
Isolation between organisations
Every table carries the organisation id and the database filters with row-level security. Every new table comes with a cross-organisation access test.
Authorisation on the server
Every endpoint's permission is checked on the server and verified by an authorisation matrix test; hiding things in the interface is only a convenience.
No secrets in logs
Passwords, keys, tokens, ciphertext, e-mail and SMS contents never enter logs, error messages or metrics; request bodies are never logged.
Hosted in Türkiye
The cloud service's servers are in Türkiye; your vaults sit there encrypted.
Technical details: the cryptography used
| Purpose | Method | Details |
|---|---|---|
| Key from a password | Argon2id | 64 MiB memory, 3 passes, 16-byte salt; the password is normalised to Unicode NFC |
| Symmetric encryption | XChaCha20-Poly1305 | A random 24-byte nonce every time; associated data binds it to its object |
| Sealing to a public key | X25519 (sealed box) | Passing vault and channel keys to members |
| Signatures | Ed25519 | Role certificates, member certificates, grants and rule documents |
| Hashes and fingerprints | BLAKE2b | Key fingerprints, envelope hashes |
| Audit chain | SHA-256 | Each entry carries the hash of the one before |
Every platform (web, extension, server) passes the same test vectors; no cryptographic function is added without vectors.
Known limits
These are not defects; they are consequences of the design that should be stated honestly.
Is the "Use" permission a barrier?
No. To fill a password it has to reach the device; a modified client or the browser's developer tools can show it. The permission prevents accidental viewing and records the use.
Does someone who generates a code (TOTP) also get its key?
Yes. The device generates the code, so the key reaches the device. If someone who generated codes leaves, set up two-step verification on that account again.
Does the server see nothing at all?
It does not see content, but it does see metadata: who opened which item, when and for what purpose; when a code reached which channel; vault and item counts. The access map and offboarding rely on this record.
What can the server do together with a compromised account?
The signature chain stops the server from forging a permission on its own. But a malicious server working with a compromised member account could produce an unauthorised share. That is why every permission change is reported to the vault's managers and enters the audit log.
Why do I have to trust the web app?
The server delivers the web app's code; a malicious server could deliver code that leaks keys. As countermeasures there is a strict content security policy and packages with no outside scripts. For the highest assurance the store-signed browser extension and mobile app are recommended.
What if the recovery kit is stolen?
The kit is the organisation's escrow key; whoever has it can open the shared vaults. Keep it on paper in a physical safe; if you suspect someone else has it, create a new kit straight away.
Does renewing a key or a password protect the past?
No. A password the leaver has seen stays valid until it is changed. That is what the offboarding tasks are for.
What can a departing owner do together with the server?
In the short time before the organisation keys are renewed, a departing owner and a malicious server together could hand out a forged key handover document. That is why renewing the organisation keys is the first required task when an owner leaves; devices never go back to a key version below one they have seen.
Data protection (KVKK)
Because we cannot see vault contents, we do not know what you keep there. We process your employees' data (name, e-mail, IP, access records) on your behalf as a data processor. When an organisation is closed, its data is permanently deleted after 30 days and drops out of backups within 35 days.
The product records which account an employee reached and when; the invitation screen tells the employee this plainly.
Data protection noticeFound a vulnerability?
Write to us at [email protected]. We take no legal action against good-faith researchers; first answer within 3 business days.
Vulnerability disclosure policyMove your passwords to a vault that even we cannot see into.
Import your spreadsheet; the file is encrypted in your browser and reaches the server encrypted.