🔥 Burn-After-Read Technology

Automatically destroy secrets after they've been accessed, ensuring sensitive data can only be viewed once and is permanently deleted from all systems.

What is Burn-After-Read?

Burn-after-read is a security feature that automatically and permanently deletes secrets once they've been accessed the specified number of times. This ensures that sensitive data has a limited lifespan and cannot be accessed indefinitely.

Key Features

• Automatic deletion after viewing
• Configurable view limits (1-10 views)
• Time-based expiration backup
• Atomic database operations
• Anti-link-preview protection
• True data destruction

Why Use Burn-After-Read?

🔥

Minimize Exposure Window

Secrets exist only as long as needed

🗑️

Prevent Data Hoarding

Forces proper secret lifecycle management

🛡️

Reduce Attack Surface

Less data available for potential breaches

⚡

Compliance Support

Meets data minimization requirements

How Burn-After-Read Works

The Burning Process

Secret Created

Secret stored with view counter (default: 1 view)

Access Request

User clicks "Reveal Secret" button

Atomic Update

Database decrements counter and returns data

Auto-Deletion

When counter reaches 0, secret is permanently deleted

Database Transaction Details

SafeMonk uses PostgreSQL's atomic transactions to ensure burn-after-read operations are safe even under high concurrency and system failures.

-- Atomic burn-after-read operation

BEGIN TRANSACTION;

UPDATE secrets
SET views_remaining = views_remaining - 1,
last_accessed = NOW()
WHERE id = $1 AND views_remaining > 0
RETURNING encrypted_data, views_remaining;

COMMIT;

-- Auto-cleanup when views_remaining = 0

Anti-Link-Preview Protection

The Problem

Many messaging apps and social platforms automatically fetch link previews, which could accidentally "burn" a secret before the intended recipient sees it.

⚠️ Vulnerable Platforms

• WhatsApp link previews
• Slack unfurling
• Discord embeds
• Twitter/X cards
• Facebook previews
• Email client previews
• Security scanners

SafeMonk's Solution

We use a "safe reveal" mechanism that requires explicit human interaction to trigger the burn-after-read process.

✅ Safe Landing Page

Initial page load shows only metadata, not the secret

✅ User Action Required

Must click "Reveal Secret" button to trigger fetch

✅ Bot Protection

Automated systems cannot trigger the reveal mechanism

Deletion Triggers

View-Based Deletion

The primary deletion mechanism. Secrets are destroyed once they've been viewed the specified number of times (1-10 views, default is 1).

1️⃣

One-Time Secret

Maximum security

3️⃣

Team Sharing

Small group access

🔟

Multiple Views

Extended access

Time-Based Deletion

Backup deletion mechanism. Secrets are automatically deleted after their expiration time, regardless of view count. Acts as a safety net.

Example: Secret set to 3 views and 1 day expiration. If only viewed once, it still deletes after 24 hours.

Manual Deletion

Secret creators can access a deletion link to manually destroy secrets before they've been viewed or expired.

Use case: Accidentally shared the wrong secret or need to revoke access immediately.

Technical Implementation

Race Condition Prevention

High-traffic scenarios could cause race conditions where multiple users simultaneously access a secret. SafeMonk prevents this with database locks.

❌

Without Atomicity

Two users could both decrement counter from 1→0

✓

With Atomicity

Only one user gets the secret, others get "not found"

Database Schema

Each secret includes metadata that controls the burn-after-read behavior.

-- Secrets table structure

id: UUID
encrypted_data: BYTEA
views_remaining: INTEGER
expires_at: TIMESTAMP
created_at: TIMESTAMP
last_accessed: TIMESTAMP
deletion_token: UUID

views_remaining: Decremented on each access
expires_at: Automatic cleanup timestamp

File Burn-After-Read

Multi-Layer Cleanup

File secrets require cleanup of both database records and storage objects. SafeMonk ensures complete deletion across all systems.

Database Deletion

Remove secret metadata and encrypted chunks

Storage Cleanup

Delete encrypted file chunks from object storage

Verification

Confirm all references and chunks are removed

Chunked File Handling

Large files (>100MB) are split into encrypted chunks. All chunks must be deleted when the secret burns.

Cleanup Process

1. Mark secret as burned in database
2. Queue chunk deletion job
3. Delete each encrypted chunk
4. Remove database references
5. Log successful cleanup

Redundancy: Multiple cleanup processes ensure no orphaned chunks remain even if primary deletion fails.

Security Benefits

⏱️

Limited Lifespan

Secrets exist only as long as needed, reducing the window for potential attacks or exposure.

🗑️

Data Minimization

Automatic deletion ensures only necessary data is retained, supporting privacy regulations and best practices.

🔒

Breach Mitigation

Less data stored means smaller impact from potential security breaches or system compromises.

Burn-After-Read Best Practices

When to Use 1 View

✅
Highly Sensitive Secrets
Passwords, API keys, personal information
✅
One-Time Passwords
2FA codes, temporary access tokens
✅
Legal Documents
Contracts, agreements, sensitive PDFs

When to Use Multiple Views

💼
Team Secrets
Shared passwords, team API keys (2-5 views)
📋
Reference Information
Configuration, non-critical data (5-10 views)
🔄
Backup Access
Allow for mistakes or multiple downloads (3-5 views)

⚠️ Important Reminder

Once a secret is burned (deleted), it cannot be recovered by anyone - not even SafeMonk. Make sure the recipient has successfully accessed the secret before the burn limit is reached.

Related Technologies

Burn-after-read works alongside other security technologies to provide comprehensive protection.

🔐

AES-GCM Encryption

🔑

PBKDF2 Key Derivation