Most onboarding tools ask you to "trust them" with your clients' passwords. We do not want your trust; we want to be mathematically incapable of seeing your data.
Here is the exact lifecycle of a Keze request link:
Before your data ever leaves your device, your browser utilizes the Web Crypto API to generate a single-use, cryptographic key (AES-256-GCM). Your credentials are locked and encrypted locally, right on your screen.
When you generate a link, Keze only receives the locked vault (the ciphertext) and an Initialization Vector. We never receive, see, or store the decryption key. Our edge servers are completely blind to the plaintext contents of your payload.
This is where traditional forms fail. Instead of storing the key in our database, the decryption key is cryptographically bound directly to the unique URL provided to you. Using isolated client-side routing, the key is separated from the network request. This ensures that network logs, email scanners, and even our own database cannot access or intercept the key.
When your client clicks the link, their browser requests the locked vault from our server. It is delivered, and the client's browser uses the isolated key from their local URL to decrypt the credentials instantly on their screen.
The exact millisecond our server delivers the locked vault to the client, the database record is permanently purged. We do not archive it, we do not soft-delete it, it is gone. If a link-preview bot, a hacker, or anyone else tries to click that link a second later, the data no longer exists.
| Platform | TRULY Zero-Knowledge? |
|---|---|
| Keze | Yes |
| Password.link | Yes |
| 1Password | Yes |
| Bitwarden | Yes |
| Dashlane | Yes |
| Password Pusher | No |
| NordPass | Yes |
| Keeper | Yes |
| Infisical | Yes |
| Doppler | No |
| Vaulty.tools | No |
| AgencyAccess | No |
| LastPass | Yes* |
*LastPass' architecture famously left metadata unencrypted, leading to massive exposure during their breach