How to send someone a password without leaving it lying around

Someone needs the database password. You are in a Slack thread, they are waiting, and the path of least resistance is to paste it and move on. Everybody knows this is wrong. Almost everybody does it anyway, because the correct alternative is rarely obvious in the moment.

So here is the practical version: what actually goes wrong, the methods worth using, and how to pick between them in the ten seconds you are willing to spend thinking about it.

Why the usual channels fail

The problem with pasting a credential into email, Slack, a ticket or a text message is not that the connection is unencrypted. It almost certainly is encrypted. The problem is what happens afterwards.

• It persists. The message stays until somebody deletes it, which is to say forever. The credential outlives the reason it was sent.
• It multiplies. Mail sits in the sender's outbox and the recipient's inbox, then in both organisations' backups, then in whatever archive compliance keeps.
• It gets searched. Anyone who later reaches that mailbox or workspace can search for "password" and find years of them at once.
• It gets forwarded. A thread grows, someone loops in a contractor, and the credential now sits in front of people who were never meant to have it.

The credential is not compromised when you send it. It is compromised later, by an account takeover or a leaked export that had nothing to do with you.

What you are actually defending against

It is worth being precise, because an unrealistic threat model leads to theatre. For nearly everyone, the risk is not a state actor intercepting traffic. It is:

• An inbox or workspace compromised months from now, with your credential still sitting in it.
• A colleague with legitimate access to a channel reading something that was never meant for them.
• An honest mistake: the wrong Dave in the autocomplete, a screenshot with the panel still open, a repo that goes public.

Every method below is judged on one question: after the intended person has read it, is there still a copy?

Six methods worth using

1. Do not share it at all

The strongest option, and the one people skip past. A large share of credential sharing exists only because the underlying system offers no better path. Before sending anything, ask whether you can instead:

• Send an invite so they create their own login.
• Add them to the SSO group that grants the access.
• Issue a scoped API token for them specifically, which you can revoke without disrupting anyone else.

A shared password cannot be revoked from one person, and it cannot tell you who used it. An individual account does both. If this route is open, take it and skip the rest of this article.

2. Your password manager's sharing feature

1Password, Bitwarden, Keeper and the rest all have a way to share an item with another user or a team vault. If both parties already live in the same manager, this is the best everyday answer: access is granted rather than copied, it can be revoked later, and rotating the credential updates it for everyone at once.

The catch is that it usually requires both sides to be on the same platform, which rules it out for contractors, clients and anyone outside the company.

3. A one-time secret link

This is the right tool for the common case: a one-off credential going to someone who is not in your password manager. You paste the secret into a service, get a link, and the link stops working once it has been read.

The implementation detail that matters is whether the service can read what you gave it. In a well-built one, the secret is encrypted in your browser and the key is held in the fragment of the URL, the part after the #, which browsers never transmit. The server stores ciphertext it has no way to open.

4. An encrypted messenger with disappearing messages

Signal, or WhatsApp with a disappearing-message timer, is a reasonable choice when you already have that channel with the person. It is end-to-end encrypted and the message removes itself on a timer.

Two caveats. Disappearing messages are a courtesy, not a guarantee: the recipient can screenshot, and some clients keep backups. And it puts a work credential on a personal device, which may not be something your policy allows.

5. Split it across two channels

Send the link one way and whatever unlocks it another. The link goes in Slack, the passphrase goes by SMS or over the phone. Neither channel on its own is enough to use the credential.

This is genuinely effective and costs almost nothing. It is also the principle the other methods are approximating, which is worth naming properly.

6. Say it out loud

Unfashionable, and for a short credential going to someone you are already talking to, entirely reasonable. A spoken password leaves no message history to leak. It fails for a forty-character API key, and it fails if anyone is recording, but do not dismiss it.

The principle underneath: out of band

"Out of band" means moving something off the channel that needs it. If the ticket is where the work happens, the credential should not be in the ticket. The ticket gets a pointer that expires; the secret itself travels separately.

Once you have that idea, the ranking above mostly explains itself. A password manager grant is out of band because nothing is copied into a conversation. A one-time link is out of band because what lands in the thread is a pointer that dies. Splitting across two channels is out of band by construction.

What not to do

• Plain email. The worst common option: permanent, searchable, forwarded, and duplicated across several systems by default.
• SMS. Unencrypted at rest with your carrier and trivially readable on a lock screen.
• A shared document or spreadsheet. Grows silently, is never cleaned up, and usually ends up shared "with anyone who has the link".
• A screenshot. Now the credential is in an image, which your password manager cannot rotate and your search cannot find when you go looking for it later.
• A public paste site. Indexed and scraped, sometimes within minutes.
• Committing it "temporarily". Git history keeps it after you delete the line. Assume it is public and rotate.

Choosing in ten seconds

• Can they have their own account? Give them one. Stop here.
• Are you both in the same password manager? Share it there.
• One-off, or someone outside the company? One-time link, with a passphrase sent by a different channel.
• Short, and you are already on a call? Read it out.
• Anything else? Assume whatever you send will still exist in a year, and decide whether you are comfortable with that.

And whichever route you take, rotate anything that has previously gone out over email or a chat thread. That copy is still there, and the only way to make it harmless is to make it wrong.

Send a one-time secret at oobsecret.com

Common questions