Sooner or later everyone has to hand someone a password: a new hire's starter credentials, a client's WordPress admin, a Wi-Fi key, a database connection string. Most people paste it into email or Slack and hope for the best. That copy never really goes away.
What is the safest way to send a password?
The safest way to send a password is a one-time secret link: the password is stored encrypted, the recipient opens the link exactly once, and the content is destroyed on first view. Add a short expiry and a passphrase delivered through a second channel, and the URL left sitting in email or chat is useless to anyone who finds it later.
The rest of this guide ranks the common methods and explains when each one is acceptable.
How do the common methods compare?
| Method | Copy left behind? | Can you revoke it? | Audit trail? | Verdict |
|---|---|---|---|---|
| One-time secret link (burn-after-read) | No — destroyed on first view | Yes, before it's viewed | Yes | Best default for hand-offs |
| Shared vault in a password manager | Yes, by design (managed) | Yes | Yes | Best for long-lived team credentials |
| Phone call / read it aloud | No | N/A | No | Fine for one password; doesn't scale, typos happen |
| SMS | Yes, on both phones and the carrier | No | No | Avoid — SIM-swap and shoulder-surf risk |
| Yes, indefinitely, on multiple servers | No | No | Avoid for the password itself | |
| Slack / Teams / chat | Yes — searchable history, admin-visible | Sometimes (delete), copies remain | Partial | Avoid for the password itself |
Why are email and chat the worst options?
Because both are retention systems. Email lives on the sender's server, the recipient's server, backups of both, and every device that synced it. Chat history is searchable by anyone who later joins the channel and by workspace admins. A password pasted there is effectively published to your future attacker — breaches of email accounts routinely harvest credentials sent years earlier. URLs and message bodies also leak through forwarding, screenshots, and compliance exports. (Related: why URLs leak sensitive information.)
How does a one-time secret link fix this?
A burn-after-read link changes the lifetime of the secret from "forever" to "one view":
- You paste the password into a secret-link tool and get a URL.
- You send the URL through any channel — the channel now only ever holds a pointer, not the secret.
- The recipient opens it once; the payload is revealed and then irreversibly destroyed. Anyone finding the URL later gets a "burned" page.
Done properly, the reveal is atomic (a database row lock ensures two simultaneous viewers can't both read it) and link previews from Slack or email scanners don't trigger the burn — only an explicit reveal click does. We wrote up the mechanics in how one-time secret links work.
Three hardening steps worth taking every time:
- Short expiry. If the recipient doesn't open it within an hour or a day, it dies anyway.
- Passphrase, sent out-of-band. Link by email, passphrase by SMS or a quick call. An intercepted link alone is then worthless.
- Watch the audit trail. If the timeline shows a view you didn't expect, rotate the credential immediately — you just detected an interception you'd otherwise never know about.
You can create one right now with LinkPilot's [free secret link generator](/tools/free-secret-link-generator) — no signup required — or compare tools like OneTimeSecret, Password Pusher, and PrivateBin in our best OneTimeSecret alternatives roundup. If you're choosing between this approach and a vault, see secret links vs password managers.
When should you use a password manager instead?
When the credential is long-lived and shared inside a team, a password manager vault is the right home: it stays updated in one place, access is role-based, and rotation is manageable. One-time links and vaults are complements, not competitors — the link is for the hand-off moment (a contractor, a client, a new hire's first login), the vault is for ongoing storage. The anti-pattern is using chat or email for either job.
A sensible default policy for teams
- Passwords, API keys, tokens, connection strings: one-time secret link, short expiry, passphrase out-of-band. Never raw in chat or email.
- Long-lived shared credentials: team vault.
- Anything already pasted into chat or email historically: rotate it when you touch it next.
That's the whole policy. It fits on a sticky note, and it removes the single most common way credentials leak from small teams.