Everyone knows they should not paste a password into Slack. Everyone does it anyway, roughly weekly, usually with a small apology attached — sorry, sending this here, will delete after.
The apology is the interesting part. It shows the risk is understood and that the understanding is not changing the behaviour, which means telling people it is bad has already failed. What follows is the mechanical version instead: what actually happens to that message, why deleting it does not do what people assume, and what to do in the thirty seconds you have.
Summary
The exposure is not the moment of sending. It is that one message becomes several independent copies — your device, their devices, the provider's servers, and the workspace's own search and export layer — each governed by a retention rule you do not set. Deleting your copy reaches one of them. Rotating the credential is the only step that reaches all of them.
Chat is designed to remember
This is not a flaw in Slack, Teams or anything else. It is the product working correctly.
A chat tool's central promise is that the conversation persists: searchable, synced across devices, available to someone who joins the channel later, exportable for compliance. Every one of those properties is a reason people pay for it. Every one of them is also a mechanism for keeping your credential.
The mismatch is that a password has the opposite requirement. It needs to reach one person, once, and then stop existing. Putting a thing that should be ephemeral into a system whose whole purpose is permanence is the entire problem, and it does not depend on the provider being careless.
Where it actually ends up
Your own device. Local message history and application caches, plus whatever backs those up. On a laptop with an encrypted disk this is the least worrying copy — but it is also the only one you can reliably delete.
Their devices. Every device the recipient is signed in on has a copy: phone, laptop, tablet, perhaps a personal device. You know nothing about the security posture of any of them. A phone with no lock screen, left on a desk, is a plausible member of this set.
The provider's servers. Retained under a policy set by your organisation's plan and administrators — frequently indefinitely. On paid workspaces, message deletion may be disabled for members entirely, which means the apology in the message is describing something the sender cannot actually do.
The workspace layer. This is the one people forget. The message is in search results for anyone with channel access, including people who join the channel next year. It is in compliance exports. Workspace administrators can read it. Connected third-party apps with a broad OAuth scope may have ingested it.
Why "I'll delete it after" does not work
Three separate reasons, any one of which is sufficient.
It may not be permitted. Many workspaces disable message deletion for non-administrators, precisely because retention is a compliance requirement. The button is not there.
It deletes your copy, not the copies. Deletion removes the message from the interface. It does not reach into device-local caches, backups already taken, or exports already generated. Search indexes may or may not update, and you have no way to check.
The exposure already happened. The credential was in an unencrypted message in a system with an unknown number of readers, for however long it took you to get to the delete button. Removing it afterwards does not retroactively un-share it. If someone with access read it, you have no signal that they did.
The honest framing is that deletion is tidying up, not remediation. Treating it as remediation is what makes the practice persist — it supplies a feeling of having handled it.
The thirty-second version of doing it right
Most guidance here fails because it is longer than the thing it is trying to replace. Pasting into a chat window takes four seconds. Anything that takes ten minutes loses.
1. Ask whether it needs to be shared at all. The best handover is one that does not happen. If you can provision a separate account, issue a scoped token, or invite them to the system directly, do that — nothing moves, nothing can leak, and revoking it later does not affect anyone else. For developers this is available far more often than it gets used; sharing credentials in a development team covers the cases where it genuinely is not.
2. Split the channel. If it must be sent, the link goes one way and the password goes another. Link in chat, password by phone call. This is the single highest-value habit in the whole subject, because it means someone reading the chat history later has an address and no key. Both halves in the same thread is the same mistake wearing a costume.
3. Set a short expiry. The default outcome should be that it disappears. A one-time link that is consumed on reading, or an expiry measured in hours, means forgetting to clean up is no longer a failure mode. Be aware that link scanners in corporate mail and chat systems will sometimes open a one-time link before the human does — if the recipient reports it already used, treat that as a consumed link rather than an attack, and reissue.
4. Confirm out of band. A two-word reply on the second channel tells you the right person got it.
5. Rotate afterwards. Secure transport reduces exposure. It does not undo the fact that the secret moved and now exists in a second person's head, notes, or password manager. Anything shared should be on a rotation list, and the rotation section of our guidance for IT and DevOps teams covers making that routine rather than exceptional.
If you have already sent one
This happens. The useful response is ordered, and the first step is not the one people reach for.
Rotate the credential first. Before deleting anything, before apologising, change it. This is the only action that reaches every copy in every location simultaneously, because it makes all of them worthless. Everything else is optional once this is done.
Then delete the message, if you can. It is worth doing — it reduces the chance of casual future exposure — but do it knowing it is the second step.
Then check what else is in the thread. If a credential was pasted once, it was probably pasted before. Search the channel for the obvious patterns: password, api_key, token, -----BEGIN. What turns up is usually worse than expected.
Do not ask the recipient to delete their copy and consider it resolved. You cannot verify it, it does not address the provider-side copy, and it converts a technical problem into a social one.
The uncomfortable part: the archive
The immediate risk — someone reading the channel today — is the smaller one. The larger risk is time.
A credential pasted into a chat thread today will still be there in three years, still valid if nobody rotated it, in a workspace that by then includes contractors, departed employees whose access was never fully revoked, and integrations installed by people who have left. The population with access to your message history grows, and nothing re-evaluates the messages already in it.
Workspace exports make this concrete. A compliance export is a file containing everything, and it is handled by whoever requested it, stored wherever they put it. Any credential ever pasted into the workspace is in that file, in plain text.
This is the strongest argument for the whole practice, and it is not about attackers. It is that chat history is a liability that accumulates quietly, and the credentials in it are the part that stays dangerous.
What an encrypted note changes, and what it does not
For the one-off handover, a client-side encrypted note with an expiry is a reasonable answer: the content is encrypted in the sender's browser, the service stores ciphertext it cannot read, and the copy is destroyed on reading or on a timer. What travels through chat is a URL, and a URL with no password attached is not a credential.
What it does not do is remove the need for the other steps. If you send the link and the password in the same message, you have moved the problem rather than solved it. If you never rotate, the secret still exists in a second place indefinitely. And there is no attributable log of who opened the link — that requires identity, which this kind of tool deliberately does not have. How to judge an encrypted note service covers how to check whether a given one does what it claims.
For anything the team needs on an ongoing basis, the answer is not a note at all — it is a shared vault in a password manager, and encrypted notes vs password managers vs secrets managers sets out which belongs where.
FAQ: passwords in chat
Q1. Is Slack encrypted? Does that make it safe for passwords?
Slack encrypts data in transit and at rest, and both are real protections against a network attacker or a stolen disk. Neither is the relevant threat here. The risk is the number of legitimate parties who can read the message — recipients, administrators, integrations, and anyone with access to the channel later — and encryption in transit does nothing about any of them.
Q2. What about a direct message instead of a channel?
Better, but the same structure applies. A DM is retained on the provider's servers, appears in compliance exports, and is visible to administrators under most enterprise plans. It reduces the immediate audience; it does not change the retention.
Q3. Is it safe if I delete the message immediately?
No, for three reasons: your workspace may not permit deletion at all, deletion does not reach device caches, backups or exports already taken, and the exposure occurred while the message was live. Treat deletion as tidying up and rotation as the fix.
Q4. What if the recipient has no tools and is outside my company?
This is the common case, and it is why link-based sharing works: the recipient needs a browser and a password, with nothing to install and no account to create. Send the link by email or chat and the password by phone.
Q5. Our workspace scans links and consumes one-time URLs. What now?
Corporate link scanners do open URLs ahead of the human, and a one-time link will register as read. Send the link through a channel that does not scan, use a link with a short expiry rather than a single-view limit, or warn the recipient in advance so a consumed link is recognised as the scanner rather than an intruder.
Q6. Is a password manager's sharing feature better than an encrypted note?
For anything ongoing, yes — a shared vault handles rotation, revocation and access control, which a note does not. An encrypted note is the better fit for a one-time handover to someone outside your vault, particularly someone with no tooling of their own.
Where to go next
- How to share passwords securely online — the full treatment, including the channel-splitting rule.
- Self-destructing notes vs encrypted email — why the number of surviving copies, not the encryption, is the deciding difference.
- Encrypted notes vs password managers vs secrets managers — which tool a given request actually belongs in.
- Secure sharing for IT and DevOps teams — onboarding, offboarding and rotation as a routine rather than an incident.