How to stop sending passwords over Slack, Teams and email

Pasting a shared account’s password into a Slack direct message, a Teams chat or an email is the quickest way to get a new teammate working. The trouble is what happens to the message afterward.

Where a sent password stays

Once you send a password in a message, you no longer control who sees it. It stays in four places.

In search

Slack lets you search messages and files, so the recipient can find the password again later by searching for the account name or the word “password”. On paid plans, Slack keeps data for the lifetime of the workspace by default. On free plans, you can view and search the last 90 days, and messages older than one year are deleted.

Paid plans can also keep a record of edits and deletions. Slack’s retention option “Never delete messages — save edits” keeps every message and tracks what was edited or deleted. So when you delete your own message, it disappears from your screen, but that doesn’t prove it’s gone.

Teams works in a similar way. Microsoft keeps a copy of every Teams chat in a hidden folder of each participant’s mailbox. When a retention policy applies and someone deletes a message, it vanishes from the Teams app but stays searchable by compliance tools until the retention period ends.

In forwards and exports

People you never sent it to can receive it. In Gmail, a user can forward all new mail to another address automatically, or only the messages a filter picks out. In Slack, Workspace Owners can export messages from public channels on every plan. On Business+ and Enterprise, private channels and direct messages can be exported too. On Business+, that needs an application approved by the Workspace Primary Owner.

On the recipient’s side

Whoever receives the password can copy it into a note, take a screenshot or save it in their own browser. You can’t see or undo any of that from your side, and their personal phone may be where it ends up.

In the accounts of people who left

The message doesn’t leave with the person. Slack’s help page on deactivating an account says the messages and files that person sent aren’t deleted. In Exchange, the mail system behind Microsoft 365, mail a user deletes for good lands in a Recoverable Items folder, where retention settings can keep it. If a person who leaves is covered by a retention policy, their mailbox is kept as an inactive mailbox after their account is deleted. Their Teams chats are kept the same way.

Other ways to hand over a password

The alternatives fall into three kinds: you can take access back later, you can limit how long a link works, or nobody receives the password at all.

Link settings vary by product. 1Password creates a unique link to a copy of one item. You choose when it expires, and whether anyone with the link can open it or only people with the email addresses you enter. Recipients don’t need a 1Password account. Bitwarden Send transmits text or files through temporary links. You can set a deletion date up to 31 days out, cap how many times it can be opened, and add a password. If you paste the link into chat, keep its lifetime short.

What is a password manager? covers what sharing through a vault leaves behind. Managing shared accounts compares methods that hide the password. A share link suits a one-time handoff. For accounts people use every day, a password manager or a method that hides the password fits better.

How to switch

1. Set up the alternative first. If you only announce “stop sending passwords,” people who still need one go back to chat. Pick a method from the table and have it working before you announce anything.
2. Find passwords already sent. Search Slack, Teams and email for words like “password”, “pw” and “login”, and add each account you find to your shared account inventory.
3. Change those passwords. Deleting the old messages leaves copies on recipients’ devices and in retention records. A new password makes every old copy useless.
4. Write the rule down and share it. Put the ban and the alternative side by side, as in the sample below.
5. Name who handles exceptions and how often you’ll check. Decide who to contact in an emergency and how often to repeat the search in step 2.

A sample rule

NIST SP 800-53 Rev. 5 is NIST’s catalog of security controls. It is mandatory for federal systems, and NIST encourages private organizations to consider it. Two of its controls cover this rule. PL-4, rules of behavior, asks you to give people written rules for their responsibilities and get their acknowledgment before granting access. IA-5, authenticator management, asks you to protect passwords from unauthorized disclosure and to require people to take specific steps to protect them. Its discussion names not sharing them with others as one such step.

Here is one way to word the rule. Adapt it to your own policy format, and have whoever owns your company policies review it.

Sending passwords

1. Do not put the password for any work account in the body of a chat message, email or other message that is stored.
2. When a password must be handed over, use the company’s chosen password manager, or a share link with an expiration date.
3. If a password is sent any other way, report it to an admin right away. The admin changes that password.
4. Admins check company chat and email for passwords [how often] and confirm none were sent.

Item 1 is the ban, item 2 the alternative, item 3 what happens after a slip, and item 4 the check. Whether people follow the rule depends on item 2: the company’s chosen tool has to exist before the rule does. The check in item 4 covers only what admins can see, such as public channels. Including direct messages and email takes the right permissions in each service, and you should tell employees about it.