Send a Password as a One-Time Link (Secure & Self-Destructing)
To send a password securely, create a client-side encrypted one-time link: encrypt with AES-256-GCM in your browser, keep the key in the URL fragment, share the link — never the password — and let the ciphertext burn after one view.
This guide covers the exact steps with VanishingVault, bearer-URL semantics, how Slack and email unfurls can burn a one-view link, a focused comparison vs Bitwarden Send and email, and when a password-manager vault is the better tool. Related: how to share passwords securely · best one-time secret sharing tools · is Slack encrypted? · zero-knowledge encryption.
How Do You Create a Secure Password Link?
Paste the password at the create page
Open VanishingVault (no account required). Paste the password, API key, or credential. Your browser encrypts it with AES-256-GCM via the Web Crypto API before anything is uploaded — only ciphertext reaches the server.
Copy the full one-time URL
You get a URL with a secret ID in the path and the AES decryption key in the fragment after #. That fragment stays in the browser and is never included in HTTP requests to the server — this is what makes the design zero-knowledge.
Send the link — never the password
Share the complete URL over email, Slack, SMS, or any channel you already use. When the recipient opens it and clicks Reveal, their browser decrypts locally and the server deletes the ciphertext. The link then returns not found.
Confirm receipt and watch for unfurls
Verify the recipient opened the link (call or separate chat). If the channel auto-previews URLs, send the full link out-of-band — Slack, Teams, and mail clients can fetch the URL and burn a one-view secret before a human clicks.
Why Shouldn't You Send Passwords via 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.
What Is a Bearer URL — and Why Does It Matter?
A one-time password link is a bearer secret: whoever opens the full URL first can decrypt the credential. There is no username check, no “only Alice can view this” gate after the link is created. That is by design — it keeps friction low for contractors and guests — but it means:
- An intercepted link (shoulder-surfed, forwarded, or opened by a preview bot) gives the secret to whoever got there first.
- You cannot revoke access after the burn — the ciphertext is gone.
- Confirming the intended recipient out of band (call, separate chat) is part of the security model, not optional polish.
Mitigate bearer risk with an optional access passphrase (Bitwarden Send supports this natively; VanishingVault supports an optional second secret shared on a different channel). If you suspect the wrong person viewed the link, rotate the credential immediately.
Can Slack or Email Link Previews Burn Your Password Link?
Yes. Slack, Microsoft Teams, Discord, LinkedIn, and many mail clients fetch URLs to generate link previews (unfurls). If that automated GET triggers burn-after-read, the secret is destroyed before your recipient clicks — and neither of you gets a clear error.
What to do: use tools with an explicit Reveal step so the first fetch loads a landing page, not the secret. Post “credentials coming separately” in the unfurling channel and paste the full URL in a DM, SMS, or phone call. See is Slack encrypted? for why chat is the wrong place for credentials even when you only paste a link.
One-Time Link vs Bitwarden Send vs Email — Which Fits?
| Method | Encryption model | Best for | Honest limit |
|---|---|---|---|
| VanishingVault | Client-side ZK (AES-256-GCM, key in # fragment) | One-off handoffs to guests, contractors, or clients — no account on either side. | Bearer URL; text secrets only; no view-tracking notification (ZK design). |
| Bitwarden Send | Client-side AES-256 (same vault crypto) | Teams already on Bitwarden; optional access password + file Sends on paid plans. | Sender needs a Bitwarden account; heavier UX for a single quick link. |
| Email (password in body) | Transport TLS only — stored plaintext in inboxes | Nothing involving credentials. Email a one-time link URL instead. | Permanent searchable copies in both inboxes and mail-server archives. |
Full tool roundup: best one-time secret sharing tools. Vault vs link decision tree: how to share passwords securely.
How Do Other Password Sharing Methods Compare?
| 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 Does the Encryption Work?
- 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 zero-knowledge basics, read what is zero-knowledge encryption?. For the broader sharing playbook, read how to share passwords securely.
When Should You Use a One-Time Link 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
What Are the Best Practices for Sending Password Links?
- 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.
- Watch link unfurls — Slack/Teams preview fetches can consume burn-after-read. Prefer an explicit Reveal page, or avoid pasting the raw URL into channels that auto-unfurl.
- 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.
Will Slack or email link previews burn my one-time password link?
They can. Slack, Teams, and many mail clients fetch URLs to build unfurls. If that GET counts as a view, the secret is gone before your recipient clicks. Prefer products with an explicit Reveal / retrieval click so automated fetches do not consume burn-after-read. Practical workaround: message “sending credentials separately” in the unfurling channel and paste the full URL in a DM, SMS, or call notes that do not preview.
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