How to share API keys and tokens safely

Why Slack and email are the wrong place for API keys

Chat platforms and email are built for conversation — they index everything, archive messages, sync across devices, and retain history indefinitely. An API key you pasted into Slack three years ago is still searchable in your workspace today. If that workspace is ever exported, breached, or reviewed by a disgruntled ex-employee, those keys are exposed.

Email is no better. The same key sitting in an email thread lives in your sent folder, the recipient's inbox, and potentially both organisations' email servers and archives. There is no way to unsend it, and no way to confirm it has been deleted everywhere it was stored.

What happens when API keys leak

The consequences depend on the service, but they can escalate quickly:

• —Unauthorized API calls billed to your account — cloud providers have seen fraudulent compute bills reach tens of thousands of dollars within hours of a key leak.
• —Data exfiltration — an attacker with your database credentials or storage keys can read and copy everything.
• —Service disruption — keys can be used to delete resources, exhaust rate limits, or lock you out.
• —Cascading access — many services link together; one leaked key can become a pivot point to others.

The speed at which leaked keys are exploited has also increased significantly. Automated scanners monitor public repositories, Slack export dumps, and pastebin-style sites in near real time. A key that appears in the wrong place can be used within minutes.

When a secrets manager is the right tool

For secrets that need to be accessed repeatedly, rotated programmatically, and audited at scale, a dedicated secrets manager is the correct infrastructure. Tools like HashiCorp Vault, AWS Secrets Manager, and similar platforms are built to handle that problem.

But not every secret transfer happens inside an automated pipeline. Developers also share secrets person-to-person — onboarding a new hire, handing credentials to a contractor, sending a client their API key. These ad-hoc transfers are where one-time encrypted links fill the gap that secrets managers do not cover.

What you can share with CYPH3RDROP

Anything that belongs in a .env file is a good candidate:

• —API keys and access tokens (Stripe, OpenAI, SendGrid, etc.)
• —Database connection strings
• —SSH private keys
• —OAuth client secrets
• —Webhook signing secrets
• —Deployment and CI/CD tokens
• —Entire .env file contents — paste the whole block

CYPH3RDROP has no character limit enforced in the browser — you can paste a full environment file as a single secret. The encryption and transmission work the same regardless of size.

How it works in practice

1. 01Go to cyph3rdrop.com.
2. 02Paste the key, token, or credential block.
3. 03Click Generate — your browser encrypts it locally using AES-256-GCM. The server stores only ciphertext.
4. 04Send the one-time link to the recipient over Slack, email, or wherever is convenient.
5. 05They open it once — it decrypts in their browser using the key from the URL fragment — and then it is gone permanently.

The encryption key is embedded in the URL fragment — the part after the # — which browsers never include in HTTP requests. This means even CYPH3RDROP's servers never see the key. Zero-knowledge by design.

What to do after the handoff

Always rotate credentials after sharing when possible. CYPH3RDROP ensures the transfer is secure and traceless — but once the recipient has the key, what they do with it is outside your control. For production credentials especially, treat every share as a reason to rotate on the next deploy cycle.

For short-lived engagements — a contractor who will be off the project in two weeks — use scoped API keys with limited permissions and an expiry date. Share those over a one-time link. Revoke them when the engagement ends. This way, the credential is limited in both scope and lifespan, and the handoff leaves no trace.

A note on git history

A common source of leaked API keys is git history — credentials that were committed to a repository and then removed in a subsequent commit. Removing a secret in a commit does not remove it from the repository history. Anyone who can access the repository can retrieve it using git log or git show.

If a credential was ever committed to a repository — even briefly — treat it as compromised and rotate it immediately. One-time links help prevent this class of leak by giving you a safe channel that keeps secrets out of source control entirely.