# Burn the Secret: public content Generated from public HTML. Private secret and account content is not included. # Burn the Secret Canonical URL: https://burnthesecret.com/ Markdown URL: https://burnthesecret.com/index.md # Securely Share Passwords with Self-Destructing Links Create encrypted temporary links with automatic expiry. Maximum lifetime: 90 days. No signup required. AES-256 Encryption Zero-Knowledge Temporary by design ## How It Works 1 ### Enter your secret Paste your password, API key, or any sensitive text into the form above. 2 ### Get a temporary link We encrypt your secret and give you a unique link with your selected expiry and view limit. 3 ### Share it securely Send the link to your recipient before it expires. Expired secrets and attachments are automatically deleted. ## Key Features ### One-time viewing Choose one view to delete content after the first retrieval. ### End-to-end encryption AES-256-GCM encryption protects your data in transit and at rest. ### No registration required Start sharing secrets instantly without creating an account. ### Custom expiration Choose a shorter expiry or share for up to 90 days. ### Passphrase protection Add an optional password for an extra layer of security. ### Burn on demand Delete your secret manually before it expires if needed. ## Security You Can Trust Burn the Secret uses zero-knowledge encryption, which means we never see or store your unencrypted secrets. Your data is encrypted in your browser using AES-256-GCM before it reaches our servers. We only store the encrypted ciphertext, and we do not have the keys to decrypt it. New secrets last at most 90 days, with shorter expiries available. Access ends at expiry, when burned, or when the view limit is reached. Expired secrets and attachments are automatically deleted from the active database and cannot be recovered through this service. ## Frequently Asked Questions ### How does secure password sharing work? Enter your password or sensitive data and choose an expiry and view limit. Burn the Secret generates an encrypted temporary link. Access ends at expiry, when burned, or when the view limit is reached. Expired secrets are automatically deleted from the active database. ### Is my password stored on your servers? Your data is encrypted in your browser before storage. New secrets expire within 90 days, or sooner if you choose. Expired secrets and attachments are automatically deleted from the active database and cannot be recovered through this service. ### What encryption do you use? We use AES-256-GCM encryption, the same standard used by banks and government agencies, to protect your sensitive information. Your data is encrypted in your browser before it reaches our servers. ### Do I need to create an account? No. You can create and share encrypted links without signing up. Creating an account gives you additional features like viewing your recent secrets and API access, but it is completely optional. ### Is this service free? Yes, Burn the Secret is completely free with no registration required. There are no premium tiers or paywalls. We believe everyone deserves access to secure password sharing. --- # Agent resources Canonical URL: https://burnthesecret.com/agents Markdown URL: https://burnthesecret.com/agents.md For agents and developers # Read the site, without the interface. Every public information page is available as Markdown. No JavaScript, account, or API key is needed to read these resources. All crawlers and scrapers are welcome. ## Discovery resources llms.txt ### Start here A concise overview and links to the right documents. [Read more](https://burnthesecret.com/llms.txt) Markdown bundle ### Full public content All public pages in a single text response. [Read more](https://burnthesecret.com/llms-full.txt) JSON ### Page inventory Public page URLs paired with their Markdown versions. [Read more](https://burnthesecret.com/agents.json) XML ### Agent sitemap Markdown documents and machine-readable discovery files. [Read more](https://burnthesecret.com/sitemap-agents.xml) XML ### Website sitemap Canonical public HTML pages. [Read more](https://burnthesecret.com/sitemap.xml) robots.txt ### Crawler policy All user agents are allowed to crawl. No crawler-specific exclusions. [Read more](https://burnthesecret.com/robots.txt) ## Using the service Burn the Secret shares encrypted text and files through temporary links. New secrets last at most 90 days, and unlimited views apply only until expiry. Existing secrets retain their saved expiry dates. The REST API supports anonymous creation; authentication is optional. The browser and CLI encrypt locally. Sending plaintext to the API uses server-side encryption, so that path is not zero-knowledge. See the [API reference](https://burnthesecret.com/api-docs) for limits and examples. Reading public pages is separate from acting on a secret. GET /api/secrets/:key reads status; POST to that endpoint reveals content and consumes a view. Burning or deleting a secret is destructive. Perform those actions only when the user requests them. These indexes contain public information only. Private secret URLs, receipts, and account data are not published here. Crawling permission does not bypass authentication, expiry, passphrases, or API rate limits. ## Public pages Append .md to a page URL, or use /index.md for the homepage. Markdown is regenerated from the public HTML on every production build. - [Burn the Secret](https://burnthesecret.com/)[Markdown ↗](https://burnthesecret.com/index.md) - [Agent resources](https://burnthesecret.com/agents)[Markdown ↗](https://burnthesecret.com/agents.md) - [API reference and CLI](https://burnthesecret.com/api-docs)[Markdown ↗](https://burnthesecret.com/api-docs.md) - [Documentation](https://burnthesecret.com/docs)[Markdown ↗](https://burnthesecret.com/docs.md) - [Pricing](https://burnthesecret.com/pricing)[Markdown ↗](https://burnthesecret.com/pricing.md) - [About](https://burnthesecret.com/about)[Markdown ↗](https://burnthesecret.com/about.md) - [Contact and abuse reporting](https://burnthesecret.com/contact)[Markdown ↗](https://burnthesecret.com/contact.md) - [Privacy policy](https://burnthesecret.com/privacy)[Markdown ↗](https://burnthesecret.com/privacy.md) - [Terms of service](https://burnthesecret.com/terms)[Markdown ↗](https://burnthesecret.com/terms.md) - [Brand assets](https://burnthesecret.com/brand)[Markdown ↗](https://burnthesecret.com/brand.md) - [Security guides](https://burnthesecret.com/guides)[Markdown ↗](https://burnthesecret.com/guides.md) - [How to share passwords securely](https://burnthesecret.com/guides/share-passwords-securely)[Markdown ↗](https://burnthesecret.com/guides/share-passwords-securely.md) - [One-time links explained](https://burnthesecret.com/guides/one-time-links-explained)[Markdown ↗](https://burnthesecret.com/guides/one-time-links-explained.md) - [Self-destructing messages](https://burnthesecret.com/guides/self-destructing-messages)[Markdown ↗](https://burnthesecret.com/guides/self-destructing-messages.md) - [Password sharing for remote teams](https://burnthesecret.com/guides/password-sharing-remote-teams)[Markdown ↗](https://burnthesecret.com/guides/password-sharing-remote-teams.md) - [Secure credential sharing for MSPs](https://burnthesecret.com/guides/secure-credential-sharing-msp)[Markdown ↗](https://burnthesecret.com/guides/secure-credential-sharing-msp.md) - [Share passwords with coworkers](https://burnthesecret.com/guides/share-passwords-with-coworkers)[Markdown ↗](https://burnthesecret.com/guides/share-passwords-with-coworkers.md) - [Send credentials to clients](https://burnthesecret.com/guides/sending-credentials-to-clients)[Markdown ↗](https://burnthesecret.com/guides/sending-credentials-to-clients.md) - [One-time link security](https://burnthesecret.com/guides/one-time-link-security)[Markdown ↗](https://burnthesecret.com/guides/one-time-link-security.md) - [Email versus secure links](https://burnthesecret.com/guides/email-vs-secure-links)[Markdown ↗](https://burnthesecret.com/guides/email-vs-secure-links.md) - [Enterprise password sharing](https://burnthesecret.com/guides/enterprise-password-sharing)[Markdown ↗](https://burnthesecret.com/guides/enterprise-password-sharing.md) - [Share a Wi-Fi password securely](https://burnthesecret.com/guides/share-wifi-password-securely)[Markdown ↗](https://burnthesecret.com/guides/share-wifi-password-securely.md) - [Send an SSH key securely](https://burnthesecret.com/guides/send-ssh-key-securely)[Markdown ↗](https://burnthesecret.com/guides/send-ssh-key-securely.md) - [Share database credentials](https://burnthesecret.com/guides/share-database-credentials)[Markdown ↗](https://burnthesecret.com/guides/share-database-credentials.md) - [Send API keys to clients](https://burnthesecret.com/guides/send-api-keys-to-clients)[Markdown ↗](https://burnthesecret.com/guides/send-api-keys-to-clients.md) - [One-Time Secret alternative](https://burnthesecret.com/guides/onetimesecret-alternative)[Markdown ↗](https://burnthesecret.com/guides/onetimesecret-alternative.md) - [PrivateBin alternative](https://burnthesecret.com/guides/privatebin-alternative)[Markdown ↗](https://burnthesecret.com/guides/privatebin-alternative.md) - [Share a password over Slack](https://burnthesecret.com/guides/share-password-over-slack)[Markdown ↗](https://burnthesecret.com/guides/share-password-over-slack.md) - [Share a password over email safely](https://burnthesecret.com/guides/share-password-over-email-safely)[Markdown ↗](https://burnthesecret.com/guides/share-password-over-email-safely.md) - [Send secrets to a new employee](https://burnthesecret.com/guides/send-secrets-to-new-employee)[Markdown ↗](https://burnthesecret.com/guides/send-secrets-to-new-employee.md) - [Share recovery and 2FA backup codes](https://burnthesecret.com/guides/share-recovery-codes-2fa-backup)[Markdown ↗](https://burnthesecret.com/guides/share-recovery-codes-2fa-backup.md) - [Privacy-conscious password sharing and GDPR](https://burnthesecret.com/guides/gdpr-compliant-password-sharing)[Markdown ↗](https://burnthesecret.com/guides/gdpr-compliant-password-sharing.md) - [How to send a password securely](https://burnthesecret.com/guides/how-to-send-a-password-securely)[Markdown ↗](https://burnthesecret.com/guides/how-to-send-a-password-securely.md) --- # API reference and CLI Canonical URL: https://burnthesecret.com/api-docs Markdown URL: https://burnthesecret.com/api-docs.md # API Documentation Integrate Burn the Secret into your applications to create secure, self-destructing secret links programmatically. ### Base URL `https://burnthesecret.com/api` ### AES-256-GCM Encryption Industry-standard authenticated encryption used by banks and governments. ### Zero-Knowledge Architecture Browser and CLI encryption keeps keys off our servers. Plaintext API submissions use server-side encryption. ### Self-Destructing Links Set view limits and expiration times. Links stop working at their view limit or expiry. ### RESTful JSON API Simple HTTP endpoints with consistent response formats. ## Authentication Authentication is **optional**. Anyone can create a secret without an API key—sending a key only attributes the secret to your account. To attribute a secret, include your key in the Authorization header: `Authorization: Bearer ks_live_your_api_key` Create API keys in your **Dashboard → API Access**. If you omit the header the request is still accepted (anonymous, or linked to your signed-in browser session). Only if you send a key that is invalid or revoked is the request rejected—with a `401 INVALID_API_KEY` response. ## Quick Start Create a secret link with a single API call: ``` curl -X POST https://burnthesecret.com/api/secrets \ -H "Authorization: Bearer ks_live_your_api_key" \ -H "Content-Type: application/json" \ -d '{"text": "my-sensitive-password", "ttl": 86400, "maxViews": 1}' ``` ## Command-Line Interface New Prefer the terminal? The `burnthesecret` CLI creates one-time links without leaving your shell. It encrypts on your machine (AES-256-GCM) and sends only the ciphertext — the decryption key stays in the link fragment, so it stays zero-knowledge, exactly like the web app. No dependencies; requires Node.js 18+. ``` # One-off, no install (Node.js 18+) npx burnthesecret "my secret" # From a pipe — great for CI and scripts echo "$DB_PASSWORD" | npx burnthesecret --ttl 3600 --views 1 # Require a passphrase, or attribute to your account with an API key npx burnthesecret "token" --passphrase "over-the-phone" npx burnthesecret "token" --api-key ks_live_... --json ``` Free and open source (MIT). It prints a single link — share that. Anyone with the full link can read the secret once, so treat the link like the secret. ## Endpoints POST`/secrets`Auth Optional Create a new secret link. Use one encryption mode for every item: either plaintext text and base64 data-URL files for server-side encryption, or client-encrypted text and files using the same AES key. Mixed modes are rejected. Client ciphertext must be canonical base64 with a 12-byte base64 IV. The browser and CLI preserve exact text, including whitespace. #### Request Body | Parameter | Type | Description | | --- | --- | --- | | text | string \| object | Secret content (2 MB combined plaintext; 4 MB encoded JSON maximum). A plain string (server encrypts it—not zero-knowledge) or `{ciphertext, iv}` you encrypted client-side (zero-knowledge) | | ttl | number | Time to live in whole seconds. 1800 (30 min) to 7776000 (90 days). Default: 86400 | | maxViews | number \| null | Max views (integer 1-999) or null for unlimited views until expiry. Default: 1 | | passphrase | string | Optional raw passphrase, 4-256 chars (send over HTTPS; hashed server-side with a salted KDF) | | files | array | Array (max 20) of files with filename, mimeType, data | #### Response ``` { "success": true, "secretUrl": "https://burnthesecret.com/secret/Kj8mNp2x...#key=...", "metadataUrl": "https://burnthesecret.com/receipt/Yz3nLq9b...", "metadata": { "key": "Yz3nLq9bFs7hGc...", "secretKey": "Kj8mNp2xQr5tVw...", "expiresAt": "2026-01-27T12:00:00.000Z", "maxViews": 1 } } ``` GET`/secrets/:key` Check if a secret exists and get metadata. Does not consume a view. ``` { "exists": true, "type": "secret", "hasPassphrase": false, "expiresAt": "2026-01-27T12:00:00.000Z", "maxViews": 1, "viewsRemaining": 1 } ``` POST`/secrets/:secretKey` Retrieve secret content. This consumes one view. #### Request Body (if passphrase protected) ``` { "passphrase": "your-passphrase" } ``` #### Response ``` { "success": true, "text": { "ciphertext": "base64-encoded...", "iv": "base64-encoded..." }, "viewsRemaining": 0 } ``` Decrypt using the key from the URL fragment with AES-256-GCM. DELETE`/secrets/:key` Permanently delete (burn) a secret. ``` curl -X DELETE https://burnthesecret.com/api/secrets/Yz3nLq9bFs7hGc... ``` ## Encryption Burn the Secret uses **AES-256-GCM**, the same encryption used by TLS 1.3, Signal, and government systems. #### Zero-Knowledge Architecture The decryption key is stored in the URL fragment (after #), which browsers never send to servers. We only store encrypted ciphertext—useless without the key. Decryption happens entirely in the recipient's browser. URL Structure: `https://burnthesecret.com/secret/secretKey#key=decryptionKey` #### Server-Side Encryption Send plaintext (or the legacy `secret` field)—we encrypt it server-side and return the URL with the key in the fragment. This path is **not** zero-knowledge: the server briefly holds the key. #### Client-Side Encryption Encrypt before sending as `{ciphertext, iv}`—you control the key. True zero-knowledge, maximum security. ## Rate Limits A baseline limit of **1,000 requests per day per IP and operation** applies before authentication. Signed-in creation also allows 100/hour and 1,000/day per account. API keys share 1,000/hour per owning account. Protected retrieval allows five attempts/minute per secret and IP, including empty attempts. Limits fail closed if their service is unavailable. Content limits are uniform: 2 MB combined text/files, 4 MB encoded JSON, 90 days, 999 views (or unlimited until expiry), and 20 files. #### Response Headers ``` X-RateLimit-Limit: 1000 X-RateLimit-Remaining: 950 X-RateLimit-Reset: 1706360400 ``` ## Errors All errors return a consistent JSON structure: ``` { "error": "Invalid passphrase", "code": "INVALID_PASSPHRASE", "hint": "Include the correct passphrase in your request.", "requestId": "req_abc123..." } ``` | Status | Code | Description | | --- | --- | --- | | 200 | — | Success | | 400 | INVALID\_\* | Bad request (invalid params) | | 401 | INVALID\_API\_KEY | A key was sent but is invalid or revoked (a key is optional; omitting it is fine) | | 403 | INVALID\_PASSPHRASE / DELETION\_NOT\_ALLOWED | Wrong passphrase, or burn attempted on a secret whose sender disabled deletion | | 404 | NOT\_FOUND | Secret not found | | 410 | SECRET\_EXPIRED / SECRET\_BURNED / MAX\_VIEWS\_REACHED | Secret is gone: expired, burned, or max views reached | | 429 | RATE\_LIMIT\_EXCEEDED / TOO\_MANY\_ATTEMPTS | Rate limit exceeded, or too many wrong passphrase attempts | | 500 | INTERNAL\_ERROR | Server error | Unknown keys and secrets removed by cleanup return 404 NOT\_FOUND. Retrieval may return 410 while an expired, burned, or exhausted status row still exists. Access ends at expiry; hourly cleanup removes expired rows and attachments from the active database, normally within one hour. New secrets last at most 90 days; existing secrets retain their saved expiry dates. ## Security Best Practices #### Choose the Right Encryption Mode - **Server-side:** Convenient—we handle encryption. Plaintext briefly in memory. - **Client-side:** Maximum security—you control the key entirely. #### Passphrase Tips Use 8+ characters with mixed case, numbers, symbols. Share passphrases via a different channel than the URL. #### Minimize Exposure Use the shortest TTL and lowest maxViews needed. For one-time credentials, use `maxViews: 1`. ## Code Examples ### Decrypting Retrieved Secrets #### JavaScript ``` const urlKey = window.location.hash.split('key=')[1]; const rawKey = Uint8Array.from( atob(urlKey.replace(/-/g, '+').replace(/_/g, '/')), c => c.charCodeAt(0) ); const key = await crypto.subtle.importKey( 'raw', rawKey, { name: 'AES-GCM' }, false, ['decrypt'] ); const ciphertext = Uint8Array.from(atob(response.text.ciphertext), c => c.charCodeAt(0)); const iv = Uint8Array.from(atob(response.text.iv), c => c.charCodeAt(0)); const plaintext = await crypto.subtle.decrypt( { name: 'AES-GCM', iv }, key, ciphertext ); const secret = new TextDecoder().decode(plaintext); ``` #### Python ``` from cryptography.hazmat.primitives.ciphers.aead import AESGCM import base64 key = base64.urlsafe_b64decode(url_key + '==') ciphertext = base64.b64decode(response['text']['ciphertext']) iv = base64.b64decode(response['text']['iv']) aesgcm = AESGCM(key) plaintext = aesgcm.decrypt(iv, ciphertext, None) secret = plaintext.decode('utf-8') ``` ### Client-Side Encryption For maximum security, encrypt before sending to Burn the Secret: #### JavaScript ``` // Generate key and IV const key = await crypto.subtle.generateKey( { name: 'AES-GCM', length: 256 }, true, ['encrypt'] ); const iv = crypto.getRandomValues(new Uint8Array(12)); // Encrypt const plaintext = new TextEncoder().encode('my-secret'); const ciphertext = await crypto.subtle.encrypt( { name: 'AES-GCM', iv }, key, plaintext ); // Export key for URL const rawKey = await crypto.subtle.exportKey('raw', key); const keyBase64 = btoa(String.fromCharCode(...new Uint8Array(rawKey))); // Send to API const response = await fetch('https://burnthesecret.com/api/secrets', { method: 'POST', headers: { 'Authorization': 'Bearer ks_live_...', 'Content-Type': 'application/json', }, body: JSON.stringify({ text: { ciphertext: btoa(String.fromCharCode(...new Uint8Array(ciphertext))), iv: btoa(String.fromCharCode(...iv)) } }) }); const data = await response.json(); const fullUrl = data.secretUrl + '#key=' + keyBase64; ``` --- # Documentation Canonical URL: https://burnthesecret.com/docs Markdown URL: https://burnthesecret.com/docs.md Burn the Secret API # Documentation The Burn the Secret API allows you to programmatically create, retrieve, and manage self-destructing secrets. Use it to securely share passwords, API keys, and sensitive information in your applications. ## Overview Burn the Secret is a secure secret-sharing service that encrypts sensitive information and generates self-destructing links. Secrets are automatically deleted after they expire or reach their view limit. **Base URL:** `https://burnthesecret.com/api` **Content Type:** All requests must use `application/json` ### Key Features - **Auto-expiring links** — Set TTL from 30 minutes to 90 days - **View limits** — Secrets auto-delete after a set number of views - **Password protection** — Optional passphrase for extra security - **File support** — Share files and text up to 2 MB combined - **Burn on demand** — Manually delete secrets at any time ## How It Works **1\. Create a secret** — Send your sensitive content to the API with optional settings like TTL, view limit, and passphrase. **2\. Get the secure link** — The API returns a unique URL that you can share with your recipient. **3\. Recipient views the secret** — When they open the link, the secret is decrypted and displayed. This counts as a view. **4\. Auto-destruct** — Once the view limit is reached or the TTL expires, access stops. Expired secrets and attachments are deleted from the active database by hourly cleanup, normally within one hour. New secrets last at most 90 days; existing secrets keep their saved expiry dates. Unlimited views never extend expiry. ## Authentication Authentication is **optional**. You can create secrets without any API key—sending a key only links the secret to your account. To attribute a secret, include your key in the`Authorization`header: HTTP Header ``` Authorization: Bearer ks_live_your_api_key ``` Get your API key from the [API Access](https://burnthesecret.com/api-docs) page in your dashboard. Omit the header and the request is still accepted (anonymous, or linked to your signed-in browser session). Only if you send a key that is invalid or revoked is the request rejected—with `401 INVALID_API_KEY`. Keep your API key secure and never expose it in client-side code. ## Create Secret Create a new encrypted secret with customizable expiration and view limits. `POST /api/secrets` ### Example Request cURL ``` curl -X POST https://burnthesecret.com/api/secrets \ -H "Content-Type: application/json" \ -H "Authorization: Bearer ks_live_your_api_key" \ -d '{ "secret": "my-super-secret-password", "ttl": 86400, "maxViews": 1, "passphrase": "optional-password" }' ``` ### Example Response JSON ``` { "success": true, "metadata": { "key": "abc123xyz", "secretKey": "def456uvw", "ttl": 86400, "expiresAt": "2025-01-27T12:00:00.000Z", "createdAt": "2025-01-26T12:00:00.000Z", "hasPassphrase": true, "hasText": true, "fileCount": 0, "maxViews": 1, "viewCount": 0, "serverEncrypted": true }, "secretUrl": "https://burnthesecret.com/secret/def456uvw#key=Zm9vYmFy...", "metadataUrl": "https://burnthesecret.com/receipt/abc123xyz", "requestId": "req_m4k7x2_abc123" } ``` ### JavaScript JavaScript ``` const response = await fetch('https://burnthesecret.com/api/secrets', { method: 'POST', headers: { 'Authorization': 'Bearer ks_live_your_api_key', 'Content-Type': 'application/json', }, body: JSON.stringify({ secret: 'my-sensitive-data', ttl: 86400, maxViews: 1, }), }); const data = await response.json(); console.log(data.secretUrl); ``` ### Python Python ``` import requests response = requests.post( 'https://burnthesecret.com/api/secrets', headers={ 'Authorization': 'Bearer ks_live_your_api_key', 'Content-Type': 'application/json', }, json={ 'secret': 'my-sensitive-data', 'ttl': 86400, 'maxViews': 1, } ) data = response.json() print(data['secretUrl']) ``` ## Understanding Key Types When you create a secret, the API returns two different keys. Understanding the difference is important: secretKey Used by **recipients** to view the secret content. Share this key (via the secretUrl) with the person who needs to see the secret. Viewing with this key increments the view count. metadataKey (key) Used by the **sender** to check status or delete the secret. This is your "receipt" - use it to see if the secret was viewed, or to burn it before the recipient sees it. ## Get Secret Status Check the status of a secret without viewing its content. Works with either key type. `GET /api/secrets/:key` ### Example Request cURL ``` curl https://burnthesecret.com/api/secrets/abc123xyz ``` ### Example Response JSON ``` { "exists": true, "type": "metadata", "viewed": false, "burned": false, "expiresAt": "2025-01-27T12:00:00.000Z", "hasPassphrase": true, "secretKey": "def456uvw", "maxViews": 1, "viewCount": 0, "viewsRemaining": 1, "requestId": "req_m4k9z4_ghi789" } ``` Note: This endpoint does not count as a view and does not reveal the secret content. ## View Secret Content Retrieve and view a secret's content. This increments the view count and may trigger deletion if the view limit is reached. Use the `secretKey` (not the metadataKey). `POST /api/secrets/:secretKey` ### Request Body | Parameter | Type | Description | | --- | --- | --- | | passphrase | string | Required if the secret is password-protected | ### Example Request cURL ``` curl -X POST https://burnthesecret.com/api/secrets/def456uvw \ -H "Content-Type: application/json" \ -d '{"passphrase": "optional-password"}' ``` ### Example Response JSON ``` { "success": true, "text": { "ciphertext": "base64-encoded-ciphertext...", "iv": "base64-encoded-iv..." }, "files": [], "oneClickRetrieval": true, "viewsRemaining": 0, "requestId": "req_m4k8y3_def456" } ``` The API returns the encrypted `text` as `{ ciphertext, iv }`, never a decrypted plaintext value. Decrypt it client-side using the key from the URL fragment (the part after `#`). ## Delete Secret Permanently delete (burn) a secret before it expires. You can burn with either the metadata key or the secret key. If the sender disabled deletion, burning with the secret key returns`403 DELETION_NOT_ALLOWED`. `DELETE /api/secrets/:key` ### Example Request cURL ``` curl -X DELETE https://burnthesecret.com/api/secrets/abc123xyz ``` ### Example Response JSON ``` { "success": true, "message": "Secret burned successfully", "requestId": "req_m4kaz5_jkl012" } ``` ## Request Parameters Parameters for the Create Secret endpoint. | Parameter | Type | Required | Description | | --- | --- | --- | --- | | secret | string | Yes | The content to encrypt (max 2 MB) | | ttl | integer | No | Time to live in whole seconds. Min: 1800 (30 min), Max: 7776000 (90 days). Default: 86400 (1 day) | | maxViews | integer \| null | No | Max views before deletion. 1-999, or null for unlimited views until expiry. Default: 1 | | passphrase | string | No | Raw passphrase, 4-256 chars (sent over HTTPS; hashed server-side). If set, required to view the secret | | oneClickRetrieval | boolean | No | Require click to reveal content. Default: true | | allowDeletion | boolean | No | Allow recipient to delete after viewing. Default: true | ## Error Handling All error responses follow a consistent format with an error code and helpful hint: JSON ``` { "error": "Invalid passphrase", "code": "INVALID_PASSPHRASE", "hint": "The secret is password-protected. Include the correct 'passphrase' in your request body.", "requestId": "req_m4kbz6_mno345" } ``` ### HTTP Status Codes | Status | Meaning | Description | | --- | --- | --- | | 200 | OK | Request succeeded | | 400 | Bad Request | Invalid or missing parameters | | 401 | Unauthorized | API key sent but invalid or revoked (a key is optional) | | 403 | Forbidden | Invalid passphrase, or burn blocked because the sender disabled deletion | | 404 | Not Found | Secret not found, expired, or already viewed | | 410 | Gone | Secret burned, expired, or max views reached | | 429 | Too Many Requests | Rate limit exceeded | | 500 | Server Error | Internal server error | ### Error Codes | Code | Description | | --- | --- | | INVALID\_KEY | Key format is invalid (must be alphanumeric) | | INVALID\_JSON | Request body is not valid JSON | | INVALID\_API\_KEY | API key was sent but is invalid or revoked (a key is optional) | | MISSING\_CONTENT | No secret content (text, secret, or files) provided in request | | CONTENT\_TOO\_LARGE | Secret exceeds the 2 MB content limit | | NOT\_FOUND | Secret doesn't exist or has been deleted | | INVALID\_PASSPHRASE | Wrong passphrase for protected secret | | SECRET\_BURNED | Secret was manually deleted by sender | | SECRET\_EXPIRED | Secret has passed its expiration time | | MAX\_VIEWS\_REACHED | Secret has reached maximum view count | | RATE\_LIMIT\_EXCEEDED | Too many requests, check Retry-After header | | INTERNAL\_ERROR | Server error, contact support if persistent | ## Rate Limits API requests are rate-limited per IP address on a sliding window. The limits below apply uniformly to every request—anonymous, signed in, or using an API key. There are no per-tier limits. | Resource | Limit | | --- | --- | | Max content size | 2 MB combined content | | Max TTL | 90 days | | Max view limit | 999 (or unlimited with null) | | Max files per secret | 20 | ### Rate Limit Headers All API responses include rate limit headers: - `X-RateLimit-Limit` — Maximum requests allowed - `X-RateLimit-Remaining` — Requests remaining in current window - `X-RateLimit-Reset` — Unix timestamp when the limit resets - `X-Request-Id` — Unique request identifier for debugging When rate limited, responses include a `Retry-After` header with seconds until reset. ### Ready to get started? Create your API key and start integrating Burn the Secret into your applications. [Get API Key](https://burnthesecret.com/api-docs) --- # Pricing Canonical URL: https://burnthesecret.com/pricing Markdown URL: https://burnthesecret.com/pricing.md # Free for everyone Burn the Secret has a single plan: free, with every feature included. ### Free $0/ no subscription Everything you need to share secrets securely. [](https://burnthesecret.com/) - One-time, self-destructing secret links - Passphrase protection - File attachments - Configurable link expiration - End-to-end encryption - API access with optional authentication ## Frequently Asked Questions ### How much does Burn the Secret cost? Burn the Secret is completely free. There are no paid tiers, trials, or hidden fees. ### Do I need an account? You can create secret links through the website or API without an account. Signing in adds account-linked secrets and API keys. ### How long do secrets stay available? New secrets last up to 90 days, with shorter expiries available. Access ends at expiry, when burned, or when the view limit is reached. Expired secrets and attachments are automatically deleted from the active database. ## Ready to get started? Start sharing secrets securely today. No credit card required. [](https://burnthesecret.com/) --- # About Canonical URL: https://burnthesecret.com/about Markdown URL: https://burnthesecret.com/about.md # Why I Built This I'm a developer and I care a lot about security. And honestly, watching people share passwords makes me a little crazy. Every day I see the same thing. Passwords sent in plain text over email. Credentials shared in Slack messages that live forever. API keys pasted into chat threads where anyone with access can see them. It happens everywhere. Startups, enterprises, junior devs, CTOs. Everyone does it. It kills me. Not because people are careless. But because there hasn't been a simple alternative. Security tools are complicated, enterprise-focused, or require everyone to create accounts and install software. So people take shortcuts. They do what's easy. I built Burn the Secret to make the secure option the easy option. Create an encrypted link in seconds. Share it however you want. Access ends at your selected expiry or view limit. New secrets last at most 90 days, and expired secrets are automatically deleted from the active database. This tool is free. It will always be free. It's a community tool designed to make the world a little safer, one encrypted password share at a time. No premium tiers, no paywalls. Everyone deserves access to basic security. I believe privacy isn't a luxury. Encryption shouldn't require a PhD. And sharing a password shouldn't mean compromising your security. If you're a developer, check out the [API docs](https://burnthesecret.com/api-docs). You can integrate Burn the Secret into your own tools and workflows. If you have any feedback, suggestions, or find any bugs, reach out. I'd love to hear from you. [hello@burnthesecret.com](mailto:hello@burnthesecret.com) Jack --- # Contact and abuse reporting Canonical URL: https://burnthesecret.com/contact Markdown URL: https://burnthesecret.com/contact.md # Contact Us Get in touch with the Burn the Secret team ## Email Us For general inquiries, support, feedback, or to report abuse, please reach out to us at: [hello@burnthesecret.com](mailto:hello@burnthesecret.com) --- # Privacy policy Canonical URL: https://burnthesecret.com/privacy Markdown URL: https://burnthesecret.com/privacy.md # Privacy Policy Last updated: September 17, 2026 ## 1\. Information We Collect Burn the Secret is designed with privacy as a core principle. We collect minimal information necessary to provide our service: - **Secret Content:** The browser and CLI encrypt content on your device before transmission; the decryption key is not sent to us. The optional plaintext API is different: it sends plaintext to our server for encryption, so it is not zero-knowledge. Filenames, MIME types, sizes, expiry, and access status are server-visible metadata. - **Operational Data:** Request counts and network identifiers for abuse prevention and service operation. Third-party analytics scripts are disabled in the application. - **Account Information:** Email address, optional name and profile image, authentication-provider account records, and sessions for registered users. ## 2\. How We Use Your Information We use collected information solely to: - Provide and maintain the Burn the Secret service - Improve user experience and service reliability - Send important service notifications to registered users - Ensure security and prevent abuse ## 3\. Data Retention New secrets have a maximum lifetime of 90 days from creation; shorter selected expiries still apply. Existing secrets keep their saved expiry dates. Access stops at expiry, when burned, or when the view limit is reached. Unlimited views do not extend the expiry date. Encrypted content is removed when burned or its view limit is reached; status metadata remains until expiry cleanup. Hourly cleanup deletes expired secrets, attachments, and status metadata from the active database, normally within one hour of expiry. These secrets cannot be recovered through this service. Active-database deletion does not promise immediate erasure from infrastructure backups. Account data is retained until you delete your account in Settings. This also removes its API keys, sessions, and associated secrets and attachments. Anonymous secrets are not associated with an account. Backup and processor retention require separate operational review; this page is not a compliance certification. ## 4\. Contact Us If you have questions about this Privacy Policy, please contact us at [hello@burnthesecret.com](mailto:hello@burnthesecret.com) --- # Terms of service Canonical URL: https://burnthesecret.com/terms Markdown URL: https://burnthesecret.com/terms.md # Terms of Service Last updated: January 25, 2025 ## 1\. Acceptance of Terms By accessing or using Burn the Secret, you agree to be bound by these Terms of Service. If you do not agree to these terms, you must immediately cease using our service. We reserve the right to modify these terms at any time, and your continued use constitutes acceptance of any changes. ## 2\. Description of Service Burn the Secret provides a secure way to share sensitive information through encrypted, self-destructing links. Our service allows you to share passwords, API keys, files, and other confidential data with recipients until the selected expiry or view limit is reached, or the secret is burned. New secrets last at most 90 days from creation; existing secrets retain their saved expiry dates. This is a temporary sharing service. Expired secrets and attachments are automatically deleted from the active database and cannot be recovered through this service. ## 3\. Prohibited Content and Activities You are strictly prohibited from using Burn the Secret to store, share, transmit, or link to any of the following: - **Illegal Content:** Any content that violates local, state, national, or international law, including but not limited to content related to illegal drugs, weapons, fraud, or other criminal activities. - **Pirated Material:** Copyrighted content shared without authorization, including software, movies, music, books, games, or any other protected intellectual property. - **Adult or Sexual Content:** Pornography, sexually explicit material, obscene content, or any material depicting sexual acts or nudity. - **Child Exploitation Material:** Any content depicting minors in sexual situations or any form of child abuse material. This will be reported to authorities immediately. - **Malicious Content:** Viruses, malware, ransomware, spyware, trojans, or any code designed to harm systems or steal data. - **Phishing or Scams:** Content designed to deceive users, steal credentials, or perpetrate fraud. - **Malicious Links:** Links to websites containing malware, phishing pages, illegal content, or sites designed to harm visitors. - **Harassment or Threats:** Content that harasses, threatens, stalks, or intimidates any individual or group. - **Hate Speech:** Content that promotes hatred, discrimination, or violence against individuals or groups based on race, ethnicity, religion, gender, sexual orientation, disability, or any other protected characteristic. - **Violence or Gore:** Graphic violence, gore, or content depicting real-world harm to humans or animals. - **Stolen Data or Credentials:** Data obtained through unauthorized access, data breaches, or hacking activities. - **Doxxing:** Personal information shared with intent to harass, harm, or enable others to harm an individual. - **Terrorism Content:** Content promoting, supporting, or inciting terrorist activities or violent extremism. - **Self-Harm Content:** Content promoting or encouraging suicide, self-harm, or eating disorders. This list is not exhaustive. We reserve the right to determine what constitutes prohibited content and to take action accordingly. ## 4\. Zero Tolerance Policy Burn the Secret maintains a zero tolerance policy for illegal, harmful, or immoral content. Violation of these terms may result in immediate termination of access, deletion of content, and reporting to appropriate law enforcement authorities. We cooperate fully with law enforcement investigations and will provide any available information when legally required. ## 5\. Content Responsibility You are solely responsible for the content you share through Burn the Secret. While our encryption prevents us from routinely viewing content, we reserve the right to investigate reported abuse and cooperate with legal authorities. You warrant that you have the legal right to share any content you transmit and that such content does not violate any laws or these Terms of Service. ## 6\. Reporting Violations If you become aware of any content or activity that violates these Terms of Service, please report it immediately to [hello@burnthesecret.com](mailto:hello@burnthesecret.com). We take all reports seriously and will investigate promptly. ## 7\. Limitation of Liability Burn the Secret is provided "as is" without warranties of any kind, express or implied. We are not liable for any damages arising from your use of the service, including but not limited to data loss, security breaches, service interruptions, or any harm caused by content shared by users. You use this service at your own risk. ## 8\. Indemnification You agree to indemnify and hold harmless Burn the Secret, its operators, affiliates, and employees from any claims, damages, losses, or expenses arising from your use of the service or violation of these Terms of Service. ## 9\. Termination We reserve the right to terminate or suspend your access to Burn the Secret at any time, for any reason, without prior notice. This includes but is not limited to violations of these Terms of Service. ## 10\. Governing Law These Terms of Service shall be governed by and construed in accordance with applicable laws. Any disputes arising from these terms or your use of Burn the Secret shall be resolved in the appropriate courts. ## 11\. Contact Us If you have questions about these Terms of Service, please contact us at [hello@burnthesecret.com](mailto:hello@burnthesecret.com). For abuse reports, contact [hello@burnthesecret.com](mailto:hello@burnthesecret.com). --- # Brand assets Canonical URL: https://burnthesecret.com/brand Markdown URL: https://burnthesecret.com/brand.md # Brand Assets Download official Burn the Secret logos for use in your projects, articles, or integrations. Please use these assets responsibly and do not modify them. BURN THE SECRET ### Light Logo For dark backgrounds BURN THE SECRET ### Dark Logo For light backgrounds ## Square Logos (Social Profiles) 400x400 pixel square logos optimized for social media profile pictures and app icons. ![Square Light](https://burnthesecret.com/logos/burnthesecret-square-light.svg) ### Square Light Dark background square (400x400) ![Square Dark](https://burnthesecret.com/logos/burnthesecret-square-dark.svg) ### Square Dark Light background square (400x400) ## Favicons 32x32 pixel favicons for browser tabs and bookmarks. ![Favicon Dark](https://burnthesecret.com/logos/favicon-dark.svg) ### Favicon Dark Dark background (32x32) ![Favicon Light](https://burnthesecret.com/logos/favicon-light.svg) ### Favicon Light Light background (32x32) ## Usage Guidelines - ✓Use the light logo on dark backgrounds - ✓Use the dark logo on light backgrounds - ✓Maintain the aspect ratio when resizing - ✗Do not modify, distort, or add effects to the logo - ✗Do not use the logo to imply endorsement ## Brand Colors Primary Dark #09090b Surface #18181b Primary Light #fafafa Muted #a1a1aa ## Typography Logo Font JetBrains Mono Body Font Inter --- # Security guides Canonical URL: https://burnthesecret.com/guides Markdown URL: https://burnthesecret.com/guides.md # Security Guides Practical advice on sharing passwords, credentials, and sensitive information without putting your security at risk. ## How to Share Passwords Securely in 2025 How to share passwords safely using encryption, one-time links, and zero-knowledge security. Read more [Read more](https://burnthesecret.com/guides/share-passwords-securely) ## One-Time Links Explained: Security for IT Teams How one-time secret links work and why IT teams use them for secure credential sharing. Read more [Read more](https://burnthesecret.com/guides/one-time-links-explained) ## Self-Destructing Messages: Complete Guide Everything you need to know about self-destructing messages and how to use them for sensitive communications. Read more [Read more](https://burnthesecret.com/guides/self-destructing-messages) ## Password Sharing Best Practices for Remote Teams How distributed teams can securely share credentials without compromising security or productivity. Read more [Read more](https://burnthesecret.com/guides/password-sharing-remote-teams) ## Secure Credential Sharing for MSPs and IT Support Best practices for managed service providers and IT support teams handling client credentials. Read more [Read more](https://burnthesecret.com/guides/secure-credential-sharing-msp) ## How to Securely Share Passwords with Coworkers A practical guide for sharing login credentials with colleagues without putting your organization at risk. Read more [Read more](https://burnthesecret.com/guides/share-passwords-with-coworkers) ## Best Practices for Sending Credentials to Clients Professional methods for delivering passwords and API keys to clients securely and efficiently. Read more [Read more](https://burnthesecret.com/guides/sending-credentials-to-clients) ## One-Time Link Security: How It Works A deep dive into the cryptographic principles that make one-time links secure for sensitive data. Read more [Read more](https://burnthesecret.com/guides/one-time-link-security) ## Comparing Password Sharing Methods: Email vs Secure Links Why emailing passwords is dangerous and how secure links provide better protection for your credentials. Read more [Read more](https://burnthesecret.com/guides/email-vs-secure-links) ## Enterprise Password Sharing: Compliance and Security Meeting regulatory requirements while maintaining secure credential sharing practices in enterprise environments. Read more [Read more](https://burnthesecret.com/guides/enterprise-password-sharing) ## How to Send a Password Securely The safest way to send a password to anyone: an encrypted, one-time link that self-destructs after it's viewed. Read more [Read more](https://burnthesecret.com/guides/how-to-send-a-password-securely) ## How to Share a WiFi Password Securely Share a network password with guests or staff without it lingering in chat history or sticky notes. Read more [Read more](https://burnthesecret.com/guides/share-wifi-password-securely) ## How to Send an SSH Key Securely Deliver an SSH private key or key passphrase to a teammate or contractor without leaving it in email or Slack. Read more [Read more](https://burnthesecret.com/guides/send-ssh-key-securely) ## How to Share Database Credentials Securely Hand off database connection strings and credentials to a freelancer or contractor with a one-time encrypted link. Read more [Read more](https://burnthesecret.com/guides/share-database-credentials) ## How to Send API Keys to Clients Safely A professional way to deliver API keys and tokens to clients that self-destructs after a single view. Read more [Read more](https://burnthesecret.com/guides/send-api-keys-to-clients) ## How to Share a Password Over Slack Safely Why pasting passwords into Slack is risky, and how to send a one-time link instead. Read more [Read more](https://burnthesecret.com/guides/share-password-over-slack) ## How to Share a Password Over Email Safely Emailing passwords leaves them in inboxes forever. Send a self-destructing link that can only be opened once. Read more [Read more](https://burnthesecret.com/guides/share-password-over-email-safely) ## How to Send Secrets to a New Employee Securely Onboard new hires by delivering credentials through encrypted, one-time links instead of plaintext messages. Read more [Read more](https://burnthesecret.com/guides/send-secrets-to-new-employee) ## How to Share 2FA Recovery Codes Securely Share MFA backup and recovery codes with a one-time, end-to-end encrypted link that disappears after viewing. Read more [Read more](https://burnthesecret.com/guides/share-recovery-codes-2fa-backup) ## Privacy-Conscious Password Sharing and GDPR How one-time, self-destructing, encrypted links help minimize data-at-rest when sharing credentials. Read more [Read more](https://burnthesecret.com/guides/gdpr-compliant-password-sharing) ## A One-Time Secret Alternative: Burn the Secret Looking for a One-Time Secret alternative? A free, zero-knowledge, one-time secret sharing tool with a REST API. Read more [Read more](https://burnthesecret.com/guides/onetimesecret-alternative) ## A PrivateBin Alternative: Burn the Secret A hosted, zero-knowledge alternative to PrivateBin for sharing one-time, self-destructing secrets. Read more [Read more](https://burnthesecret.com/guides/privatebin-alternative) Ready to start sharing secrets securely? [Create a Secure Link](https://burnthesecret.com/) --- # How to share passwords securely Canonical URL: https://burnthesecret.com/guides/share-passwords-securely Markdown URL: https://burnthesecret.com/guides/share-passwords-securely.md [Back to Guides](https://burnthesecret.com/guides) # How to Share Passwords Securely in 2025 A practical guide to sharing passwords safely using encryption and one-time links. Sharing passwords is something we all need to do. Whether it's giving a colleague access to a shared account, sending login credentials to a client, or sharing a streaming service password with family—the need comes up regularly. The problem is that most people do it wrong, putting their accounts and sensitive data at risk. ## Why traditional methods fail Before we look at secure methods, let's understand why common approaches are dangerous. **Email** is probably the most common way people share passwords. It's also one of the worst. Emails are stored indefinitely on servers, can be forwarded to anyone, and are often unencrypted in transit. If someone gets into your email account years from now, they'll find every password you ever sent. **Text messages** aren't much better. SMS isn't encrypted and can be intercepted. Messages persist on devices and carrier servers. And phones get lost, stolen, or compromised. **Slack and Teams** feel private, but messages are stored in searchable company archives. Administrators can access them. Former employees might still have copies. It's not designed for sensitive data. **Shared documents** like Google Docs or Notion pages seem convenient, but passwords sitting there can be accessed by anyone with document access—which often includes more people than you realize. ## The secure approach: one-time links One-time links solve the fundamental problem of password sharing: persistence. When you send a password through a one-time link, the password is encrypted and stored temporarily. Once the recipient views it, the link is destroyed and the password is permanently deleted. This means there's no email sitting in an inbox, no message in a chat history, no document that could be accessed later. The password exists only long enough to be delivered. Good one-time link services also use end-to-end encryption. Your password is encrypted in your browser before it ever leaves your device. The server only stores encrypted data it can't read. The encryption key is part of the URL itself (in the fragment after the # symbol), which browsers never send to servers. ## How to share a password securely Here's the process: 1. Go to [Burn the Secret.io](https://burnthesecret.com/) and enter the password you want to share. 2. Optionally add a passphrase for extra security. The recipient will need this to view the password. 3. Choose how many views to allow and when the link should expire. 4. Click "Create Secret Link" to generate an encrypted, one-time link. 5. Send the link to your recipient through any channel. Even if the link is intercepted, the encryption protects the content. And if you use a passphrase, send it through a different channel (link via email, passphrase via text) for additional security. ## Best practices A few tips to make password sharing even more secure: - Use a separate channel for the passphrase. Send the link via email and the passphrase via text, or vice versa. - Set the shortest expiration time that makes sense. If your recipient will see it within an hour, don't let the link live for a week. - Ask the recipient to confirm when they've retrieved the password. This way you know it wasn't intercepted by someone else. - Use unique passwords for each account. Never share a master password or one that you use elsewhere. - Consider if the person really needs ongoing access. Sometimes it's better to change the password after sharing so they only have temporary access. ## When to use secure password sharing One-time links are ideal for: - Sharing login credentials with a new team member or contractor - Sending API keys or access tokens to developers - Providing temporary access to accounts for troubleshooting - Sharing WiFi passwords with guests - Sending credentials to clients after project completion - Sharing family account passwords securely Ready to share a password securely? [Create a secure link](https://burnthesecret.com/) on Burn the Secret. ## Related guides [One-Time Links Explained →](https://burnthesecret.com/guides/one-time-links-explained)[Email vs Secure Links →](https://burnthesecret.com/guides/email-vs-secure-links) --- # One-time links explained Canonical URL: https://burnthesecret.com/guides/one-time-links-explained Markdown URL: https://burnthesecret.com/guides/one-time-links-explained.md [Back to Guides](https://burnthesecret.com/guides) # One-Time Links Explained: Security for IT Teams How one-time secret links work and why IT teams rely on them for secure credential sharing. One-time links (also called one-time secrets or ephemeral links) are a security mechanism for sharing sensitive information that self-destructs after being viewed. For IT teams handling credentials, API keys, and access tokens daily, understanding how these links work helps maintain security. ## How one-time links work The core principle is simple: create a link that can only be accessed once, then permanently destroy the content. But the implementation involves several security layers working together. **Step 1: Client-side encryption.** When you create a secret, an AES-256-GCM encryption key is generated in your browser. Your data is encrypted locally before being sent to the server. The encryption key is added to the URL fragment (after the # symbol), which is never transmitted to the server. **Step 2: Server storage.** The encrypted ciphertext is stored on the server along with metadata like expiration time and view count. The server only sees encrypted data and cannot read the original content. **Step 3: Client-side decryption.** When the recipient opens the link, their browser extracts the encryption key from the URL fragment, fetches the encrypted data from the server, and decrypts it locally. **Step 4: Automatic destruction.** After the allowed number of views, the encrypted data is permanently deleted from the server. Even if someone saved the link, it will no longer work. ## Zero-knowledge architecture The key innovation in modern one-time link services is zero-knowledge architecture. This means the server operator (including Burn the Secret) cannot access your secrets, even if compelled to do so. This is achieved through the URL fragment mechanism. In web browsers, everything after the # symbol in a URL is never sent to the server. By placing the encryption key in the fragment, we ensure that: - The server only stores encrypted, unreadable data - Only someone with the complete link (including the fragment) can decrypt the content - Server logs and database backups contain no useful information - Even a server breach would not expose your secrets ## Why IT teams need one-time links IT teams face unique challenges when sharing sensitive information. Here are a few common scenarios where one-time links help: **Credential rotation.** When rotating passwords or API keys, one-time links ensure the old credentials aren't sitting in email threads or chat histories. **New employee onboarding.** Share initial login credentials securely without creating a permanent record that could be compromised later. **Vendor access.** Provide temporary credentials to contractors or vendors without worrying about long-term exposure. **Incident response.** During security incidents, share emergency credentials without adding to the communication trail. ## Security considerations While one-time links are significantly more secure than email or chat, there are still some things to keep in mind: **Link interception.** If someone intercepts the link before the intended recipient, they can view and destroy the secret. Use passphrase protection for highly sensitive data. **Browser history.** The complete URL (including fragment) may be stored in browser history. Recipients should use private/incognito mode for sensitive links. **Screenshot/copy.** Once decrypted, the recipient can screenshot or copy the content. One-time links protect transmission, not what happens after viewing. ## Implementing in your IT workflow Here's how to integrate one-time links into your IT operations: 1. **Create a policy:** Define when one-time links should be used (always for credentials, API keys, etc.) 2. **Use the API:** For automated workflows, integrate with the [Burn the Secret API](https://burnthesecret.com/api-docs) to generate links programmatically. 3. **Train your team:** Ensure everyone understands why one-time links are important and how to use them. 4. **Verify receipt:** Establish a practice of confirming when credentials have been successfully retrieved. Ready to start using one-time links? [Create a secure link](https://burnthesecret.com/) on Burn the Secret. ## Related guides [One-Time Link Security: How It Works →](https://burnthesecret.com/guides/one-time-link-security)[Secure Credential Sharing for MSPs →](https://burnthesecret.com/guides/secure-credential-sharing-msp) --- # Self-destructing messages Canonical URL: https://burnthesecret.com/guides/self-destructing-messages Markdown URL: https://burnthesecret.com/guides/self-destructing-messages.md [Back to Guides](https://burnthesecret.com/guides) # Self-Destructing Messages: Complete Guide Everything you need to know about self-destructing messages and how to use them for sensitive communications. Self-destructing messages, also known as ephemeral messages, are communications designed to automatically delete themselves after being read or after a set period of time. They're useful for sharing sensitive information that shouldn't persist in digital records. ## What are self-destructing messages? Unlike regular messages that remain in inboxes, chat histories, and server logs indefinitely, self-destructing messages have a built-in expiration. Once the conditions for destruction are met (viewed, time elapsed, or both), the message is permanently erased. There are three main types: - **Burn after reading:** Message is deleted immediately after being viewed once. - **Time-based expiry:** Message automatically expires after a set duration (hours, days). - **View limited:** Message can be viewed a specific number of times before deletion. ## Why use self-destructing messages? Traditional communication methods create permanent records. Every email you send, every Slack message, every text sits on servers waiting to be discovered in a data breach, legal discovery, or by a curious administrator. Self-destructing messages solve this by ensuring: - **No lingering sensitive data:** Passwords, API keys, and credentials don't sit in email archives for years. - **Reduced breach impact:** If a system is compromised, historical secrets have already been destroyed. - **Compliance benefits:** Minimizing data retention helps meet regulatory requirements. - **Peace of mind:** Know that sensitive information has a defined lifecycle. ## Common use cases **Password sharing.** Share login credentials with colleagues or clients without leaving a permanent record. The password link expires after viewing, ensuring it can't be accessed later. **API keys and tokens.** Send API keys, access tokens, or other developer credentials securely. Once the developer retrieves them, the secret is destroyed. **Confidential documents.** Share sensitive files that should only be accessed once. Contracts, financial data, or personal information can be shared with automatic deletion. **Temporary access codes.** Share WiFi passwords, door codes, or temporary access credentials with guests or contractors that automatically expire. ## How Burn the Secret's self-destructing messages work Burn the Secret combines self-destruction with end-to-end encryption for maximum security: 1. **Encrypt:** Your message is encrypted in your browser using AES-256-GCM before being sent to our servers. 2. **Store:** Only the encrypted ciphertext is stored. The encryption key stays in the URL fragment, never touching our servers. 3. **Retrieve:** When the recipient opens the link, the encrypted data is sent to their browser for decryption. 4. **Destroy:** After the allowed views, the encrypted data is permanently deleted from our database. ## Best practices - **Use appropriate expiration times:** For urgent credentials, use short expirations (1-24 hours). For less time-sensitive items, longer expirations are fine. - **Add passphrase protection:** For highly sensitive data, add a passphrase and communicate it through a separate channel. - **Verify receipt:** Ask the recipient to confirm they received the message successfully. If they didn't, you know the link was accessed by someone else. - **Use single view when possible:** For most credential sharing, one view is sufficient. Multiple views increases the window of exposure. - **Don't rely solely on self-destruction:** Remember that the recipient can still copy or screenshot the content. Self-destruction protects the transmission, not what happens after viewing. ## Self-destructing vs. encrypted messaging apps Apps like Signal and WhatsApp offer disappearing messages, but there are key differences. Messaging apps require both parties to have accounts. Burn the Secret works with anyone—just send a link. With messaging apps, you can't always confirm the message was read before disappearing. With one-time links, when the link stops working, you know it was viewed. One-time links also work with any communication channel. You can send the link via email, SMS, Slack, or any other platform. Ready to create a self-destructing message? [Get started](https://burnthesecret.com/) on Burn the Secret. ## Related guides [How to Share Passwords Securely →](https://burnthesecret.com/guides/share-passwords-securely)[One-Time Links Explained →](https://burnthesecret.com/guides/one-time-links-explained) --- # Password sharing for remote teams Canonical URL: https://burnthesecret.com/guides/password-sharing-remote-teams Markdown URL: https://burnthesecret.com/guides/password-sharing-remote-teams.md [Back to Guides](https://burnthesecret.com/guides) # Password Sharing Best Practices for Remote Teams How distributed teams can securely share credentials without compromising security or productivity. Remote work has transformed how teams collaborate, but it's also created new security challenges. Without the ability to whisper a password across the desk, distributed teams need secure digital methods to share credentials. Unfortunately, most teams default to the easiest option: Slack messages, emails, or shared documents. ## The remote team security challenge Remote teams face unique challenges when sharing passwords: **Geographic distribution.** Team members across time zones can't easily coordinate real-time credential sharing. **Personal devices.** BYOD policies mean passwords might end up on personal devices with varying security levels. **Contractor turnover.** Freelancers and contractors may need temporary access without long-term credential storage. **Network insecurity.** Team members working from cafes, airports, or home networks with varying security. ## What not to do Before diving into best practices, let's address what many remote teams get wrong: - **Passwords in Slack/Teams:** These platforms keep searchable histories. A compromised account exposes all past credentials. - **Shared spreadsheets:** Google Sheets or Excel files with passwords are a security nightmare. Anyone with access can copy them. - **Email forwarding chains:** Passwords get forwarded, CC'd, and end up in multiple inboxes indefinitely. - **Notion/wiki pages:** Documentation tools are great for processes, not for storing live credentials. - **Text messages:** SMS is unencrypted and persists on carrier servers and device backups. ## Best practices for remote password sharing ### Use one-time links for ad-hoc sharing For occasional credential sharing, one-time links provide the best balance of security and convenience. Create a secure link with the credential, send it via any channel, and the credential is encrypted and deletes after viewing. Optionally add passphrase protection for extra security. ### Establish clear credential sharing protocols Document when and how credentials should be shared. Define who can request credentials and the approval chains for sensitive access. Specify which method to use—one-time links for temporary sharing, password managers for persistent access. Always verify requests through a second channel, and set expiration policies so contractor credentials expire with their contract. ### Implement time-based access Remote teams often work asynchronously, making time-based access control important. Set link expirations that match the recipient's time zone. Use longer expirations for team members in distant time zones. Always set an expiration, even if it's generous—never create permanent links. ### Verify before sharing Social engineering attacks target remote workers because verification is harder. Before sharing any credential, confirm the request through a different channel than it was made. Be suspicious of urgent requests, especially from "executives." Use video calls for high-value credential sharing. ## Recommended workflow Here's a secure process for sharing credentials with your remote team: 1. **Request verification:** Confirm the credential request is legitimate via a separate channel (e.g., Slack DM to verify an email request). 2. **Create one-time link:** Use Burn the Secret to create an encrypted, self-destructing link with the credential. 3. **Add passphrase (optional):** For highly sensitive credentials, add a passphrase and share it separately. 4. **Send the link:** Share through your team's standard communication channel. 5. **Confirm receipt:** Ask the recipient to confirm they successfully accessed the credential. ## Special scenarios **New employee onboarding.** When onboarding remote employees, prepare all initial credentials in advance as separate one-time links. Send links during the onboarding call so you can verify receipt. Use separate links for each credential (don't bundle them). Have the new hire confirm each credential works before proceeding. **Contractor/freelancer access.** Always use view-limited or time-limited links. Create project-specific accounts when possible instead of sharing main credentials. Rotate credentials when the contract ends. Document what access was provided and when it should be revoked. **Emergency access.** For urgent situations when the credential owner isn't available, pre-create emergency one-time links and store the URLs securely. Use longer expirations for emergency credentials. Ensure at least two people know how to access emergency credentials. Ready to secure your remote team's credential sharing? [Create a secure link](https://burnthesecret.com/) on Burn the Secret. ## Related guides [Share Passwords with Coworkers →](https://burnthesecret.com/guides/share-passwords-with-coworkers)[Sending Credentials to Clients →](https://burnthesecret.com/guides/sending-credentials-to-clients) --- # Secure credential sharing for MSPs Canonical URL: https://burnthesecret.com/guides/secure-credential-sharing-msp Markdown URL: https://burnthesecret.com/guides/secure-credential-sharing-msp.md [Back to Guides](https://burnthesecret.com/guides) # Secure Credential Sharing for MSPs and IT Support Best practices for managed service providers and IT support teams handling client credentials securely. Managed Service Providers (MSPs) and IT support teams handle some of the most sensitive data in any organization: administrator passwords, API keys, database credentials, and root access tokens. A single leaked credential can compromise an entire client's infrastructure. This guide covers how to share these credentials securely while maintaining operational efficiency. ## The MSP credential challenge MSPs face a unique security paradox: they need access to everything to do their job, but that access creates enormous risk. A typical MSP might manage domain admin credentials for dozens of clients, cloud console access (AWS, Azure, GCP) with root privileges, database credentials for production systems, API keys for critical integrations, SSL certificates and private keys, and VPN and firewall configurations. Each of these credentials needs to be shared with team members, documented for emergency access, and sometimes delivered to clients. Traditional methods like email or shared documents create unacceptable risk. ## Common credential sharing scenarios **Client to MSP.** Clients need to provide initial access credentials when onboarding. This often includes domain admin, cloud console access, and existing service accounts. **MSP to client.** After provisioning services, MSPs deliver new credentials back to clients: new user accounts, application passwords, or API keys. **Internal team sharing.** Technicians need to share credentials for escalations, shift handoffs, or collaborative troubleshooting. **Emergency access.** Critical credentials need to be accessible during emergencies when the primary administrator isn't available. ## Best practices for MSP credential security ### Never email credentials This seems obvious, but email remains the most common way credentials are shared. Emails persist in sent folders, inboxes, and backups indefinitely. Email threads get forwarded, exposing credentials to unintended recipients. Email isn't encrypted by default in transit. Compromised email accounts expose historical credentials. Instead, use one-time links for all credential sharing. Send the link via email if needed—the actual credential is encrypted and auto-deletes after viewing. ### Use passphrase protection for high-value credentials For domain admin, root, or cloud console credentials, add an extra layer. Create the one-time link with a passphrase, send the link via the primary channel (email, ticket), and communicate the passphrase via a different channel (phone, SMS, video call). This ensures that even if one channel is compromised, the credential remains protected. ### Verify credential receipt Always confirm that the intended recipient accessed the credential. With one-time links, if the recipient says they didn't receive it but the link has been viewed, you know it was intercepted. ### Document without storing credentials Your documentation should reference that credentials exist and how to obtain them, not the credentials themselves. For example: "Domain admin credentials stored in password manager under Client X folder" or "AWS root access: request from security team, 2FA via john@company.com." Never write the actual password in documentation. ## Workflow: Secure client onboarding When collecting credentials from new clients: 1. Send the client a link explaining how to create a secure one-time link at [burnthesecret.com](https://burnthesecret.com/) 2. Have the client create separate links for each credential type (domain admin, cloud console, etc.) 3. Retrieve each credential and verify it works before the link expires 4. Immediately transfer to your secure credential storage 5. For highly sensitive access, rotate the password after secure storage ## Workflow: Delivering credentials to clients After provisioning new services: 1. Generate a secure link for each credential you need to deliver 2. Set appropriate expiration times (24-72 hours gives clients time to retrieve) 3. Include the links in your service delivery email with clear labeling 4. Note in the ticket that credentials were delivered via one-time link 5. Follow up to confirm the client successfully retrieved the credentials ## API integration for automation For MSPs with high volume credential sharing, Burn the Secret's API enables automation. You can integrate with PSA tools to auto-generate credential links during provisioning, automatically include secure links in onboarding email templates, and create links programmatically when scripts generate new credentials. See our [API documentation](https://burnthesecret.com/api-docs) for integration details. ## Compliance considerations One-time links help MSPs meet various compliance requirements. For SOC 2, they demonstrate secure credential handling with an audit trail. For HIPAA, they protect PHI-adjacent credentials with encryption and auto-deletion. For PCI DSS, they ensure payment system credentials aren't stored insecurely. For GDPR, they minimize data retention of credential communications. Ready to secure your MSP's credential sharing? [Create a secure link](https://burnthesecret.com/) on Burn the Secret. ## Related guides [Enterprise Password Sharing →](https://burnthesecret.com/guides/enterprise-password-sharing)[Sending Credentials to Clients →](https://burnthesecret.com/guides/sending-credentials-to-clients) --- # Share passwords with coworkers Canonical URL: https://burnthesecret.com/guides/share-passwords-with-coworkers Markdown URL: https://burnthesecret.com/guides/share-passwords-with-coworkers.md [Back to Guides](https://burnthesecret.com/guides) # How to Securely Share Passwords with Coworkers A practical guide for sharing login credentials with colleagues without putting your organization at risk. We've all been there. A coworker needs access to a shared account, a new team member is starting and needs login credentials, or someone's locked out and needs a password reset. The temptation is to just type it into Slack or fire off a quick email. But every time you do that, you're creating a security risk that could come back to haunt you. ## Why you shouldn't just Slack it Let's be real about why the quick-and-easy approach is dangerous. **Chat messages are searchable.** Anyone with admin access can search Slack or Teams for "password" and find every credential ever shared. Former employees might still have access to exported chat histories. **Email lives forever.** That email with the WiFi password from 2019? It's still sitting in someone's inbox. Email threads get forwarded, CC'd, and backed up across multiple systems. **Account compromises cascade.** If a coworker's account is compromised, the attacker gets access to every password that was ever shared with them via chat or email. ## The better way: one-time links One-time links solve the persistence problem. Instead of sending the password directly, you send a link to the password. Once your coworker clicks it, the password is revealed and then permanently deleted. The difference is simple. With Slack, a message like "Hey, the Netflix password is streamingFun2024!" is visible in search forever. With a one-time link, you send "Hey, here's the Netflix password: burnthesecret.com/secret/abc123" and the link expires after viewing. ## How to share with a coworker 1. Go to [Burn the Secret.io](https://burnthesecret.com/) and enter the password or credential you need to share. 2. Click "Create Secret Link" to generate an encrypted one-time link. 3. Copy the link and send it to your coworker via Slack, email, or wherever. 4. Your coworker clicks the link, sees the password, and the link is destroyed. ## Common scenarios at work **New employee needs access to shared accounts.** Create a one-time link for each account instead of adding credentials to an onboarding doc. The link expires, but the doc would live forever. **Covering for someone on vacation.** Need temporary access to a coworker's account? They can send a one-time link with the password. When they're back, they should change it. **Sharing WiFi or printer passwords.** Instead of posting the office WiFi password in a Slack channel, send one-time links to new team members who need it. **Shared service accounts.** Social media logins, analytics tools, or other shared accounts can be shared via one-time links instead of pinned messages. ## Tips for workplace password sharing - **Ask for confirmation:** Have your coworker let you know when they've successfully retrieved the password. - **Don't include usernames:** If possible, send only the password. If the username is obvious (like a shared email address), don't bundle it with the password. - **Consider passphrase protection:** For sensitive credentials, add a passphrase and tell your coworker verbally or via a different channel. - **Rotate after temporary sharing:** If you shared a password for temporary access, change it when that access is no longer needed. - **Use the QR code:** For in-person sharing, show the QR code on your screen and let your coworker scan it with their phone. ## Getting your team on board The hardest part of secure password sharing isn't the tools—it's changing habits. Here's how to get your team to adopt better practices: 1. **Lead by example:** Start using one-time links yourself. When you share a password, use Burn the Secret. 2. **Explain the why:** Share this guide with your team. Understanding the risks makes people more likely to change behavior. 3. **Make it easy:** Bookmark Burn the Secret on shared browsers or pin it in your Slack channel. 4. **Gently correct:** When someone shares a password in plain text, kindly suggest using a one-time link next time. Ready to start sharing passwords securely? [Create a secure link](https://burnthesecret.com/) on Burn the Secret. ## Related guides [Password Sharing for Remote Teams →](https://burnthesecret.com/guides/password-sharing-remote-teams)[Email vs Secure Links →](https://burnthesecret.com/guides/email-vs-secure-links) --- # Send credentials to clients Canonical URL: https://burnthesecret.com/guides/sending-credentials-to-clients Markdown URL: https://burnthesecret.com/guides/sending-credentials-to-clients.md [Back to Guides](https://burnthesecret.com/guides) # Best Practices for Sending Credentials to Clients Professional methods for delivering passwords and API keys to clients securely and efficiently. Sending credentials to clients is a routine part of business. Whether you're a web developer delivering login details for a new site, an IT consultant providing access to configured systems, or an agency handing over social media accounts, how you deliver those credentials matters. It reflects your professionalism and impacts your client's security. ## Why credential delivery matters The way you handle credential delivery sends a message about your business. Sending passwords in plain text emails, scattering credentials across multiple messages, and not verifying receipt looks unprofessional. Using encrypted, self-destructing links with organized credential delivery and confirmation of successful access looks professional and builds trust. ## The professional workflow Here's a step-by-step process for delivering credentials to clients that's both secure and professional: 1. **Prepare your delivery email:** Write a clear email listing what credentials you're providing (without the actual passwords). Include context like what each login is for and any important notes. 2. **Create one-time links:** For each credential, create a separate one-time link on Burn the Secret. This keeps things organized and allows you to verify each credential was received. 3. **Send with clear labels:** Include the links in your email with clear labels like "WordPress Admin Login: \[link\]" and "Hosting Panel Access: \[link\]". 4. **Request confirmation:** Ask the client to confirm they were able to access each credential and that everything works. This protects both of you. ## Example: Website project handoff Here's how a professional credential delivery email might look: Subject: \[Project Name\] - Access Credentials Hi \[Client Name\], Your website is live! Below are the secure links to access your credentials. Each link can only be viewed once and will expire in 72 hours, so please save the information somewhere secure after viewing. **Website Admin (WordPress):** URL: yoursite.com/wp-admin Login credentials: \[one-time link\] **Hosting Panel (cPanel):** URL: server.host.com:2083 Login credentials: \[one-time link\] **Domain Registrar:** URL: namecheap.com Login credentials: \[one-time link\] Please confirm once you've successfully accessed each account. Let me know if you have any questions. ## Different types of client credentials **Website and CMS logins.** WordPress, Shopify, Squarespace admin credentials. Include the login URL alongside the credential link, but keep them separate. **API keys and tokens.** Third-party API keys, service tokens, webhook secrets. Include clear documentation on what each key is for and any rate limits or restrictions. **Email and social media.** Business email accounts, social media management access. For social media, consider having the client add you as a manager rather than sharing the master password. ## Best practices checklist - Create separate one-time links for each credential type - Set appropriate expiration times (24-72 hours is typical) - Include context (what the credential is for, the login URL) - Request confirmation that credentials were received and work - Add passphrase protection for highly sensitive credentials - Document what was delivered in your project records - Advise clients to change passwords after the handoff if desired ## Handling client requests for credentials Sometimes clients need to send you credentials. Coach them to use secure methods too. Send them a link to Burn the Secret and explain how to use it. Never ask them to email passwords in plain text. If they send credentials insecurely, change them immediately and educate them for next time. Here's a template you can use: Subject: Secure Way to Share Your Login Credentials Hi \[Client Name\], I need access to \[system/account\] to proceed with \[task\]. Please don't email the password directly, as that's not secure. Instead, please visit burnthesecret.com, paste your password, and send me the secure link it generates. The link will only work once and then delete itself. Ready to deliver credentials professionally? [Create a secure link](https://burnthesecret.com/) on Burn the Secret. ## Related guides [Secure Credential Sharing for MSPs →](https://burnthesecret.com/guides/secure-credential-sharing-msp)[How to Share Passwords Securely →](https://burnthesecret.com/guides/share-passwords-securely) --- # One-time link security Canonical URL: https://burnthesecret.com/guides/one-time-link-security Markdown URL: https://burnthesecret.com/guides/one-time-link-security.md [Back to Guides](https://burnthesecret.com/guides) # One-Time Link Security: How It Works A deep dive into the cryptographic principles that make one-time links secure for sensitive data. When you create a one-time link for sharing sensitive information, there's a lot happening under the hood. This guide explains the cryptographic principles and security architecture that make one-time links a secure method for sharing passwords, API keys, and other sensitive data. ## The security model One-time link security is built on three core principles: 1. **Client-side encryption:** Data is encrypted in the user's browser before being transmitted to the server. 2. **Zero-knowledge storage:** The server only stores encrypted data it cannot decrypt. 3. **Automatic destruction:** Data is permanently deleted after being accessed or when it expires. ## AES-256-GCM encryption Burn the Secret uses AES-256-GCM (Advanced Encryption Standard with 256-bit keys in Galois/Counter Mode) for encrypting secrets. This is the same encryption standard used by governments and financial institutions for classified and sensitive data. **256-bit key strength.** A 256-bit key has 2^256 possible combinations. Even with all the computing power on Earth, brute-forcing this would take longer than the age of the universe. **Authenticated encryption.** GCM mode provides both confidentiality and authenticity. If anyone tampers with the encrypted data, decryption will fail, detecting the modification. **Web Crypto API native.** AES-GCM is natively supported by the Web Crypto API, meaning encryption happens securely in the browser without external libraries. ## The encryption process Here's exactly what happens when you create a one-time link: **Step 1: Key generation.** A random 256-bit encryption key is generated in your browser using the Web Crypto API's cryptographically secure random number generator. **Step 2: Encryption.** Your secret is encrypted using AES-256-GCM with a random initialization vector (IV). The IV ensures that encrypting the same data twice produces different ciphertexts. **Step 3: Server storage.** Only the encrypted ciphertext and IV are sent to the server. The encryption key stays in your browser. **Step 4: Link generation.** The encryption key is placed in the URL fragment (after #). URL fragments are never sent to servers—they only exist in the browser. The final URL looks like: burnthesecret.com/secret/abc123#key=3Kd8f... but the server only sees: burnthesecret.com/secret/abc123 ## Zero-knowledge architecture The URL fragment mechanism is the key to zero-knowledge security. According to the HTTP specification, everything after the # symbol in a URL is handled client-side only. It's not included in HTTP requests to the server, doesn't appear in server logs or analytics, isn't visible to network intermediaries (proxies, CDNs), and exists only in the recipient's browser. This means Burn the Secret (or any attacker who compromises our servers) physically cannot decrypt your secrets. We only have the ciphertext, which is meaningless without the key. ## The decryption process When the recipient opens the link: 1. The browser extracts the encryption key from the URL fragment 2. The browser requests the encrypted ciphertext and IV from the server 3. Decryption happens entirely in the browser using the fragment key 4. The plaintext secret is displayed to the user 5. The server deletes the encrypted data ## Additional security layers **Passphrase protection.** When you add a passphrase, it's SHA-256 hashed client-side before being sent to the server. The server stores only the hash and compares it when the recipient provides their passphrase. The actual passphrase is never transmitted or stored. **View limits.** The server tracks view counts. Once the limit is reached, the encrypted data is immediately and permanently deleted, making the link completely unusable. **Time-based expiration.** A background process continuously checks for expired secrets and deletes them. Expired data cannot be recovered under any circumstances. **HTTPS/TLS.** All communications are over HTTPS with modern TLS, protecting against eavesdropping during transmission of the (already encrypted) ciphertext. ## Security considerations While one-time links provide strong security, there are still factors to consider. One-time links protect against server breaches (data is encrypted), insider threats (zero-knowledge architecture), data persistence (automatic deletion), and network eavesdropping (TLS + encryption). However, be aware of these limitations: - **Link interception:** If someone accesses the link before the intended recipient, they get the secret. Use passphrase protection for high-value credentials. - **Browser history:** The full URL (including fragment) may be saved in browser history. Use private browsing for sensitive links. - **Post-viewing actions:** After decryption, the recipient can copy or screenshot the content. One-time links protect transmission, not usage. Ready to experience zero-knowledge security? [Create a secure link](https://burnthesecret.com/) on Burn the Secret. ## Related guides [One-Time Links Explained →](https://burnthesecret.com/guides/one-time-links-explained)[Self-Destructing Messages →](https://burnthesecret.com/guides/self-destructing-messages) --- # Email versus secure links Canonical URL: https://burnthesecret.com/guides/email-vs-secure-links Markdown URL: https://burnthesecret.com/guides/email-vs-secure-links.md [Back to Guides](https://burnthesecret.com/guides) # Comparing Password Sharing Methods: Email vs Secure Links Why emailing passwords is dangerous and how secure links provide better protection for your credentials. "I'll just email you the password." These seven words have caused countless security breaches. Despite being the most common method of sharing credentials, email is one of the worst choices for password security. Let's break down why, and what you should use instead. ## The problem with emailing passwords Email was designed in the 1970s for exchanging messages between trusted parties on a trusted network. It was never intended to be secure. Here's why emailing passwords is a security nightmare: **Emails live forever.** That password you emailed in 2019? It's still sitting in sent folders, inboxes, archives, and backup tapes. Companies are legally required to retain emails for years. Your password is now part of that permanent record. **Multiple copies, multiple risks.** An email travels through multiple servers and creates copies at each step: your mail server, their mail server, possibly their company's archive system, their devices, and any backups. Each copy is a potential breach point. **Forwarding and CC'ing.** Recipients can forward emails without thinking twice. "Hey, can you help John with this?" And suddenly your password is in John's inbox, his manager's inbox (CC'd "for visibility"), and the team Slack channel where someone pasted it. **Searchable archives.** Administrators can search email archives. "Password", "login", "credentials" are easy keywords. A compromised admin account or a malicious insider can harvest every password ever shared via email. **Account compromise = total exposure.** When someone's email is hacked (and eventually, it will be), the attacker gets access to every password ever sent to or from that account. One breach exposes years of credentials. ## Head-to-head comparison Here's how email stacks up against one-time links across key security factors: - **Data persistence:** Email is archived forever. One-time links are deleted after viewing. - **Encryption:** Email varies (often unencrypted). One-time links use AES-256-GCM (always). - **Access control:** Email is accessible to anyone with email access. One-time links have view limits and expiration. - **Searchability:** Email is fully searchable. One-time links are not searchable. - **Forwarding risk:** Email is easy to forward. One-time link dies after use. - **Server access:** Email admins can read content. One-time links use zero-knowledge architecture. - **Breach impact:** Email exposes all historical passwords. One-time links leave nothing (data deleted). ## How secure links solve these problems **Self-destruction.** Access ends at the selected expiry or view limit. Expired secrets are automatically deleted from the active database. A shared link cannot retrieve them afterward. **End-to-end encryption.** The password is encrypted before leaving your browser. Even if someone intercepts the transmission, they only get encrypted gibberish. **View confirmation.** When the link stops working, you know it's been viewed. If the intended recipient says they didn't get it, you know it was intercepted. **Zero knowledge.** The encryption key never touches the server. Even a server breach reveals only encrypted data that can't be decrypted. ## But I still need to send something via email Here's the good news: you can use email as the delivery mechanism for a secure link. The email itself just contains a link, not the password. If someone searches your email archives, they'll find links that no longer work. The wrong way: "Hi John, here are your credentials: Username: john@company.com, Password: SecureP@ss123!" The right way: "Hi John, here are your credentials: Username: john@company.com, Password: burnthesecret.com/s/abc123" ## What about encrypted email? Some people suggest using encrypted email (PGP/GPG or S/MIME) for sharing passwords. While better than plain email, there are significant drawbacks: - **Complexity:** Both sender and recipient need to set up encryption keys, something most people never do. - **Key management:** Lost keys mean lost access. Compromised keys mean all historical messages are exposed. - **Still persistent:** Even encrypted emails are stored permanently. If the key is ever compromised, all historical passwords are exposed. - **Metadata visible:** Subject lines and sender/recipient information aren't encrypted, revealing that sensitive information was shared. One-time links are simpler, work for anyone without setup, and provide better security through automatic deletion. ## Making the switch Breaking the habit of emailing passwords takes effort, but it's worth it. Here's how to transition: 1. **Start with yourself:** Use one-time links for every password you share, even internally. 2. **Educate gently:** When someone emails you a password, thank them but suggest using Burn the Secret next time. 3. **Create team guidelines:** Establish that passwords should never be shared via email, Slack, or other persistent channels. 4. **Clean up history:** Search your email for "password" and consider changing any credentials that were shared via email. Ready to stop emailing passwords? [Create a secure link](https://burnthesecret.com/) on Burn the Secret. ## Related guides [How to Share Passwords Securely →](https://burnthesecret.com/guides/share-passwords-securely)[One-Time Link Security →](https://burnthesecret.com/guides/one-time-link-security) --- # Enterprise password sharing Canonical URL: https://burnthesecret.com/guides/enterprise-password-sharing Markdown URL: https://burnthesecret.com/guides/enterprise-password-sharing.md [Back to Guides](https://burnthesecret.com/guides) # Enterprise Password Sharing: Compliance and Security Meeting regulatory requirements while maintaining secure credential sharing practices in enterprise environments. Enterprise organizations face unique challenges when it comes to password sharing. Beyond just security, there are compliance requirements, audit trails, and governance considerations. This guide covers how to implement secure credential sharing that satisfies both security teams and compliance auditors. ## The enterprise password challenge Large organizations have more complex credential sharing needs. They deal with scale—hundreds or thousands of employees sharing credentials across teams, departments, and time zones. They face compliance requirements dictating how sensitive data must be handled, stored, and transmitted. They need audit trails documenting who shared what, when, and with whom for security reviews. And they must manage higher stakes with sensitive data, intellectual property, and customer information at risk. ## Compliance framework support One-time links help enterprises meet requirements across multiple compliance frameworks. **SOC 2 Type II.** SOC 2 requires controls around data confidentiality and secure transmission. One-time links support CC6.1 (encryption of confidential data in transit and at rest), CC6.7 (restrictions on transmission of confidential information), and CC7.2 (security event monitoring through access logs). **HIPAA.** Healthcare organizations must protect PHI. One-time links support §164.312(a)(2)(iv) (encryption of ePHI), §164.312(c)(1) (integrity controls for electronic information), §164.312(e)(1) (transmission security), and §164.306(a)(4) (information disposal requirements). **PCI DSS.** Organizations handling payment data must protect cardholder information. One-time links support Requirement 3 (protect stored cardholder data via encryption), Requirement 4 (encrypt transmission of cardholder data), Requirement 7 (restrict access to cardholder data), and Requirement 10 (track access to network resources). **GDPR.** EU data protection requires appropriate security measures. One-time links support Article 5(1)(f) (integrity and confidentiality principle), Article 25 (data protection by design via encryption and auto-deletion), Article 32 (security of processing via encryption and access controls), and Article 17 (right to erasure via automatic data deletion). ## Enterprise security best practices ### Establish a credential sharing policy Document when and how credentials should be shared. Define which credential types require one-time links (all passwords, API keys, etc.). Specify passphrase requirements for high-sensitivity credentials. Establish maximum expiration times based on credential sensitivity. Require verification of receipt for critical credentials. ### Implement approval workflows For highly sensitive credentials, require approval before sharing. Production database credentials might require manager approval. Root/admin access might require security team sign-off. Customer data access might require documented business justification. ### Maintain audit documentation While the credential content is deleted, document the sharing event. Your audit log should include the date and time, who shared the credential and with whom, the credential type (not the credential itself), expiration settings, whether passphrase protection was used, business justification, and who approved the sharing. ### Use API integration for automation Integrate one-time link generation into existing workflows. Provisioning systems can automatically generate secure links for new users. CI/CD pipelines can create links for deployment credentials. Ticketing systems can include secure links when resolving credential requests. ## Handling different credential classes Different credentials warrant different security levels: - **Production Admin:** 1 hour expiration, passphrase required, security + manager approval - **Database Access:** 4 hours expiration, passphrase required, manager approval - **API Keys:** 24 hours expiration, passphrase recommended, team lead approval - **Third-party Services:** 24 hours expiration, passphrase recommended, no approval needed - **Internal Tools:** 72 hours expiration, passphrase optional, no approval needed ## Training and change management Rolling out secure credential sharing requires organizational change: 1. **Executive sponsorship:** Get leadership buy-in for the policy change and communicate it from the top. 2. **Pilot program:** Start with security and IT teams who understand the risks, then expand. 3. **Training sessions:** Conduct brief training on why secure sharing matters and how to use the tools. 4. **Documentation:** Create internal guides with step-by-step instructions for common scenarios. 5. **Enforcement:** Monitor for insecure sharing and follow up with additional training. ## Incident response considerations One-time links simplify incident response. They provide limited blast radius—if a breach is detected, only active (unexpired, unviewed) links are at risk, and historical credentials are already deleted. They create a clear audit trail—you know exactly what credentials were shared and when, making rotation straightforward. They offer burn functionality—active links can be manually burned if a sharing mistake is discovered. Ready to secure your enterprise credential sharing? [Create a secure link](https://burnthesecret.com/) or view our [API documentation](https://burnthesecret.com/api-docs) for integration details. ## Related guides [Secure Credential Sharing for MSPs →](https://burnthesecret.com/guides/secure-credential-sharing-msp)[One-Time Link Security →](https://burnthesecret.com/guides/one-time-link-security) --- # Share a Wi-Fi password securely Canonical URL: https://burnthesecret.com/guides/share-wifi-password-securely Markdown URL: https://burnthesecret.com/guides/share-wifi-password-securely.md [Back to Guides](https://burnthesecret.com/guides) # How to Share a WiFi Password Securely Give guests and staff network access without leaving the password sitting in a chat thread forever. A WiFi password feels harmless to text or drop into a group chat, but it is a key to your network. Once it is pasted into a message, it lives in that history indefinitely, gets forwarded, and can end up on the phone of anyone who briefly borrows a device. For a home guest that might be a minor annoyance. For an office network, a print-out on the wall or a message in a shared channel is a genuine risk, because anyone on the same network is a step closer to your printers, cameras, file shares, and connected devices. ## Why the sticky note and the group chat both fail The most common ways people hand out WiFi credentials all share one flaw: the password persists somewhere you no longer control. A photo of the router label sits in a camera roll. A message in a company Slack channel is searchable by every current and future member. A whiteboard in a meeting room is visible to every visitor. None of these expire, and none of them tell you who actually read them. A one-time link flips that around. The password is encrypted in your browser, delivered through a link that works exactly once, and permanently deleted the moment it is viewed. There is nothing left to forward and nothing left to find later. ## Sharing WiFi access step by step 1. Open [Burn the Secret](https://burnthesecret.com/) and paste your network name and password. 2. Set a short expiry, for example one hour for a single guest arriving now. 3. Optionally add a passphrase and tell the guest verbally. 4. Create the link and send it by text, email, or QR code. 5. Once they connect, the secret is gone, so nothing lingers on their device. Everything is encrypted client-side with AES-256-GCM, so the server never sees your password. It is free, needs no signup to create a link, and works from any browser. ## Extra tips for office networks - Use a dedicated guest network so visitors never touch internal systems. - Rotate the guest password on a schedule and share the new one with a fresh link. - For a recurring reception setup, generate a new one-time link per visitor rather than reusing a static message. - Keep the main network password out of any shared document entirely. Ready to hand out access the safe way? [Create a secure link](https://burnthesecret.com/) on Burn the Secret. ## Related guides [How to Send a Password Securely →](https://burnthesecret.com/guides/how-to-send-a-password-securely)[Sharing Passwords Over Slack →](https://burnthesecret.com/guides/share-password-over-slack) --- # Send an SSH key securely Canonical URL: https://burnthesecret.com/guides/send-ssh-key-securely Markdown URL: https://burnthesecret.com/guides/send-ssh-key-securely.md [Back to Guides](https://burnthesecret.com/guides) # How to Send an SSH Key Securely Delivering a private key or key passphrase to a teammate or contractor without leaving a copy behind. An SSH private key is one of the highest-value secrets you can hold. Whoever has it can authenticate as you to every server that trusts the matching public key. The strong preference is always to have each person generate their own key pair and simply send you their public key, which is not sensitive. But there are real cases where a private key or its passphrase genuinely has to move between people: a shared deploy key, a contractor picking up an existing automation account, or an emergency handover. When that happens, the transfer method matters enormously. ## Prefer public keys, but when you must send a private key Emailing a key file, dropping it in a chat, or pasting it into a shared document are all poor choices. Key material sitting in an inbox or a message archive is a standing liability that can be exfiltrated long after the task is done. If a private key must travel, it should travel encrypted, be viewable once, and then vanish. A one-time link does exactly this. The key is encrypted in your browser with AES-256-GCM before anything is sent, the encryption key lives only in the URL fragment (which browsers never transmit to servers), and the ciphertext is permanently deleted after the recipient opens it once. ## A safe handover workflow 1. Paste the private key file contents (or the passphrase) into [Burn the Secret](https://burnthesecret.com/). File attachments are also supported if you prefer to attach the key file. 2. Add a passphrase to the link itself and set a short expiry. 3. Send the link over one channel and the link passphrase over a separate one, such as a phone call. 4. Ask the recipient to confirm retrieval, then verify the link has already been consumed. 5. Where possible, rotate the key afterward so the transferred copy has a limited useful life. ## Handling the key passphrase separately A passphrase-protected key is safer to move because the file alone is not enough to use it. Send the encrypted key file through one one-time link and the passphrase through a second, independent one. Splitting the two across separate links and channels means a single intercepted message never yields a usable key. Need to hand off a key right now? [Create a secure link](https://burnthesecret.com/) on Burn the Secret. ## Related guides [Sharing Database Credentials Securely →](https://burnthesecret.com/guides/share-database-credentials)[Sending API Keys to Clients →](https://burnthesecret.com/guides/send-api-keys-to-clients) --- # Share database credentials Canonical URL: https://burnthesecret.com/guides/share-database-credentials Markdown URL: https://burnthesecret.com/guides/share-database-credentials.md [Back to Guides](https://burnthesecret.com/guides) # How to Share Database Credentials Securely Handing a connection string or database login to a freelancer without it living in your chat history. A database connection string is deceptively dense. In a single line it often bundles the host, port, database name, username, and password, which means one pasted string is a complete map to your data. When you bring on a freelancer or contractor, they frequently need exactly this to get started, and the temptation is to drop it into an email or a project chat. That single message can then be searched, forwarded, and backed up far beyond the life of the engagement. ## What is actually at risk Unlike a single account password, database credentials often unlock customer records, order history, and anything else that lives in your tables. A leaked connection string can be enough for someone to connect directly and read or modify production data. Because the string is compact and easy to copy, it also spreads easily, which is exactly why it should never sit in a persistent channel. ## Sharing a connection string the safe way A one-time link keeps the credential out of any archive. It is encrypted in your browser before it is sent, stored only as ciphertext the server cannot read, and permanently destroyed once the recipient has viewed it. Here is a practical flow: 1. Paste the full connection string, or the individual host, user, and password, into [Burn the Secret](https://burnthesecret.com/). 2. Add a passphrase for anything touching production and share it over a different channel. 3. Set an expiry that matches when the contractor will actually pick it up. 4. Send the link, confirm they retrieved it, and check the link has been consumed. ## Reduce blast radius before you share - Create a dedicated, scoped database user for the contractor rather than sharing an admin login. - Grant only the permissions the task needs, and prefer read-only where possible. - Point them at a staging or replica database instead of production when the work allows it. - Rotate or revoke the credential the moment the engagement ends. Combining a narrowly scoped credential with a self-destructing link means that even in a worst case, the exposure is small and short-lived. The service is free, requires no signup to create a link, and encrypts everything client-side. Onboarding a contractor today? [Create a secure link](https://burnthesecret.com/) on Burn the Secret. ## Related guides [How to Send an SSH Key Securely →](https://burnthesecret.com/guides/send-ssh-key-securely)[Sending API Keys to Clients →](https://burnthesecret.com/guides/send-api-keys-to-clients) --- # Send API keys to clients Canonical URL: https://burnthesecret.com/guides/send-api-keys-to-clients Markdown URL: https://burnthesecret.com/guides/send-api-keys-to-clients.md [Back to Guides](https://burnthesecret.com/guides) # How to Send API Keys to Clients Safely Delivering keys and tokens to a client in a way that looks professional and leaves nothing behind. When you finish an integration or provision a new account, the last step is often handing the client an API key or access token. It is easy to treat this as an afterthought and paste the key into the delivery email. But an API key is a live credential. Anyone who reads that email, now or in the future, can call the API as your client, run up usage, and reach whatever data the key is scoped to. A polished delivery should protect that credential as carefully as the work that produced it. ## Why keys do not belong in the delivery email Email is a permanent, forwardable record. A key sent in the body sits in your sent folder, the client's inbox, and every backup of both, often for years. If either mailbox is compromised later, the key is right there waiting. Ticketing systems and shared docs have the same problem: the credential outlives its usefulness and keeps accumulating copies. A one-time link separates the delivery from the record. You can still send a friendly, well-labeled email, but the key itself lives inside an encrypted link that works once and then deletes itself. The email that remains contains only a dead link. ## A clean client delivery flow 1. Generate the key in your own dashboard, scoped to only what the client needs. 2. Paste it into [Burn the Secret](https://burnthesecret.com/) and set an expiry that gives the client a comfortable window to retrieve it. 3. Add a passphrase for production keys and share it over a separate channel. 4. Include the one-time link in your delivery email with a clear label such as "Your production API key (one-time link)." 5. Confirm the client retrieved it, and note in your records that it was delivered securely. ## Automate it at scale If you onboard clients regularly, you can generate one-time links programmatically with the [Burn the Secret API](https://burnthesecret.com/api-docs) and drop the resulting link straight into your provisioning emails or portal. Every key gets the same encrypted, self-destructing treatment without a manual step. The tool is free, needs no signup to create a link, and encrypts everything in the browser so the server never sees the key. Delivering keys to a client soon? [Create a secure link](https://burnthesecret.com/) on Burn the Secret. ## Related guides [Best Practices for Sending Credentials to Clients →](https://burnthesecret.com/guides/sending-credentials-to-clients)[Sharing Database Credentials Securely →](https://burnthesecret.com/guides/share-database-credentials) --- # One-Time Secret alternative Canonical URL: https://burnthesecret.com/guides/onetimesecret-alternative Markdown URL: https://burnthesecret.com/guides/onetimesecret-alternative.md [Back to Guides](https://burnthesecret.com/guides) # A One-Time Secret Alternative If you are comparing tools for sharing a secret that self-destructs, here is what Burn the Secret offers. One-Time Secret helped popularize a simple, powerful idea: paste a secret, get a link that works once, and let it disappear after it is read. It is a well-known open-source tool, and if it fits your needs it is a reasonable choice. This page is not a takedown of it. Instead, it explains what Burn the Secret provides so you can decide which tool matches how you actually work. ## The shared idea: links that self-destruct Both tools are built around the same core mechanic. You enter a secret, the tool produces a link, and the secret is destroyed once it has been viewed. This is a far safer pattern than email or chat, because there is nothing left in a message archive to leak later. ## What Burn the Secret offers Here is exactly what you get, described in plain terms so you can compare it against whatever else you are evaluating: - **Client-side, zero-knowledge encryption.** Secrets are encrypted in your browser with AES-256-GCM. The key rides in the URL fragment, which browsers never send to servers, so the server only ever stores unreadable ciphertext. - **One-time, self-destructing links.** The secret is permanently deleted after it is viewed. - **Optional passphrase.** Add a passphrase the recipient must enter, and share it over a separate channel. - **Configurable expiration.** Set how long a link stays valid before it expires on its own. - **File attachments.** Share files, not just text. - **A REST API.** Generate links programmatically for onboarding, provisioning, and automation. - **Free and no signup.** You do not need an account to create a link. ## How to choose The honest answer is that it depends on your priorities. If you need to self-host on your own infrastructure, an open-source project you deploy yourself may be the better fit, and you should evaluate the options on their own merits. If you want a hosted tool that is free, requires no signup, encrypts in the browser, and supports passphrases, file attachments, and an API out of the box, Burn the Secret is designed for exactly that. The best way to decide is to try sharing a real secret and see how the flow feels. Want to see it in action? [Create a secure link](https://burnthesecret.com/) on Burn the Secret. ## Related guides [One-Time Links Explained →](https://burnthesecret.com/guides/one-time-links-explained)[A PrivateBin Alternative →](https://burnthesecret.com/guides/privatebin-alternative) --- # PrivateBin alternative Canonical URL: https://burnthesecret.com/guides/privatebin-alternative Markdown URL: https://burnthesecret.com/guides/privatebin-alternative.md [Back to Guides](https://burnthesecret.com/guides) # A PrivateBin Alternative Weighing up encrypted paste tools? Here is how Burn the Secret approaches the same problem. PrivateBin is a respected open-source project, an encrypted pastebin where the server stores data it cannot read. It is a solid tool with an active community, and for teams that want to run their own paste service it is a natural pick. This page does not argue against it. It lays out what Burn the Secret offers so you can match the right tool to your situation, especially if what you really need is to share a secret once rather than host a paste service. ## A pastebin versus a one-time secret tool An encrypted pastebin is built around sharing snippets, sometimes with a burn-after-reading option. Burn the Secret is built specifically around the one-time secret: paste a credential, get a link that works once, and let it self-destruct after viewing. Both encrypt on the client, but the design centers on different jobs. If your main need is delivering a password, key, or token safely and then having it disappear, a purpose-built one-time tool tends to be the simpler fit. ## What Burn the Secret provides - **Client-side, zero-knowledge encryption.** AES-256-GCM runs in your browser, and the decryption key stays in the URL fragment that servers never receive. - **One-time, self-destructing links.** The secret is deleted for good after it is read. - **Optional passphrase and configurable expiry.** Layer on a passphrase and choose how long a link can live. - **File attachments.** Send files alongside or instead of text. - **A REST API.** Automate link creation from your own systems. - **Hosted, free, and no signup.** Nothing to deploy and no account required to create a link. ## Which one fits you If you specifically want to self-host an encrypted pastebin on your own servers, evaluate the open-source options directly. If you want a hosted, zero-knowledge tool focused on sharing a secret once, with passphrases, expiries, attachments, and an API available immediately and at no cost, Burn the Secret is built for that path. Trying a real share is the quickest way to know which experience you prefer. Curious how it feels? [Create a secure link](https://burnthesecret.com/) on Burn the Secret. ## Related guides [A One-Time Secret Alternative →](https://burnthesecret.com/guides/onetimesecret-alternative)[One-Time Link Security: How It Works →](https://burnthesecret.com/guides/one-time-link-security) --- # Share a password over Slack Canonical URL: https://burnthesecret.com/guides/share-password-over-slack Markdown URL: https://burnthesecret.com/guides/share-password-over-slack.md [Back to Guides](https://burnthesecret.com/guides) # How to Share a Password Over Slack Safely Slack feels private, but a pasted password becomes a permanent, searchable record. Here is a safer way. Slack is where a lot of quick credential handoffs happen. A teammate needs a login, you paste it into a DM or a channel, and everyone moves on. The problem is that Slack is designed to remember everything. A message you send in a rush becomes part of a company archive that is searchable, exportable, and retained according to your workspace policy, often long after the password should have been forgotten. ## Why pasting a password into Slack is risky Even a direct message is not as private as it feels. Consider what a plain-text password in Slack is exposed to: - Workspace admins can access message history and run exports. - Search means the credential can resurface months later with a simple query. - Anyone added to a channel later may be able to scroll back to it. - Connected apps and integrations may have broad access to messages. - A compromised account exposes every credential ever sent through it. Deleting the message afterward helps, but it is easy to forget, and it does not undo exports or backups that already captured it. ## Use a one-time link instead The fix is to keep the password out of Slack entirely while still using Slack to deliver it. Create a one-time link, then paste the link, not the password, into the conversation. The credential is encrypted in your browser, the link works exactly once, and the secret self-destructs after your teammate opens it. What remains in the channel is a link that no longer does anything. 1. Paste the password into [Burn the Secret](https://burnthesecret.com/) and set a short expiry. 2. Optionally add a passphrase and send it by another route. 3. Drop the generated one-time link into your Slack message. 4. Confirm your teammate opened it, and the secret is already gone. This same approach works in Microsoft Teams, Discord, or any chat tool. The tool is free, requires no signup to create a link, and encrypts client-side so the server never sees the password. Need to hand off a login in Slack right now? [Create a secure link](https://burnthesecret.com/) on Burn the Secret. ## Related guides [How to Share a Password Over Email Safely →](https://burnthesecret.com/guides/share-password-over-email-safely)[How to Send a Password Securely →](https://burnthesecret.com/guides/how-to-send-a-password-securely) --- # Share a password over email safely Canonical URL: https://burnthesecret.com/guides/share-password-over-email-safely Markdown URL: https://burnthesecret.com/guides/share-password-over-email-safely.md [Back to Guides](https://burnthesecret.com/guides) # How to Share a Password Over Email Safely Email is the default way people send passwords, and one of the least safe. Here is what to do instead. Sending a password by email feels normal because everyone does it. But email was never built to protect secrets. A message you send is copied to your sent folder, the recipient's inbox, and the backups of both mail systems. Unlike a spoken word, that copy does not fade. It can be searched, forwarded, and recovered years later, which makes email one of the riskiest possible homes for a live credential. ## Why emailing a password is a lasting liability The core issue is permanence combined with reach. A password in an email is exposed to more than just the two people in the thread: - It persists indefinitely across inboxes, sent folders, and server backups. - A single forward can expose it to people you never intended to include. - Standard email is often not encrypted end-to-end in transit. - If either mailbox is breached in the future, the credential is sitting there in plain text. Because the credential outlives the moment it was needed, the window for something to go wrong keeps growing the longer the email exists. ## The one-time-link approach You can keep using email as the delivery channel while removing the password from the email itself. Create a one-time link and send that instead. The password is encrypted in your browser, the link opens exactly once, and the secret is permanently destroyed after the recipient views it. The email that stays in the archive holds nothing but an expired link. 1. Paste the password into [Burn the Secret](https://burnthesecret.com/) and choose an expiry. 2. Add a passphrase for sensitive accounts and share it by phone or text. 3. Email the one-time link with a clear label instead of the password. 4. Ask the recipient to confirm, and verify the link has already been used. Sending the passphrase through a different channel than the link means an intercepted email alone is never enough. The tool is free, needs no signup to create a link, and never sees your password because everything is encrypted client-side. About to email a credential? [Create a secure link](https://burnthesecret.com/) on Burn the Secret instead. ## Related guides [Comparing Password Sharing Methods: Email vs Secure Links →](https://burnthesecret.com/guides/email-vs-secure-links)[Sharing Passwords Over Slack →](https://burnthesecret.com/guides/share-password-over-slack) --- # Send secrets to a new employee Canonical URL: https://burnthesecret.com/guides/send-secrets-to-new-employee Markdown URL: https://burnthesecret.com/guides/send-secrets-to-new-employee.md [Back to Guides](https://burnthesecret.com/guides) # How to Send Secrets to a New Employee Securely Onboarding is a credential-heavy moment. Here is how to deliver those first secrets without leaving a trail. The first day of a new hire is one of the most credential-intensive moments in any company. A single person suddenly needs a temporary account password, VPN details, a Wi-Fi login, access to shared tools, and sometimes a password manager invite. It is tempting to batch all of that into a friendly welcome email. But that email becomes a compact, permanent list of secrets, sitting in two inboxes and every backup, exposed to anyone who later gains access to either account. ## The onboarding credential problem New employees are also, by definition, the people you know the least about from a security standpoint. Their accounts are brand new, they may be setting up devices for the first time, and they are learning your systems. Handing them a durable document full of passwords maximizes the chance that one of those secrets is screenshotted, forwarded, or left in a downloads folder. The goal during onboarding is to deliver each secret cleanly and then have it disappear. ## A secure onboarding handoff One-time links fit onboarding well because they let you deliver credentials through the same welcome email or chat while keeping the secrets themselves out of that permanent record. Each secret is encrypted in the browser, viewable once, and then destroyed. 1. Create a separate one-time link for each credential at [Burn the Secret](https://burnthesecret.com/), rather than bundling them. 2. Set expiries that line up with the new hire's start date and first week. 3. For higher-value access, add a passphrase and share it during a call or in person. 4. Prefer temporary credentials the employee must reset on first login. 5. Confirm each link was retrieved so you know onboarding is on track. ## Make it repeatable If you onboard often, build one-time links into your standard checklist so every new hire is handled the same secure way. Teams with automated provisioning can generate links programmatically with the [Burn the Secret API](https://burnthesecret.com/api-docs) and insert them into onboarding templates. The tool is free, requires no signup to create a link, and encrypts everything client-side with AES-256-GCM, so the server never sees the credentials you hand out. Welcoming someone new this week? [Create a secure link](https://burnthesecret.com/) on Burn the Secret. ## Related guides [Best Practices for Sending Credentials to Clients →](https://burnthesecret.com/guides/sending-credentials-to-clients)[Sharing Passwords Over Slack →](https://burnthesecret.com/guides/share-password-over-slack) --- # Share recovery and 2FA backup codes Canonical URL: https://burnthesecret.com/guides/share-recovery-codes-2fa-backup Markdown URL: https://burnthesecret.com/guides/share-recovery-codes-2fa-backup.md [Back to Guides](https://burnthesecret.com/guides) # How to Share 2FA Recovery Codes Securely Backup and recovery codes are as powerful as the account itself. Treat sharing them with the same care. When you enable two-factor authentication, most services give you a set of backup or recovery codes. Their entire purpose is to let you back into an account when you lose your phone or authenticator, which means each code effectively bypasses your second factor. That power cuts both ways: anyone who obtains the codes can use them to defeat the very protection 2FA is supposed to provide. So the moment you need to share a recovery code with someone, for example handing off a shared team account, the delivery method matters enormously. ## Why recovery codes deserve extra caution A recovery code is a bypass key. Unlike a rotating authenticator code, backup codes are often valid until used, so a code captured from an old email or chat message can still work weeks or months later. Pasting them into a message thread, saving them in a shared note, or emailing a screenshot all create a lasting record of a factor that is meant to be tightly held. The safest handling keeps the codes out of any persistent channel. ## Sharing codes without leaving a copy A one-time link is a good match for recovery codes because it is designed to be read once and then destroyed. The codes are encrypted in your browser, the link self-destructs after viewing, and nothing remains in an inbox or archive to be reused. 1. Paste only the specific codes you need to share into [Burn the Secret](https://burnthesecret.com/), not your full set. 2. Add a passphrase and share it through a separate channel from the link. 3. Set a short expiry so an unopened link does not linger. 4. Confirm the recipient retrieved the codes, then regenerate a fresh set from the account so any shared codes are retired. That last step is the important one for recovery codes specifically: because they stay valid until used, regenerating a new batch after a handoff invalidates the ones you shared and closes the window entirely. ## A note on shared accounts Where a service supports it, individual logins with their own 2FA are safer than passing recovery codes around a team. When a genuinely shared account is unavoidable, combine a one-time link with a passphrase and a prompt regeneration of codes afterward. The tool is free, needs no signup to create a link, and encrypts everything client-side so the server never sees your codes. Need to hand off backup codes? [Create a secure link](https://burnthesecret.com/) on Burn the Secret. ## Related guides [How to Send a Password Securely →](https://burnthesecret.com/guides/how-to-send-a-password-securely)[How to Share Passwords Securely →](https://burnthesecret.com/guides/share-passwords-securely) --- # Privacy-conscious password sharing and GDPR Canonical URL: https://burnthesecret.com/guides/gdpr-compliant-password-sharing Markdown URL: https://burnthesecret.com/guides/gdpr-compliant-password-sharing.md [Back to Guides](https://burnthesecret.com/guides) # Privacy-Conscious Password Sharing and GDPR How self-destructing, encrypted links support data-minimization goals when you share credentials. A quick, important caveat first: this is general information, not legal advice, and Burn the Secret does not claim to be "GDPR certified." Compliance depends on your organization, your data, and your processes, and you should consult your own legal or privacy team. What this guide does explain is how the mechanics of one-time, self-destructing, encrypted links line up with privacy principles that many teams care about, particularly data minimization and limited retention. ## Why credential sharing is a privacy concern Credentials frequently unlock systems that hold personal data. A shared login to a CRM, a database connection string, or an admin password can all be a path to information about real people. When those credentials are pasted into email or chat, they create long-lived copies in systems you may not fully control. From a privacy standpoint, every additional place a secret is stored is another place that could be involved in a breach, and another thing to account for when reasoning about retention. ## How one-time links reduce data at rest The privacy value of a one-time link comes from what it does not leave behind. Instead of a credential sitting indefinitely in a mailbox, the secret exists only briefly and then is gone. Several properties support this: - **Data minimization by design.** The secret is delivered once and permanently deleted after viewing, so there is no standing copy in a chat archive or inbox. - **Client-side, zero-knowledge encryption.** Content is encrypted in your browser with AES-256-GCM, and the key stays in the URL fragment that servers never receive, so the service stores only unreadable ciphertext. - **Configurable expiration.** Even an unopened link can be set to expire, limiting how long anything is retained. - **Optional passphrase.** An extra layer for particularly sensitive credentials. None of this makes an organization compliant on its own, but it does shrink the footprint of a credential compared with methods that keep permanent copies. ## Practical steps for privacy-conscious teams 1. Use one-time links for credential handoffs so secrets are not retained in messaging tools. 2. Keep expiries short and share only the specific secret that is needed. 3. Add a passphrase for anything that touches systems holding personal data. 4. Document your process, and check the specifics with your own privacy or legal advisors. Burn the Secret is free and requires no signup to create a link, which also means you can adopt this pattern without provisioning yet another account that stores personal data. Want to minimize what you leave behind? [Create a secure link](https://burnthesecret.com/) on Burn the Secret. ## Related guides [Enterprise Password Sharing: Compliance and Security →](https://burnthesecret.com/guides/enterprise-password-sharing)[How to Send a Password Securely →](https://burnthesecret.com/guides/how-to-send-a-password-securely) --- # How to send a password securely Canonical URL: https://burnthesecret.com/guides/how-to-send-a-password-securely Markdown URL: https://burnthesecret.com/guides/how-to-send-a-password-securely.md [Back to Guides](https://burnthesecret.com/guides) # How to Send a Password Securely The short version: never send a password in plain text. Send a link that self-destructs instead. At some point everyone has to send someone a password. The instinct is to type it straight into an email, a text, or a chat message. That feels quick, but it leaves the password sitting in a place that remembers everything: inboxes, sent folders, message archives, and backups. The safest way to send a password is to make sure it exists only long enough to be read, and then disappears. This guide covers the simple method for doing exactly that. ## The one rule: never send a password in plain text Plain-text passwords in messages are the root of most avoidable exposure. Email is permanent and forwardable. Text messages persist on devices and carrier systems. Chat tools keep searchable histories. In every case, the password outlives the moment it was needed and waits around to be found later. Deleting the message helps a little, but backups and exports may already have captured it. The reliable fix is to never put the raw password into the channel at all. ## The secure method: a one-time link A one-time link lets you use any channel to deliver a password while keeping the password itself out of that channel's permanent record. Here is how it works under the hood: - The password is encrypted in your browser with AES-256-GCM before anything is sent. - The decryption key lives in the URL fragment, the part after the # symbol, which browsers never transmit to servers. - The server stores only unreadable ciphertext, so even it cannot see the password. - After the recipient views it once, the secret is permanently deleted. You share a link, not a password, and once it is opened there is nothing left to leak. ## Step by step 1. Go to [Burn the Secret](https://burnthesecret.com/) and paste the password. 2. Optionally add a passphrase the recipient must enter to unlock it. 3. Choose an expiry so an unopened link does not linger. 4. Create the link and send it through email, chat, or text. 5. Send the passphrase, if you used one, through a different channel. ## A few habits that help - Split the link and passphrase across two different channels for sensitive accounts. - Use the shortest expiry that is practical. - Ask the recipient to confirm they retrieved it so you know it was not intercepted. - Consider rotating the password afterward when the access only needed to be temporary. Burn the Secret is free, requires no signup to create a link, and supports passphrases, expiries, file attachments, and an API for automating the whole thing. Ready to do it the safe way? [Create a secure link](https://burnthesecret.com/) on Burn the Secret. ## Related guides [How to Share Passwords Securely →](https://burnthesecret.com/guides/share-passwords-securely)[One-Time Links Explained →](https://burnthesecret.com/guides/one-time-links-explained)