Send a Password as a One-Time Link (Secure & Self-Destructing)
To send a password securely, create an encrypted one-time link: encrypt the password in your browser with AES-256-GCM, keep the key in the URL fragment (never sent to the server), share the link, and destroy the ciphertext after one view. Do not paste the password into email, Slack, Teams, or SMS — those channels retain searchable copies.
This guide covers the exact steps with VanishingVault, how the cryptography works, how one-time links compare to Bitwarden Send and Password Pusher, common handoff scenarios (contractor, new hire, guest Wi‑Fi), and when a password manager vault is the better tool.
How to Send a Password as a One-Time Link
Paste the password
Open VanishingVault and paste the password, API key, or credential. Your browser encrypts it with AES-256-GCM before anything is uploaded — only ciphertext reaches the server.
Copy the one-time link
You get a URL that includes a secret ID plus the decryption key in the fragment after #. That fragment stays in the browser and is never included in HTTP requests to the server.
Send the link (not the password)
Share the link over email, Slack, SMS, or any channel you already use. When the recipient opens it, their browser decrypts locally and the server deletes the ciphertext. The link then returns not found.
Why Not Email, Slack, or SMS?
Security auditors keep flagging the same channels because each one keeps a copy long after the handoff is done:
Stored in both inboxes, on mail servers, and in backup archives for years — even after you delete the message.
Slack / Teams
Indexed, searchable, and often exportable by admins. A credential shared months ago can still be found in history.
SMS / iMessage
Carrier and cloud backups; lock-screen previews can show plaintext. Fine for a link, not for the password.
Shared spreadsheets
No real access control, no burn-after-read, and often shared wider than intended.
Password Sharing Methods Compared
| Method | Encryption model | Self-destructs | Account needed | Risk |
|---|---|---|---|---|
| Email / SMS (password in body) | Transport only / none | High | ||
| Slack / Teams (password in chat) | Server-side (not E2EE) | High | ||
| Bitwarden Send | Client-side (AES-256) | Low | ||
| Password Pusher | Server-side (typical hosted) | Medium | ||
| VanishingVault | Client-side ZK (AES-256-GCM) | Low |
Bitwarden documents Send as AES-256 end-to-end encrypted with optional access passwords and expiry from 1 hour to 30 days. Password Pusher (open source) adds view limits and audit trails; hosted deployments typically encrypt at rest on the server rather than keeping the provider blind. Prefer tools that encrypt in the browser when the recipient is outside your org. If your threat model includes a stolen link, prefer a tool with an optional access password and send that passphrase on a different channel than the URL.
Common Handoffs: Contractor, New Hire, Guest
Client or contractor
They are outside your vault. Create a one-time link, email the URL, and confirm receipt on a call or separate chat. After they log in, rotate if the engagement ends.
New hire (day one)
Before a password-manager seat exists, send each first-day credential as its own one-time link. Move ongoing shared logins into Bitwarden or 1Password once onboarding completes.
Guest Wi‑Fi / family
Paste the Wi‑Fi key, text the link. No app install for the recipient. The message history keeps a dead URL instead of a forever-visible passphrase.
How the Encryption Works
- Client-side key: The browser generates a random AES-256-GCM key via the Web Crypto API.
- Encrypt locally: Only ciphertext (plus IV) is uploaded. The server never sees plaintext.
- Key in the fragment: The key is appended after
#in the share URL. Per HTTP rules, URL fragments are not sent to the server — so a database dump yields unreadable blobs. - Burn after read: On first successful retrieve, the ciphertext is deleted. Unopened links expire after a 7-day TTL.
For a deeper architecture walkthrough, see how we built zero-knowledge secret sharing on Cloudflare. For the broader sharing playbook, read how to share passwords securely.
When to Use One-Time Links vs a Password Manager
Use a one-time link when
- • Onboarding someone before they have a vault seat
- • Handing credentials to a contractor or client
- • Sharing Wi‑Fi or a guest login
- • One-off API key or DB password delivery
Use a password manager when
- • The team needs ongoing shared access
- • You need audit logs and role-based access
- • Both parties already have org accounts
- • Credentials must be rotated and revoked centrally
Best Practices
- Send the link, never the password — let chat and email keep a dead URL.
- Split channels when risk is high — send the link by email and confirm (or share an access passphrase) by phone or a different chat. Bitwarden documents this pattern for Send access passwords.
- Confirm the recipient — verify who should open the link before you paste it into a busy channel. The full URL is a bearer secret.
- Rotate after the handoff — change the password when a contractor finishes or someone leaves.
- Prefer unique credentials — generate a strong password for the account before you share it.
- Enable 2FA — a leaked password is far less useful without the second factor.
Frequently Asked Questions
How do I send a password securely?
Create an encrypted one-time link instead of pasting the password into email or chat. Encrypt in the browser (AES-256-GCM), put the decryption key in the URL fragment so it never hits the server, share the link, and destroy the ciphertext after one view. The channel only ever holds a dead URL after the handoff.
What is the safest way to send a password to someone?
A zero-knowledge one-time link is the safest practical method for a one-off handoff: client-side encryption, burn-after-read, and no recipient account required. For ongoing shared access inside a team, use a password manager vault share (Bitwarden, 1Password) instead of links.
Can the server see my password?
No — not with a true client-side (zero-knowledge) tool. The browser encrypts with AES-256-GCM before upload; the decryption key stays in the URL fragment after #, which browsers do not send to servers. The provider stores ciphertext it cannot decrypt. Avoid tools that only encrypt on the server with a provider-held key.
What happens after the recipient opens the link?
The ciphertext is permanently deleted from storage and the same URL returns not found. Nobody — including the sender — can retrieve it again. If nobody opens it, VanishingVault still expires unopened links after a 7-day TTL.
What if someone intercepts the one-time link?
Treat the full URL as a bearer secret: anyone who opens it first can decrypt. Mitigate by confirming the recipient out of band (call or separate chat), keeping the link out of public channels, and preferring tools with an optional access password (Bitwarden Send) when the threat model includes link interception. Rotate the credential if you suspect the wrong person viewed it.
Is it safe to send a password by text message (SMS)?
Not the password itself. SMS is not end-to-end encrypted across carriers, messages sit on carrier systems and device backups, and lock screens can display plaintext. SMS is fine for delivering a one-time encrypted link — never for the credential itself.
How do I send a password through email safely?
Never put the password in the email body. Create an encrypted one-time link and email that URL. The inbox then stores a link that dies after one view, not a live credential. For higher risk, send the link by email and a short out-of-band confirmation (call or separate chat) so interception of one channel alone is not enough.
Is it safe to send passwords over Slack or Teams?
Not as plaintext. Slack and Teams retain searchable history and workspace admins can often export messages. Paste a one-time link into the channel if you must use chat; never paste the password. After one view the link is dead and the chat log holds only an expired URL.
Can I share a password without a password manager?
Yes. A zero-knowledge one-time link needs no account on either side: paste the password, send the URL, and the recipient opens it once in any browser. That is the right pattern for guests, clients, and contractors who are not in your vault org.
How does a one-time password link work?
Your browser generates a random AES-256-GCM key, encrypts the password, and uploads only ciphertext. The key stays in the URL fragment after # — browsers do not send fragments to servers (HTTP). The recipient’s browser fetches ciphertext, decrypts locally, and the server deletes the blob so the link cannot be reused.
Bitwarden Send vs a dedicated one-time link?
Bitwarden Send is excellent if the sender already uses Bitwarden: AES-256 end-to-end encryption, view limits, optional access password, and expiry from 1 hour to 30 days (per Bitwarden’s product docs). Dedicated tools like VanishingVault need no account for sender or recipient, which is better for contractors and guests. Both beat email and Slack. Prefer client-side encryption over tools that only encrypt on the server.
How long does a VanishingVault password link last?
Links expire after the first view or after 7 days, whichever comes first. Once opened, the encrypted data is permanently deleted. There is no view-tracking notification — zero-knowledge design means the service does not retain accessor identity.
Send your next password as a one-time link
Encrypt in the browser, share once, and leave nothing searchable in Slack or email.
Create One-Time Password Link