Why Sharing Passwords in Slack and Microsoft Teams Is a Security Risk (and What to Do Instead)

"Hey, can you ping me the database password?" And seconds later, a reply in Slack: "Sure, it's Sup3rS3cr3t!2024".

This exchange happens thousands of times every day in companies of all sizes. It feels safe because Slack and Microsoft Teams are enterprise tools with login requirements, two-factor authentication, and HTTPS encryption. But this perception is dangerously wrong.

When you paste a password into a chat message, you are not sending it and moving on. You are creating a permanent, searchable, exportable record that will exist in the platform's infrastructure for months or years. This guide explains exactly why that is dangerous and what to do instead.

How Slack and Teams actually store your messages

To understand the risk, you need to understand how these platforms handle data behind the scenes.

Slack's data architecture

Slack stores all messages in a centralized database. Every message is indexed for search, which is one of Slack's core features. When you type a search query, Slack scans every message you have access to, including DMs, group chats, and channels, both public and private.

Key facts about Slack's data handling:

• Default retention is indefinite. Unless an admin explicitly configures a retention policy, every message ever sent is stored forever.
• Deleted messages are not immediately purged. When you delete a message, it may be removed from the user interface but can persist in Slack's backend systems, backups, and compliance exports.
• Compliance exports include DMs. On Enterprise Grid and Business+ plans, admins can export all messages, including private DMs, without notifying the participants.
• Third-party app integrations can access messages. Slack apps installed in a workspace may have permission to read messages in channels, creating additional exposure points.

Microsoft Teams data architecture

Microsoft Teams stores messages in Exchange Online mailboxes and uses Azure infrastructure. Messages are encrypted at rest using BitLocker and service encryption, and in transit using TLS. However, Microsoft holds the encryption keys.

• eDiscovery and Content Search. Admins with the appropriate roles can search and export all Teams messages, including private chats, using Microsoft Purview compliance tools.
• Retention policies apply. Teams messages are subject to Microsoft 365 retention policies, which often default to retaining everything for compliance reasons.
• No end-to-end encryption for standard chats. While Teams offers E2EE for 1:1 VoIP calls, standard text messages are not end-to-end encrypted. Microsoft and anyone with admin access to the Microsoft 365 tenant can potentially read them.

6 security risks of sharing passwords in chat

1. Persistent, searchable history

This is the most critical risk. Corporate chat tools are designed to keep history searchable. This means a password you shared six months ago is just a search query away.

If an attacker gains access to a single employee's Slack or Teams account (via phishing, credential stuffing, or session hijacking), the first thing they do is search for keywords like:

• password, contraseña, senha
• API key, secret, token
• login, admin, root
• database, .env, credentials

Security researchers call this the "goldmine effect": a single compromised account unlocks years of credentials shared across the entire organization.

2. Admin and compliance access

In many organizations, IT administrators, legal teams, and compliance officers have the ability to export and read chat logs. This is by design: regulations like GDPR, HIPAA, and SOC 2 often require that organizations retain and can produce communication records.

But this also means your "private" DM containing a database password might be readable by dozens of people in your organization who have admin access. And if any of those admin accounts are compromised, the attacker inherits that access to everything.

3. Notification previews and screen exposure

When someone sends a password in Slack or Teams, it often appears as a push notification on the recipient's phone, tablet, or desktop lock screen. The first few words of the message are visible to anyone nearby.

This is a social engineering goldmine. An attacker performing physical reconnaissance (shoulder surfing in a cafe, office visit, or even a photo of a desk) can capture credentials that pop up on an unlocked screen or notification preview.

4. Third-party app and integration exposure

Slack and Teams have rich ecosystems of third-party integrations. Many organizations install apps for project management, CRM, monitoring, and more. These apps often request permissions to read messages in channels.

If any of these third-party apps have a security vulnerability or are compromised, the messages they have access to, including any passwords shared in those channels, are exposed. You are trusting not just Slack or Microsoft, but every third-party vendor whose app has message-reading permissions.

5. No granular access control on messages

When you send a password in a Slack channel or Teams chat, every member of that channel or chat can see it. There is no way to restrict a specific message to a specific person. Even in a DM, you cannot set an expiration, limit views, or require additional authentication to read the message.

Compare this with a purpose-built tool like Nurbak's one-time links: you can set the link to self-destruct after one view, add a passphrase for additional security, and set an expiration time. If the link is intercepted, the attacker has a narrow window to use it, and you will know it was accessed.

