Why You Should Stop Sharing Secrets in Slack and Email

A quick Slack message with an API key. An email with the database password. A Teams DM with the .env file. It takes seconds, feels harmless, and happens thousands of times per day across development teams worldwide.

But every secret shared through these channels becomes a permanent liability — searchable, stored on third-party servers, and accessible to more people than you realize.

The Problem with Slack

Messages are stored indefinitely

Slack retains all messages on its servers. Free plans keep the last 90 days, but paid plans retain everything by default. Even on free plans, Slack’s backend stores messages beyond the visible retention period for compliance and data recovery purposes.

Messages are searchable

Slack’s search indexes every message, including DMs. Any workspace member with access to a channel can search for keywords like “password,” “API key,” or “secret” and find credentials shared months or years ago. On Enterprise Grid plans, workspace administrators can export and search all messages, including private DMs.

Third-party apps have access

Slack apps and integrations can read messages in channels they are added to. A logging or analytics bot silently ingesting channel messages may be archiving your credentials in yet another system you do not control.

Message deletion is unreliable

Deleting a Slack message removes it from the chat interface but does not guarantee removal from Slack’s servers, backups, or compliance exports. If your workspace has a retention policy or legal hold, deleted messages may be preserved.

Workspace breaches expose everything

When a Slack workspace is compromised — through a stolen session token, phished OAuth grant, or social engineering of an admin — the attacker can access every message in every channel the compromised account can reach. Every credential ever shared in those channels is immediately exposed.

The Problem with Email

Email is transmitted in plaintext

Unless both sender and recipient use end-to-end encryption (PGP or S/MIME), email messages are transmitted in plaintext between mail servers. Any intermediate server, network appliance, or monitoring system along the path can read the contents.

Email is archived and backed up

Corporate email systems retain messages for years as part of compliance and backup policies. An API key sent via email in 2023 is likely still sitting in a backup archive in 2026, accessible to IT administrators and discoverable in legal proceedings.

Email accounts are high-value targets

Email accounts are targeted by phishing, credential stuffing, and social engineering attacks. A compromised email account gives the attacker access to every credential ever received via email, plus the ability to reset passwords for other services.

Forwarding and CC risks

Email can be forwarded to unintended recipients with a single click. A message containing credentials can end up in a contractor’s inbox, a manager’s archive, or a mailing list, each expanding the exposure surface.

Real-World Consequences

These are not hypothetical risks. Public breach reports consistently show credential exposure through communication channels:

• Uber (2022): An attacker gained access to internal Slack and found credentials that provided access to cloud infrastructure and source code repositories.
• EA Games (2021): Attackers purchased stolen Slack session cookies and used them to access internal channels containing credentials and source code.
• Twitter (2020): A social engineering attack gave attackers access to internal tools and communication channels containing admin credentials.

In each case, credentials shared through chat or messaging systems were a key part of the attack chain.

What Makes a Sharing Method Secure?

A secure credential sharing method needs four properties:

1. End-to-end encryption

The credential must be encrypted before it leaves the sender’s device and only decrypted on the recipient’s device. No intermediary — including the service provider — should be able to read the contents.

2. Automatic expiry

The shared credential should disappear after a defined time period. This limits the window during which a compromise can occur and eliminates the long-tail risk of archived messages.

3. Access controls

The sender should be able to restrict who can access the credential and how many times it can be downloaded. This prevents unauthorized access and provides a layer of accountability.

4. No persistent storage

The sharing mechanism should not create a permanent, searchable record of the credential. Once the recipient has the credential, the shared copy should cease to exist.

Slack and email fail on all four counts. They offer no end-to-end encryption for message contents, no automatic expiry, limited access controls, and persistent storage by design.

What to Use Instead

For one-time credential sharing

Use SecretDrop to create an encrypted, password-protected bundle with an expiry date. The credential is encrypted in your browser before upload, the server never sees the plaintext, and the bundle is permanently deleted after expiry.

This replaces the “paste the API key in Slack” workflow with something that takes the same amount of time but eliminates every risk described above.

For long-lived shared credentials

Use a team password manager (1Password, Bitwarden, or similar) with a shared vault. These tools provide encrypted storage, access controls, and audit logs for credentials that multiple team members need ongoing access to.

For application-level secrets

Use a secrets manager (HashiCorp Vault, AWS Secrets Manager, Doppler) integrated with your deployment pipeline. These tools provide automated rotation, fine-grained access policies, and audit logging for production credentials.

Making the Switch

Changing a team’s habits takes more than tools — it requires establishing a clear policy:

1. Define the rule: Credentials must never be shared via Slack, Teams, email, or any persistent chat channel.
2. Provide the alternative: Set up SecretDrop and share the link in your team’s onboarding documentation.
3. Lead by example: When someone asks for a credential, share it via SecretDrop instead of pasting it in chat. It takes the same amount of time.
4. Audit periodically: Search your Slack workspace for common credential patterns (strings starting with sk_, AKIA, ghp_, or containing password=). Rotate anything you find and use it as a teaching moment.

The transition from insecure sharing to encrypted sharing is not a major workflow change. It takes the same number of clicks. The difference is that your credentials do not become permanent fixtures of your team’s chat history.