How to share a password without leaving a copy behind

If a coworker asks you for the staging database password, what do you do? Most people send it through whatever chat app is open: Slack, WhatsApp, iMessage, email. It feels casual. It also creates a permanent record of the credential in at least three places — and probably more, depending on how everyone has their devices configured.

This post is about why that's a problem, and what to do instead.

The leakage map

When you paste a password into a regular chat app and hit send, here's where copies typically end up:

• The provider's servers. Slack, Google Workspace, Microsoft, Apple, and Meta all store messages on their infrastructure. Even when transport is encrypted, the company can read the content (with a few exceptions like end-to-end encrypted iMessage or WhatsApp).
• Both devices' message history. Indefinite, unless someone manually deletes — and even then, often only locally.
• Cloud sync of those devices. iCloud Messages, Google Drive backups, Slack Enterprise archives. The password is now in another company's storage too.
• Notification systems. Push notifications often display the message body on lock screens. They get logged by Apple Push Notification service or Firebase Cloud Messaging in transit.
• Endpoint security tools. If either of you is on a managed work laptop, DLP and endpoint logging tools may have captured the message body.
• Screenshots and copy-paste. If your coworker copies the password, it sits in their clipboard, possibly synced via Universal Clipboard or Windows Clipboard History. If they screenshot it, that image is now in their photo library, possibly cloud-synced.

That's the situation for one casual "hey, here's the password" message. The credential exists in maybe ten places, owned by four different companies, indefinitely.

What "good" actually looks like

A safe credential transfer has three properties:

1. Ephemeral. The carrier of the secret destroys itself after one read, or after a short time window. There's no archive to leak.
2. End-to-end encrypted. Even the company providing the transport can't see the secret. They store ciphertext at most.
3. Out-of-band verification. The thing that decrypts the secret travels through a different channel than the encrypted blob, so a single compromised channel can't reveal everything.

Most "secure password sharing" tools cover (1) and (2). Few do (3) by default — but it's the most important one for high-value credentials.

The options, ranked

1. Say it on a phone call (or in person)

Sounds dumb. Actually one of the safest options for a one-off. Phone calls aren't archived by default on either side, and a voice line is harder to scrape than a text message. The downside is that long random strings are awful to dictate. Use this for short shared secrets, not 32-character API keys.

2. A password manager's share feature

1Password, Bitwarden, and Dashlane all have one-time-link sharing. It works well — the link expires after one click or a set time, and the recipient doesn't need an account in some cases. The catch: at least the sender needs an account, the company sees the metadata (who sent what to whom and when), and recipients sometimes hit friction with the receiver flow.

3. An ephemeral encrypted link

Tools like Btwinus, OneTimeSecret, and PrivateBin let you create a link that contains the encrypted secret and self-destructs after one read. Btwinus goes further by requiring a passphrase the link doesn't contain — meaning even if someone intercepts the link, they can't decrypt without the second piece, which you send through a different channel (a phone call, a different chat app, in person).

The two-channel split matters more than people realize. If your Slack is compromised and you sent both the password and the link to it through Slack, the attacker has both halves. If the link goes through Slack and the passphrase goes through a phone call, an attacker needs to compromise two different things to get the credential. (It's the same encryption-in-a-link model Btwinus uses for chat.)

4. Signal disappearing messages

Signal supports messages that auto-delete after a set time. End-to-end encrypted, no server retention. Genuinely solid. The friction is that both parties need Signal accounts and to have already added each other, which is fine for ongoing relationships but awful for a one-off transfer with someone you don't already have on Signal. (For a fuller breakdown, see how Signal, Telegram, and Btwinus compare on anonymity.)

5. PGP encrypted email

Bulletproof if both sides have it set up. Almost nobody does. Skip unless you're already in a PGP-using community.

What to actually do, by situation

Sending the staging DB password to a coworker who needs it for an hour: ephemeral encrypted link with a separate-channel passphrase. Btwinus, OneTimeSecret, or your password manager's share feature.

Sending an API key to a vendor for a long-term integration: shared password manager vault. The credential should live somewhere both teams can rotate it; one-time transfers don't fit that workflow.

Sending a recovery code to a family member: phone call or in person. The credential is short, the relationship is long-term, and you don't need the secret to live anywhere outside your heads.

Sending a crypto seed phrase: never, ever digitally. Write it on paper, hand it over physically. Anything else is a mistake.

The principle, distilled

The question isn't "is this app encrypted?" — most modern apps are. The question is: after I send this password, where does a copy of it still exist, and who controls those places? If the answer is "five servers, indefinitely, owned by people I don't know," you used the wrong tool.

Use a tool that destroys itself. Split the secret across two channels when it matters. And for the high-stakes stuff, don't send it digitally at all.