Request and share passwords and credentials securely
Request passwords, API keys and logins through a one-time, end-to-end encrypted link. The server never sees the plaintext.
Encrypted locally in your browser One-time reads No account needed Open source
Stop asking clients to send passwords by email.
Three ways Vault replaces the unsafe handoffs you do every week.
Request credentials securely
Generate a one-time request link. The other person encrypts the secret to a keypair that lives only in your browser. You receive ciphertext, never a password by email.
Share secrets with a one-time link
Encrypt in your browser, share a self-destructing link. The first read hard-deletes the secret server-side. No copy lingers in inboxes or chat history.
Verify the code and deployment
Every line of crypto is AGPL-3.0 on a public mirror. The status page exposes the deployed commit SHA and the SHA-256 of the browser bundle you can recompute yourself.
Secrets for AI agents: vault-ask
Your coding agent needs an API key or a database password? With vault-ask you enter the value in your browser, and it goes only to the one command you saw. Via CLI or MCP server, bound to its purpose and masked in the output, so it never lands in the chat or the session log.
Encryption and decryption happen in your browser via the native WebCrypto API. The key lives in the URL fragment and never reaches us.
Structurally there is no plaintext for us to leak, subpoena or lose.
AES-256 Authenticated GCM encryption
X25519 Key exchange per request
0 Plaintext bytes on the server
Request a secret without ever seeing it in plaintext
The request flow is what makes Vault different. Stop asking clients to email or Slack you their passwords.
Create the request
Your browser generates an X25519 keypair locally. The private key never leaves your device.
Share the request link
Send the link to the person who has the credentials. Email, chat, or even paper - the server never sees the key.
They submit the secret
Their browser encrypts the secret against your public key and uploads only ciphertext.
You collect it encrypted
Open your retrieval link. Your browser decrypts locally. Server-side plaintext exposure: zero.
The whole request in twenty seconds
Create the request link, the other person submits, you retrieve it once. Recorded on vault.erseni.com in one take; the interface in the clip is German.
What it looks like
Three steps. No account. No plaintext on the server.
Built for real credential handoffs
The same flow that protects a one-off password protects every recurring credential handoff in your day.
Agencies collecting client logins
Send one request link instead of chasing the client across three email threads. Nothing lands in your inbox in plaintext.
Developers sharing API keys
Hand over a Stripe key, GitHub PAT or AWS credential without leaving a copy in Slack or git history.
Support receiving sensitive data
Customers send 2FA backup codes, photo IDs or licence keys through a one-time link instead of a ticket.
Freelancers onboarding clients
Collect logins for legacy systems your client cannot wrap in SSO. Encrypted at their browser, decrypted at yours.
DevOps temporary credentials
Hand a colleague a short-lived production credential during an incident. The link expires, no cleanup forgotten.
Internal teams sharing secrets
Stop pasting passwords in shared docs. One-time link, hard-deleted after the first read, audit-friendly.
The first successful read hard-deletes the record server-side before the response even leaves the machine. No copy is left in inboxes or chat history, and server backups hold at most unreadable ciphertext until they are overwritten after 7 days.
Open the same link again and all you get is "expired".
Built in the open, verifiable end to end
Six properties we hold ourselves to. Each one is reviewable in the public source.
Zero-knowledge by design
The server only ever stores your secret as ciphertext. The decryption key lives in the URL fragment and never reaches us.
Browser-side encryption
AES-GCM-256 and X25519 run via the browser-native WebCrypto API. No third-party crypto library, no plaintext on the wire.
URL fragment key separation
Browsers never send the part after # in HTTP requests. We put the key there on purpose, so the server is structurally unable to see it.
Open source, public mirror
Every line that runs your secret is AGPL-3.0-licensed and pushed to a public GitLab mirror. Read it, fork it, self-host it.
Deployed build verification
The status page exposes application commit, component commit, mirror commit and the SHA-256 of the bundle delivered to your browser.
Documented limitations
We list what this design does not protect against, including JavaScript-delivery risk and metadata leakage. No absolute-security claims.
Why not just use OneTimeSecret, Password Pusher, PrivateBin or Bitwarden Send?
Based on public documentation and source code at the time of publication. Different tools optimise for different threat models. This comparison focuses on browser-based, one-time credential handoff.
One boundary we name ourselves: an optional note you attach to a secret in the dashboard is stored in plain text. The secret itself we can never read.
Sources
Each claim is verifiable against the linked competitor source. If a value is out of date, open an issue on the public mirror and we will correct the table.
OneTimeSecret (GitHub) Server-side encryption with a server-held key; the optional passphrase is not the default path. Incoming Secrets (version 0.26.0, released 19 July 2026) is a drop-off page on a DNS-verified custom domain, so it is not a targeted request to a specific person, and it requires an account on the collecting side; sending works without one. Open source and self-hostable. For the server-side encryption we follow the project's own description; we have not verified it against its source code.
Password Pusher (GitHub) Server-side encryption with a server-held key; not zero-knowledge by design. Offers an inbound Requests feature, but uploads use the same server-held key, so the request flow is not zero-knowledge. Apache-2.0 licensed, self-hostable, no account required.
PrivateBin (GitHub) In-browser AES-GCM encryption with key in the URL fragment, server stores ciphertext only. Zlib license, self-hostable, no account.
Bitwarden Send FAQ Server-side encrypted with an account-derived key; recipients use a one-time link. The Send feature requires a sender account. Server is AGPL-3.0; the official UI client and apps ship under a custom licence with proprietary components, hence the "partial" mark on open-source.
Verify our code
Trust is earned by being verifiable. The backend and the browser crypto are published under the AGPL-3.0 license.
Source: gitlab.erseni.net/open-source/secrets-component
Threat model: docs/architecture.md
Current build: status page lists the deployed commit SHA. Compare against the public mirror to verify.
Pricing
Free to use, with no limit on how much you send. No account. No tracking. No ads.
Business is available now, and you can invite team members. Questions? Email hello@erseni.com.
Share your next secret the safe way
No account, no plaintext, no trace. End-to-end encrypted in your browser and destroyed on first read.