Send the secret one way and the key to it another way. That single rule is most of the answer. A password pasted into an email is a password that now lives in your Sent folder, in their inbox, on two mail servers and in whatever backups those companies keep — and you cannot delete any of it. A password sent as an encrypted block by email, with the passphrase read out over the phone, is a password that nothing in either archive can open. The rest of this is how to do that without turning a two-minute favour into a project.
Why pasting it into email or chat is worse than it feels
The transport is usually fine. Mail servers talk to each other over TLS and most chat apps encrypt in transit. The problem is that messages are stored, in more places than you are counting:
- Your copy and their copy. Deleting yours does nothing to theirs. You have no idea how long their inbox keeps things, or who else can open it.
- Search. Both mailboxes are full-text indexed. Anyone who later gets into either account can type the word "password" and get a list.
- Administrators. On a company mail system or a paid chat workspace, an admin can usually export history — and depending on the plan, that can include direct messages. Nobody has to be malicious for this to bite; it happens during a routine legal hold.
- Forwarding. The recipient replies to a colleague with the whole thread quoted underneath, and now it is in a fourth inbox.
- Backups and devices. The phone that received it backs itself up. The laptop that read it syncs its mail store. Each is another copy with its own lifetime.
None of this requires anyone to intercept anything. The message does the damage by continuing to exist.
Split the secret from the key to it
The working principle is called out-of-band delivery, and it is not complicated: the thing you send and the thing that unlocks it must travel through channels that would not be compromised by the same event.
In practice you turn the password into something useless on its own before it goes anywhere. Paste it into an in-browser encryption tool, pick a passphrase, and you get a base64 block that is safe to drop in an email, a ticket or a chat message. It is AES-256-GCM with a key stretched from your passphrase by PBKDF2 over 250,000 rounds, and it runs in the page — nothing is uploaded, so no third server holds your secret. Then you tell the recipient the passphrase by voice.
Now an attacker needs both halves, from two different places. The email archive gives them a block of base64; the overheard call gives them a passphrase with nothing to open.
What counts as a second channel
One that fails independently of the first. The block by email and the passphrase by email ten minutes later is one channel used twice.
- Good: a phone call, in person, or a messaging app on a different account and a different device from the one that got the block.
- Acceptable: SMS. Genuinely weak — SIM swaps are real — but it fails for different reasons than corporate email, which is the point.
- Not a second channel: a second email, a reply in the same thread, or the same chat app you just used. Same account, same compromise.
The methods that actually work, roughly in order
Your password manager's share feature
If both of you already use the same password manager, this is the best option and it is not close. The credential is shared as an entry rather than as text, so it never lands in a message at all, you can revoke access later, and when the password changes the other person gets the new one. Several managers also generate one-time share links for people outside your account, usually with an expiry and a view limit. Check what yours supports — the feature set differs a lot between products and tiers.
A self-destructing link
Services that store a secret once, hand you a URL, and delete the secret after it is read. Convenient, and the well-built ones keep the decryption key in the URL fragment — the part after the #, which browsers never send to the server — so the operator cannot read what it stores.
Two things spoil it. You are trusting that the page you were served is the page you think it is, and you cannot check that from the outside. And link previews are a menace: chat apps and mail clients fetch URLs automatically to build a thumbnail, so if the secret sits in the path rather than the fragment, the preview bot can burn the single view before your recipient clicks. When they say the link is already used, that is usually what happened.
An encrypted block plus a spoken passphrase
More friction, no third party involved at any point. Good when the secret has to travel through a system that keeps records on purpose — a support ticket, a shared mailbox, a client's procurement portal — because the record it keeps is meaningless.
Just reading it out
Underrated for short secrets. No copies anywhere, no software, no server to trust. Use the NATO alphabet for anything case-sensitive and it takes thirty seconds. It falls apart for a 32-character API key, which is when the options above earn their friction.
The passphrase is the weakest part, every time
Encryption gives you a block that is only as good as the thing protecting it, and an attacker who has the block guesses at it offline — on their own hardware, in parallel, for as long as they like. No rate limit, no lockout, no one watching. A dictionary word with a number after it does not survive that, whatever the cipher is.
Use four or five genuinely random words. Random is doing the work in that sentence: words you pick yourself cluster around things you like and things in the room, which collapses the search space. A generator that picks for you removes that problem, and the difference between a passphrase and a password covers why a machine-picked phrase beats a clever human-picked one by roughly thirty bits of entropy.
And it is for this message only. Do not use the one that opens your laptop.
The best version of this is not sending a password at all
Before encrypting anything, check whether the system has an invite flow. Most do. An invitation to create their own credentials means there is no shared secret in existence, nothing to intercept and nothing to remember to rotate. The same goes for SSO, scoped API tokens with an expiry, and a temporary password the system forces them to change on first login.
When you genuinely have to hand over a real password — a legacy account, a shared billing login, a router — treat the sharing event as the start of an expiry. The password is now in their clipboard history, possibly in a note they made so they would not forget it, and in whatever they pasted it into by mistake. Change it when the reason for sharing ends, and immediately if the person leaves.
What none of this protects against
The encrypted-block approach can feel more total than it is.
It does not protect a compromised machine. With a keylogger on either end, the secret is gone the moment it is typed or pasted, and care in transit changes nothing.
The clipboard is shared. Both the block and the decrypted result pass through it, and other applications on the same machine can often read it. Some clipboard managers keep months of searchable history.
It proves nothing about who sent it. A block that decrypts cleanly was not modified by anyone lacking the passphrase — that is what the GCM authentication tag buys you. It does not prove who wrote it, because anyone with the passphrase can write one. Encryption, signing and what a hash does and does not guarantee are three different jobs, and conflating them is how people end up trusting the wrong thing.
The recipient's habits are outside your control. You can deliver a password perfectly and watch them paste it into a shared spreadsheet called Logins. Tell them where to put it, not only what it is.
For the cases where a password has to cross a channel that keeps records, the text encryption tool here turns it into a block that is safe to paste anywhere, with the key derived in your browser and nothing sent to a server. Then say the passphrase out loud to the person, and the two halves never meet in the same archive.
Splitting the secret is only half of the defence, though. The other half is making the password less valuable to whoever eventually finds it, which is what a second factor does — how those six-digit codes are generated explains why a stolen password on its own stops being enough.
Frequently asked questions
How do I send a password securely over email?
Do not put the password itself in the message. Encrypt it into a block first and send the passphrase by a different route, such as a phone call, or share it through a password manager instead. Email is stored indefinitely in at least four places you do not control, so anything readable in the body should be assumed permanent.
Is it safe to send a password over Slack or Teams?
No safer than email. The transport is encrypted but the message is retained, searchable, and on paid workspaces an administrator can often export history, which depending on the plan can include direct messages. If you have already done it, change the password rather than deleting the message.
Is WhatsApp or Signal good enough for sending a password?
They are better than email because the message is end-to-end encrypted in transit, so the provider cannot read it. The copies on both phones remain, though, along with anything those phones back up. Use them as the second channel for a passphrase rather than as the place you paste the full credential.
What is a one-time secret link and can I trust it?
It is a service that stores a secret, gives you a URL, and deletes the secret after the first view. The better ones keep the decryption key in the URL fragment so the server never receives it, but you are still trusting that the page you were served behaves as advertised. Watch out for link previews in chat apps, which can consume the single view before the recipient clicks.
Should I change a password after sharing it with someone?
Yes, once the reason for sharing has ended, and immediately if the person leaves the team. After sharing, the password exists in their clipboard history, possibly in a note they wrote, and anywhere they pasted it by accident. Treat the moment you share it as the start of its expiry.
What is the safest way to send a password to a non-technical client?
Check first whether the system can send them an invitation to set their own password, which removes the shared secret entirely. If not, read it to them over the phone and have them type it straight into the login screen. Short secrets over voice beat any tool they have to be talked through.
Last updated September 19, 2026