6. Forwarding and screenshot risks

Once a password is in a chat message, any participant can forward it to another channel, copy-paste it elsewhere, or screenshot it. There is no digital rights management (DRM) on chat messages. The credential has left your control permanently.

Real-world attack scenarios

These are not theoretical risks. They are documented attack patterns used by real threat actors:

Scenario 1: Phishing leads to credential harvesting

An attacker sends a convincing phishing email to an employee. The employee clicks and enters their Slack credentials. The attacker now has access to the employee's entire Slack history. They search for "password", "API key", and "database" and find credentials shared over the past year. Within hours, they have accessed the company's production database, cloud console, and payment system.

Scenario 2: Former employee retains access

An employee leaves the company, but their Slack account is not immediately deactivated. Or they had already downloaded or screenshotted credentials from chat. They retain knowledge of every password that was ever shared with them in Slack. If those credentials were not rotated, the former employee still has access.

Scenario 3: Compromised Slack bot

A third-party Slack bot installed for workflow automation has a vulnerability. An attacker exploits it and gains the bot's access token, which has permission to read messages in several channels. The attacker silently reads channel history and extracts credentials that were shared months ago.

The secure workflow: ephemeral links instead of chat messages

The solution is simple: separate communication from secret transmission. Use Slack or Teams to say "here is the credential." Use a purpose-built tool to deliver the actual credential.

Step-by-step secure credential sharing

1. Go to Nurbak and paste the credential (password, API key, env variable, etc.).
2. Configure security settings: set it to self-destruct after 1 view, add an optional passphrase, and choose an expiration time.
3. Copy the generated link and paste it into Slack or Teams.
4. Your colleague clicks the link, sees the credential, and the link is permanently destroyed.

What remains in chat history: A dead link that returns a 404 page. No password, no API key, no credential. If an attacker searches the logs months later, they find a graveyard of expired links, not a list of live passwords.

Why this approach works

• Zero-knowledge encryption: Nurbak encrypts the credential in your browser using AES-256 before it reaches any server. Even Nurbak cannot read your data. Learn more about client-side vs server-side encryption.
• Self-destructing links: The credential is automatically deleted after being viewed. No persistence, no searchable history.
• Audit trail without exposure: You can verify that the link was accessed without the credential being stored anywhere. This satisfies compliance requirements without creating a security liability.
• No behavior change required: Your team still uses Slack or Teams for communication. They just paste a link instead of a password. The workflow adds less than 10 seconds.

What about Slack's "Delete message" feature?

Some teams rely on deleting the message after the recipient has seen it. This is insufficient for several reasons:

• Slack's compliance exports may capture the message before you delete it.
• The message may persist in Slack's backups and internal systems.
• Push notifications already displayed the content on potentially multiple devices.
• Any third-party apps with message access may have already cached the content.
• It relies on humans remembering to delete, which is unreliable.

Deleting a message is not a security control. It is a UI convenience that provides a false sense of security.

Building a culture of secure credential sharing

Technical tools alone are not enough. Your team needs to adopt secure practices as a habit:

• Establish a policy: "Never paste credentials directly in chat. Always use an ephemeral link." Document this in your onboarding materials and security handbook.
• Lead by example: When a teammate asks for a password in chat, respond with a Nurbak link instead of the plaintext credential. Over time, this becomes the norm.
• Use tools that integrate with your workflow:Nurbak's Slack integration lets you generate secure links directly from Slack, reducing friction to near zero.
• Rotate credentials that were previously shared in chat: If your team has been sharing passwords in Slack or Teams, assume those credentials are compromised. Rotate them and start fresh with secure sharing practices.
• Regularly audit chat history: Periodically search your own chat history for credential-like patterns and remediate any findings. Learn more about secret key management best practices.

Comparison: chat messages vs. ephemeral links

Conclusion

Slack and Microsoft Teams are excellent communication tools. They are not credential management tools. Every password pasted into a chat becomes a permanent, searchable, exportable liability that grows more dangerous over time.

The fix is simple and takes seconds: use an encrypted, self-destructing link for every credential you share. Your team keeps using Slack and Teams for communication. The only change is pasting a link instead of a password.

Stop treating chat logs as a password vault. They are searchable text files on someone else's server. Use the right tool for the job.