Have you ever needed to share a database password or a sensitive API key with a colleague over Slack or email, only to break out in a cold sweat wondering how long that secret will sit in a chat history? We’ve all been there. Dropping credentials into plain text communication channels is a fast track to a security incident, yet it remains one of the most common ways sensitive data is passed around.

This is exactly why we built self-destructing secrets into OtterSeal 🦦. It’s a “burn-after-read” approach to sharing sensitive information, ensuring that once your intended recipient views the data, it vanishes into the digital ether, completely inaccessible to anyone else. It’s like a spy’s self-destructing message, but for your infrastructure keys and passwords.

Let’s dive into why this matters, how it works under the hood, and how you can use the OtterSeal CLI to keep your secrets secure.

The Problem with Persistent Secrets

When you paste a secret into a messaging app, an email, or a Jira ticket, you lose control over its lifecycle. It gets backed up, indexed, and replicated across multiple servers. If that platform is ever compromised — or if someone leaves their laptop unlocked at a coffee shop — your secret is exposed.

Even if you delete the message later, you can never be entirely sure it hasn’t been retained in a cache or a backup archive. The only reliable way to share a secret is to ensure it only exists long enough to be consumed, and that the transmission medium itself cannot read it.

Enter Burn-After-Read

A burn-after-read secret is designed to be viewed exactly once. The moment it is accessed, the underlying data is permanently deleted from the storage system. If a second person (or an automated link scraper) tries to access it, they’ll only find an empty void.

OtterSeal takes this a step further by combining self-destruction with end-to-end encryption and a clever URL trick to ensure that even our servers never see your sensitive data.

How OtterSeal Keeps Your Secrets Safe

When you use OtterSeal to share a secret, the security model ensures the decryption key never leaves the client environment. Here’s how it works:

  1. Local Encryption: The OtterSeal client (CLI or web app) generates a random encryption key locally on your machine. Your secret is encrypted with AES-256-GCM before it ever touches the network.

  2. The Encrypted Blob: The encrypted payload is sent to the OtterSeal server, along with your expiry policies (time-to-live or burn-after-read). The server stores this blob but has no way to read its contents.

  3. The URL Fragment Trick: The client generates a unique sharing link. The ID required to find the blob on the server is in the standard URL path. But the decryption key is appended as a fragment identifier — the part after the # symbol.

  4. Why the # Matters: By design, web browsers do not send the URL fragment to the server during an HTTP request. When your recipient clicks the link, the server only receives a request for the blob ID — it never sees the key. The browser decrypts the secret locally using the fragment. Because the key is in the hash, OtterSeal’s servers (and any proxies or logs in between) are cryptographically blind to your data.

Using the OtterSeal CLI

Sharing secrets securely shouldn’t slow down your workflow. The oseal CLI makes generating secure links fast and scriptable.

To send a secret that self-destructs immediately after it is read:

oseal secret send "super_secret_database_password_123" --selfDestruct

This outputs a secure URL. Once the recipient opens it, the OtterSeal server deletes the encrypted blob permanently. Any subsequent attempt to load the URL returns nothing.

You can also add a time-based expiration as a fallback — useful when the recipient might forget to open it:

oseal secret send "sk_live_stripe_key_example" --selfDestruct --expires 1h

This guarantees deletion after one hour, or immediately upon first view — whichever comes first. You can also skip the --selfDestruct and just use expiry alone for less sensitive use cases:

# Expires after 30 minutes, can be viewed multiple times
oseal secret send "temporary-access-code" --expires 30m

Practical Everyday Use Cases

This feature is incredibly versatile for day-to-day engineering and IT tasks:

  • Sharing API Keys: When onboarding a new developer, send the API key via a burn-after-read link instead of leaving a permanent record in Slack.
  • Resetting Passwords: IT helpdesks can share temporary passwords securely. Once the user views and logs in, the link is gone.
  • Customer Support: If a customer needs to provide sensitive diagnostic info or credentials, they can send it via OtterSeal without it sitting in an email thread forever.
  • CI/CD Secrets Bootstrap: When setting up a new server, use a burn-after-read link to securely transmit the initial secrets rather than storing them in a config file or environment variable that might get logged.

By making it trivial to share secrets securely, the goal is to make pasting plain text passwords a thing of the past. It’s a small change to your workflow that makes a significant difference to your security posture.

Ready to start sharing your secrets the safe way? Head to otterseal.ycmj.bot to try it out, or install the CLI globally with:

npm install -g @otterseal/cli

Keep your credentials out of your chat logs. Stay secure out there 🦦.