How to share a password or secret safely (and what not to do)

MAIN OÜ Updated 10 July 2026 6 min read

Sooner or later you have to hand someone a password — the shared account for a tool the team uses, the Wi-Fi key for the office, a recovery code, the credentials for a client's server. The quick reflex is to type it into email or a chat window and hit send. That reflex is the problem. The message you fired off in two seconds can outlive the account it protects by years, sitting in copies you will never see and cannot delete.

Why the usual methods fail

Email, Slack, Teams, and SMS are all built to keep messages, not to destroy them. That is exactly what you want from them most of the time, and exactly what makes them poor couriers for a secret. When you send a password through one of them, you are not making one copy — you are scattering several:

• It persists. The message stays in your Sent folder and the recipient's inbox indefinitely. Neither of you will remember to go back and delete it.
• It gets forwarded. "Can you loop in Sam?" and now the password lives in a thread you have lost track of, quoted at the bottom of a reply.
• It sits in backups. Corporate mail and chat are archived, often for years, on systems you do not administer and cannot purge.
• It syncs everywhere. The message lands on every phone, laptop, and tablet signed into the account, including an old device in a drawer.
• It lands in logs. Text pasted into a chat can flow through search indexes, notification previews, and third-party integrations before anyone reads it.

A password sent this way does not expire when the conversation ends. It can resurface during a mailbox export, a discovery request, or a breach of a service you forgot you were even using. The secret is only as safe as the least careful copy of it, and you stopped counting the copies the moment you pressed send.

The four principles

Everything good practice comes down to four ideas. Hold onto these and the specific tools matter less.

• Minimise copies. The fewer places the secret exists, the fewer places it can leak. Aim for delivery that leaves nothing behind once it has been read.
• Make it expire. A secret with a deadline stops being a liability on its own. If it is not collected, it should disappear.
• Use a separate channel. Never send the secret through the same channel as the thing it unlocks. If email holds the login link, the password should not also travel by email.
• Prefer one-time delivery. Once the recipient has the secret, no one else should be able to fetch it from the same place. A link that works exactly once beats a document that works forever.

Safe methods, ranked

Three approaches meet those principles, in rough order of how well they scale to everyday use.

1. A password manager's secure sharing

If your team already uses a shared password manager, use its built-in sharing. The secret stays inside an encrypted vault, access is granted to a named person, and you can revoke it later. This is the best option for credentials that a colleague will need again, because it keeps the password in one managed place instead of scattering it through messages.

2. A one-time encrypted link

For a one-off — a contractor who needs a key once, a friend you are helping recover an account — a link that self-destructs after a single view is ideal. The secret is encrypted before it leaves your browser, and it exists only until it is read. Nothing lingers in a vault or an inbox.

3. Splitting the secret across two channels

When you have no better tool to hand, split the secret. Send half by one route and half by another — the username by email, the password by phone call; or the file by chat and its passphrase by text. An attacker would need to compromise both channels at once. It is clumsy, but it is far better than putting everything in a single message.

The one-time-link method, step by step

The second option deserves a full walkthrough, because it is the one most people do not know they have. Here it is with classified, a free, no-signup tool from MAIN OÜ, as the concrete example.

1. Write and encrypt in the browser. Type the password or paste the secret into the page. It is encrypted on your device with AES-256-GCM before anything is uploaded; only the unreadable ciphertext and an opaque id reach the server. The key rides in the link's URL fragment, which browsers never send to servers.
2. Set a short expiry. Choose a window that fits — anywhere from 5 minutes to 24 hours. If the link is never opened, it is purged automatically at the deadline. The moment it is viewed once, it is destroyed.
3. Optionally add a password. Turn on password mode to protect the link with a passphrase of your own. It adds a second layer derived in the browser with PBKDF2, so even someone holding the link cannot open it without the passphrase.
4. Send the link on one channel, the passphrase on another. Drop the link in chat and read the passphrase over a phone call, or send the link by email and the passphrase by text. Neither channel alone reveals the secret.

What not to do

• Never put the password beside what it unlocks. The username, the login URL, and the password should not travel in the same message. Together they are a working key; split up, each half is close to useless.
• Do not screenshot secrets. A screenshot is a permanent image that lands in your camera roll, syncs to the cloud, and gets backed up — the opposite of something that expires.
• Do not reuse a shared password. Once a credential has been passed to someone else, treat it as spent. Rotate it when their need ends, and never let a shared secret double as a personal one.
• Do not paste secrets into a chat that generates link previews. Some platforms fetch and unfurl anything that looks like a URL, which can trigger a one-time link before the person you meant to reach ever clicks it.

A copy-ready checklist

• Is the secret going through a channel that keeps permanent copies? If yes, switch methods.
• Will the secret expire on its own if it is not collected?
• Is the secret travelling on a different channel from the thing it unlocks?
• Can it be fetched more than once? If yes, prefer a one-time link.
• Did you avoid pairing the password with the username or login URL in one message?
• Have you planned to rotate the credential once the other person is done with it?