How to Share Passwords Securely

Everyone does it: a password gets pasted into Slack, emailed, or dropped in a chat. It works — until it doesn't. Those messages are permanent, searchable, and readable by the platform. A leaked credential is a breach waiting to happen.

Why chat is the wrong place

Slack, email, and messaging apps keep archives. A password sent today is still there in a year, indexed and searchable by anyone with access — including a compromised account or a subpoena.

The right way

Use an encrypted, burn-after-read link. The password is encrypted in your browser, the server stores only ciphertext, and the link self-destructs after one view. The recipient reads it once, and it's gone — no archive, no trace.

Best practices

1. Never send credentials in plaintext. 2. Use burn-after-read for anything sensitive. 3. Add an expiration timer as a safety net. 4. Rotate the credential after sharing, when possible. 5. Prefer a password manager's sharing feature for ongoing access.

The Password-Sharing Paradox

Passwords exist to authenticate one person to one system — yet real life constantly demands sharing: the Wi-Fi password for a houseguest, the shared streaming login for family, the service account credential a contractor needs for one job, the recovery passphrase a co-founder must hold. The paradox: the moment you share a password, you lose control of its copies. Every channel you might default to leaves residue — email lives on two mail servers plus both inboxes, SMS transits carrier infrastructure and syncs to cloud backups, chat DMs persist in searchable archives. Verizon's 2024 Data Breach Investigations Report attributes 68% of breaches to the human element, with credential misuse and phishing leading — and sloppy sharing is how credentials get into phishable, searchable places.

The Correct Stack: Password Manager First

For sharing with people you share many credentials with — a spouse, a team — the right tool is a password manager with built-in sharing: Bitwarden organizations, 1Password shared vaults. These keep the credential encrypted end-to-end, sync updates (rotate once, everyone has the new one), and revoke access cleanly. If your problem is recurring sharing, fix the root cause: make a shared vault. The one-off-secure-link approach below is for everything else — the recipient without your password manager, the credential you must hand off exactly once, the emergency access scenario.

One-Time Links for One-Off Shares

For the truly one-off handoff: paste the password into a zero-knowledge pastebin with burn-after-read (e.g., Urlpaste). The browser encrypts with AES-256-GCM, the key rides in the URL fragment, and the server holds only ciphertext deleted on first view. Compose the handoff deliberately: send the link over Signal or a work E2EE channel — never in the same message as the username or the system it unlocks. Splitting context across channels means a single intercepted conversation yields a useless link. Have the recipient confirm receipt, then — if the password is meant to be permanent — both parties store it in their password managers and the link, now burned, ceases to exist.

One more habit worth keeping: if the link you're about to open came from an unknown sender, run it through expandir.link first — it expands and checks URLs for phishing before you click. A password handoff is only as safe as the link you actually open.

Rules That Prevent the Classic Disasters

  1. Never put the password in the same message as the link, the username, and the service name — that message is a complete key.
  2. Never email passwords. Email is plaintext at rest on multiple servers, forwarded unpredictably, and the first place attackers search after a mailbox compromise ("password" in mail search is their literal playbook).
  3. Rotate after the need ends. The contractor's engagement ends → change the password. Burn-after-read limits exposure in transit; rotation limits it over time.
  4. Assume the recipient's device is the weak link. Their phone backups and chat history are outside your control — another reason delivery should be one-shot and storage should be in their password manager, not their messages.

FAQ

Is it safe to send a password over WhatsApp or Signal?

Signal is safe for the transit hop — it's properly end-to-end encrypted. WhatsApp is E2EE in transit but cloud backups may be unencrypted depending on settings, leaving a server-side copy. Either way, the message persists in chat history forever; for passwords, prefer a one-time link so the artifact self-destructs after delivery.

Why not just tell someone the password on a phone call?

Verbal handoff is genuinely good — no persistent artifact — and fine for short, human-typeable passwords. But it fails for the long random passwords you should be using (imagine dictating k9$Vb2!xR7... ), it requires synchronous availability, and it tempts people to choose shorter, dumber passwords. A one-time encrypted link handles strong passwords asynchronously.

What should I do if I already emailed a password?

Assume it's compromised: change the password now, then delete the email (while accepting it still lives in backups and the recipient's mailbox). Going forward, use your password manager's sharing for recurring shares and a burn-after-read encrypted paste for one-offs — and never send the link and the password context in the same message.