What is the most secure way to share a password?

For credentials a team uses continuously, a password manager with shared vaults is the most secure option, because nobody has to copy the password anywhere. For a one-off handover to someone outside your vault, a one-time secret link is best, because the credential is encrypted, expires, and leaves no lasting copy in a mailbox or chat thread.

Is it safe to send a password over email?

No. Email is stored indefinitely in the inbox, the sent folder, the mail server and their backups, and it is readable by anyone who later gains access to any of those. It is also frequently forwarded. If you have already sent a password by email, the safest response is to change it rather than to delete the message.

Is sending a password over Slack or Teams secure?

Not for anything lasting. Messages persist, are searchable, are readable by people who join the channel later, and are included in workspace exports. Team chat is encrypted in transit but it is a permanent, widely readable record, which is the opposite of what a credential needs.

Should I split a password across two messages?

Splitting a password in half across two messages on the same channel adds almost nothing, since anyone reading one message can usually read both. Splitting across two different channels is genuinely useful: send a one-time link by email and the passphrase by text message, so an attacker must compromise two unrelated systems.

How should I share a password with a client or contractor?

Use a one-time secret link. They are usually outside your password manager, so adding them to a shared vault is disproportionate for a single credential. A link that expires means there is nothing left in their inbox or yours once the job is done.

What should I do after sharing a password?

Where the system allows it, have the recipient change the password on first use, so the shared value stops being valid. For API keys and tokens, prefer issuing a new credential scoped to that person over sharing an existing one, because a credential you can revoke individually is far easier to clean up later.

The best ways to share passwords securely

Most advice on this question is unhelpful because it treats "sharing a password" as one problem. It is two, and they have different answers:

Ongoing access. Several people need the same credential, repeatedly, for as long as the account exists.
A handover. One person needs one credential, once, and then the transfer is finished.

Using the tool built for the other problem is where most of the bad outcomes come from.

For ongoing access: a password manager with shared vaults

If your team logs into the same account week after week, a shared vault is the right answer and nothing else comes close. The reason is not encryption - it is that nobody ever has to copy the password anywhere. It is never pasted into a message, never typed into a document, never sent. The moment a credential is transmitted as text, it can be stored as text.

Shared vaults also give you the things ad-hoc sharing cannot: revoking one person's access without changing the password for everyone, seeing who has access, and rotating a credential in one place.

The limitation is boundaries. A vault works for people inside it. Clients, contractors and one-off recipients are usually outside, and adding someone to your vault for a single credential is disproportionate.

For a handover: a one-time secret link

This is the gap the password manager leaves. You need to move one credential to one person who is not in your vault, and you want nothing left behind afterwards.

A one-time link encrypts the secret, gives you a URL, and destroys the record once it is read or once the clock runs out. The credential does not accumulate in a mailbox or a chat history. On a well-built service the encryption happens in your browser and the key travels in the part of the URL that is never sent to the server, so the service itself cannot read what it is holding.

Use one when:

The recipient is outside your organisation.
The credential is temporary or will be changed on first use.
You want the exposure bounded in time rather than open-ended.

For anything valuable: split the channels

Whichever method you choose, the strongest single improvement is to stop sending the credential on the channel it belongs to. Do not email the password for an email account. Do not put a production key in the channel where the incident is being run.

Better still, split the secret across two channels. Send a one-time link by email and its passphrase by text message. An attacker now needs to compromise two unrelated systems, and the effort involved rises by much more than double. This is the part most people skip, and it is the part that does the most work.

What to stop doing

Each of these is common, and each has the same underlying flaw: the credential persists somewhere it cannot be cleaned up.

Email. Lives in the inbox, the sent folder, the server and their backups. Frequently forwarded. Worst of the common options.
Team chat. Persistent, searchable, readable by people who join the channel later, and included in workspace exports.
Tickets and wikis. Indexed, widely readable, and often outlive the system they refer to by years.
Shared documents and spreadsheets. A password list in a shared drive is a single file that gives up everything at once.
Text message. Better than email for a second channel, but it is backed up to the cloud and sits on a lock screen.
Reading it aloud on a recorded call. The recording is a durable copy, often with automatic transcription.

Choosing quickly

Team needs it repeatedly: shared vault in a password manager.
One person, once, inside your organisation: shared vault entry, or a one-time link if they are not set up yet.
Client or contractor: one-time link, with a passphrase sent separately.
API key or token: issue a new one scoped to that person instead of sharing an existing one. A credential you can revoke individually is far easier to clean up.
Temporary password: one-time link, and require a change on first login so the shared value stops working.

If you have already sent one badly

Deleting the message is not a fix. It may be in backups, in someone's notification history, on a synced device, or in an export. If a credential has gone out over email or chat and it matters, change it. That is the only action that reliably ends the exposure, and it is usually far quicker than the investigation you would otherwise be doing later.