DatenschutzTechnologie

Sind Einmal-Links wirklich sicher? Kryptografie-Check 2026 von 4 Verfahren

Veröffentlicht am5.3.20268 min read

Viele verwechseln "selbstzerstörend" mit "sicher"

Burn-after-read-Links sind in den letzten Jahren beliebt geworden. Vom Versenden eines Passworts bis zum Teilen privater Fotos — Einweg-URLs gelten vielen als Synonym für Sicherheit. Was die wenigsten wissen: Die technische Umsetzung unterscheidet sich fundamental. Manche Varianten können Daten kryptografisch nicht wirklich vernichten.

Dieser Artikel zerlegt die drei wichtigsten Implementierungsmuster. Aus Sicht der angewandten Kryptografie und der Systemarchitektur — kein Hype, nur Messgrößen.

Drei Implementierungsmuster

Muster 1: Server-seitige Löschung (Token-Based)

Der einfachste und häufigste Ansatz:

Nutzer lädt Inhalt hoch, Server speichert Klartext und erzeugt ein Token (UUID oder Random-String)
Server gibt einen Link zurück (z. B. https://example.com/view/abc123)
Erster Zugriff liest den Inhalt, Token wird als verbraucht markiert
Spätere Zugriffe erhalten "Link abgelaufen"

Sicherheitsanalyse:

Das fundamentale Problem: Der Server hält Klartext. Vor der "Vernichtung" haben folgende Akteure Zugriff auf den Originalinhalt:

Serveradministratoren
Datenbankadministratoren
Jeder Angreifer mit Serverzugriff
Backup-Systeme (bei regelmäßigen Backups überlebt "gelöscht" oft im Backup)
Gerichtsbeschlüsse oder behördliche Anordnungen

Wichtig zu wissen: Selbst nach "Löschung" ist in modernen Storage-Systemen das Datum nur zum Überschreiben freigegeben. Bis zum physischen Überschreiben bleibt es mit forensischen Methoden rekonstruierbar. SSDs mit TRIM und magnetische Restdaten auf HDDs sind bekannte Wege der Datenrettung.

Muster 2: Client-seitige Verschlüsselung (Zero-Knowledge)

Die sicherste Variante, umgesetzt von PrivNote und dem eingestellten Firefox Send:

Nutzer gibt Inhalt im Browser ein
Browser erzeugt einen zufälligen AES-256-Schlüssel
Verschlüsselung im Browser
Ciphertext wird zum Server hochgeladen
Server speichert nur den Ciphertext, nicht den Schlüssel
Schlüssel landet im URL-Fragment (hinter dem #)

Beispiel: https://example.com/view/abc123#encryption-key-here

Kryptografisches Schlüssel-Design: URL-Fragmente (alles hinter dem #) werden nicht an den Server übertragen. Der Server sieht nur den Ciphertext, kennt den Schlüssel niemals. Das ist die sogenannte Zero-Knowledge-Architektur.

Der Empfänger:

Browser lädt Ciphertext vom Server
Liest Schlüssel aus dem URL-Fragment
Entschlüsselt im Browser
Server löscht den Ciphertext

Sicherheitsanalyse:

Bei diesem Muster bekommt ein Angreifer bei Serverkompromittierung nur unlesbaren Ciphertext. Trotzdem bleiben Angriffsflächen:

Malicious Browser Extensions: Bösartige Erweiterungen können die volle URL (inklusive Fragment) lesen
Browserverlauf: Die vollständige URL (mit Schlüssel) kann im History landen
Referer-Header-Leaks: Wenn die Seite externe Ressourcen lädt, konnten ältere Browser das URL-Fragment via Referer leaken (aktuelle Browser haben das weitgehend gefixt)
JavaScript-Supply-Chain-Angriffe: Wird der JS-Code für die Verschlüsselung manipuliert, kann der Schlüssel an den Angreifer exfiltriert werden

Muster 3: Hybrid

Kombiniert server-seitige Kontrolle mit clientseitiger Verschlüsselung:

Clientseitige Verschlüsselung (wie Muster 2)
Serverseitige Zugriffslimits (Einmal-Token + optionales Passwort + Ablaufzeit)
Mehrstufige Authentifizierung (z. B. Passwort nötig, um Ciphertext zu erhalten)
Löschung des Ciphertexts nach Zugriff, Audit-Log ohne Inhaltsbezug

Das ist der beste Kompromiss zwischen Sicherheit und Nutzbarkeit.

Threat-Model: Was Burn-after-read nicht schützt

Egal welche Implementierung, folgende Bedrohungen sind technisch nicht abwehrbar:

Screenshots und Bildschirmaufnahmen

Fundamentale Limitierung: Sobald Inhalt auf einem Bildschirm gerendert wird, lässt sich kein Abfotografieren oder Aufzeichnen verhindern. Manche Dienste versuchen per JavaScript, Rechtsklick oder Screenshot-Hotkeys zu sperren — das umgehen technisch versierte Nutzer trivial. Der Schutz wirkt nur gegen Gelegenheitsnutzer.

CDN- und Proxy-Cache

Werden Einweg-Inhalte über CDN ausgeliefert, speichern CDN-Nodes möglicherweise Kopien. Selbst wenn der Origin-Server gelöscht hat, bleibt der Cache bis zum TTL-Ablauf. Ein oft übersehenes Risiko.

Korrekte Konfiguration: Cache-Control: no-store, no-cache, must-revalidate und CDN-Cache-Control: no-store. Cloudflare, Akamai und Fastly beachten diese Header, aber nur, wenn sie gesetzt sind.

Browser-Cache

Browser cachen entschlüsselte Inhalte manchmal lokal. Bilder sind besonders anfällig — der Image-Cache greift oft unabhängig von Page-Cache-Headern.

Netzwerküberwachung (Man-in-the-Middle)

Bei reinem Token-Muster (Muster 1) ohne HTTPS kann jeder Netzwerkzwischenpunkt (ISP, Firmen-Firewall, bösartiger WLAN-Hotspot) Klartext mitlesen.

In deutschen Unternehmensumgebungen ist SSL-Inspection (TLS-Entschlüsselung durch die Firewall) weit verbreitet — auch HTTPS schützt dort nicht vor der IT-Abteilung. Muster 2 (clientseitige Verschlüsselung) schützt: Selbst wenn TLS aufgebrochen wird, sieht die Firewall nur Ciphertext.

Serverlogs

Selbst wenn der Inhalt gelöscht ist, können Access-Logs URL, IP, Zeitstempel und User-Agent enthalten. Bei Muster 1 lässt sich daraus rekonstruieren: "Wer hat wann von welcher IP auf welchen Link zugegriffen." Das ist nach DSGVO übrigens auch dokumentationspflichtig — viele Anbieter haben unzureichende Löschkonzepte für solche Logs.

Vergleich bekannter Dienste (Stand März 2026)

Dienst	Verschlüsselung	Open Source	Schlüsselort	Server liest Klartext?	Passwort	Max. Inhalt
PrivNote	Client AES	Nein	URL-Fragment	Nein (Zero-Knowledge)	Nein	Nur Text
1ty.me	Server	Nein	Server	Ja	Optional	Nur Text
Snappass (Pinterest)	Server AES	Ja	URL-Pfad	Ja (Schlüssel durchläuft Server)	Optional	Nur Text
hat.sh	Client XChaCha20	Ja	URL-Fragment	Nein (Zero-Knowledge)	Nein	Dateien
OnionShare	Client + Tor	Ja	Lokal	Nein	Optional	Dateien
Yopass	Client OpenPGP	Ja	URL-Fragment	Nein (Zero-Knowledge)	Nein	Text + Dateien
Cryptpad (DE-gehostet)	Client	Ja	URL-Fragment	Nein (Zero-Knowledge)	Optional	Dokumente, Dateien
Passbolt (self-hosted)	Client OpenPGP	Ja	Schlüssel lokal	Nein	Ja	Passwörter, Dateien

Ein wichtiger Indikator: Open Source ist essenziell für Vertrauensbildung. Geschlossene Dienste können clientseitige Verschlüsselung behaupten, aber niemand kann es verifizieren. Open-Source-Dienste erlauben Sicherheits-Audits.

Für den DACH-Raum: CryptPad wird teilweise aus Frankreich gehostet und bietet europäische Instanzen. Für deutsche Unternehmen mit strengen Compliance-Anforderungen ist das oft einfacher zu rechtfertigen als US-Dienste.

Praktische Anwendung

Geeignete Szenarien

Einmal-Passwörter oder Zugangsdaten
Sensible, aber zeitlich begrenzte Informationen
Inhalte, die nicht dauerhaft im Chat-Verlauf bleiben sollen

Ungeeignete Szenarien

Hochvertrauliche Geschäftsinformationen (Ende-zu-Ende-verschlüsselte Kommunikation verwenden)
Rechtlich relevante Nachweise (nach Vernichtung fehlt die Beweisfähigkeit)
Sicherheitskritische staatliche Informationen (Offline-Transfer ist angebracht)

Empfohlene Praktiken

Clientseitige Verschlüsselung bevorzugen — Server soll nicht lesen können
Open-Source-Dienste bevorzugen — Sicherheitsbehauptungen müssen überprüfbar sein
Zusätzlichen Passwortschutz nutzen — bei abgefangenem Link kein Zugriff ohne Passwort
Link und Passwort getrennt übermitteln — Link per E-Mail, Passwort per Telefon oder Signal
In Firmennetzwerken vorsichtig sein — SSL-Inspection kann TLS aufbrechen, clientseitige Verschlüsselung ist dann die einzige Schutzschicht

Rechtlicher Kontext in Deutschland

Ein Aspekt, den die Technik-Perspektive oft ausblendet: In Deutschland gelten für Burn-after-read-Dienste gleich mehrere rechtliche Rahmenwerke:

TTDSG (Telekommunikation-Telemedien-Datenschutz-Gesetz): Verpflichtet Anbieter zu transparenter Information über Cookies und Tracking
DSGVO: Betroffenenrechte, Löschkonzepte, Dokumentation
TKG § 170 ff.: Anbieter mit über 100 000 Nutzern müssen unter Umständen Bestandsdaten auskunftspflichtig machen
BSI-Empfehlungen: Für Behörden sind BSI-Technische Richtlinien bindend (TR-02102 für Krypto-Verfahren)

Für unternehmensinterne Lösungen empfiehlt das BSI klar: clientseitige Verschlüsselung (AES-256 oder XChaCha20), Zero-Knowledge, lückenlose Audit-Logs — ohne Klartext-Logging.

lpic.cc und Passwortschutz

Beim Teilen von Bildern bietet lpic.cc Passwortschutz: Beim Upload lässt sich ein Passwort setzen, ohne das kein Zugriff möglich ist.

Ehrlich gesagt: Der Passwortschutz bei lpic.cc entspricht serverseitiger Zugriffskontrolle (ähnlich Muster 1), nicht clientseitiger Zero-Knowledge-Verschlüsselung (Muster 2). Das bedeutet:

Der Server hält die Original-Bilddaten
Passwortschutz dient der Zugriffskontrolle, nicht der Ende-zu-Ende-Verschlüsselung
Geeignet für "Nicht jeder mit Link soll das Bild sehen"
Nicht geeignet für Szenarien mit kryptografischem Sicherheitsanspruch

Für alltägliches Bild-Sharing mit Diskretionsanspruch ist es praktisch. Für militärische Vertraulichkeit brauchen Sie spezialisierte Ende-zu-Ende-Tools.

FAQ

Sind die Daten nach einem Burn-after-read-Zugriff wirklich nicht wiederherstellbar?

Hängt von der Implementierung ab. Im Server-Modus können Daten in Backups, CDN-Caches oder nicht überschriebenen Speicherblöcken weiter existieren. Im Client-Verschlüsselungs-Modus: Selbst wenn der Ciphertext nicht vollständig gelöscht wurde, ist er ohne Schlüssel kryptografisch unrekonstruierbar. Der Schlüssel ist aber, wenn die URL nirgends mehr existiert, vernichtet. Gerenderte Inhalte auf dem Bildschirm des Empfängers sind davon nicht betroffen.

Hilft der Inkognito-Modus?

Teilweise. Inkognito verhindert History-, Cookie- und Cache-Persistenz, die URL mit dem Schlüssel landet nicht auf der lokalen Festplatte. Aber: Netzwerküberwachung (ISP, Firmen-Firewall) wird dadurch nicht abgewehrt, und Screenshots auch nicht.

Sind Selbstzerstörungs-Countdowns wirklich wirksam?

Kaum. Der Countdown ist reines JavaScript im Browser — ein Screenshot während der Anzeige oder ein Deaktivieren per DevTools ist trivial. Der Wert ist psychologisch, nicht technisch: Er erinnert den Empfänger daran, dass der Inhalt vertraulich ist.

Kann Burn-after-read das Weiterleiten verhindern?

Nein. Der Empfänger kann den Link vor dem Öffnen an Dritte weiterreichen, und diese öffnen dann stattdessen. Ein zusätzlicher Passwortschutz erhöht die Hürde (Weiterleitende müssen Link UND Passwort übermitteln), verhindert aber nicht Screenshots nach Öffnung.

Ist Burn-after-read in deutschen Unternehmen sicher?

Besser als Klartext-Transport — aber mit Vorbehalt. Viele Unternehmen betreiben SSL-Inspection (TLS-Entschlüsselung auf der Firewall). Bei serverseitigen Lösungen kann die IT-Abteilung mitlesen. Clientseitig verschlüsselte Open-Source-Tools (Yopass, hat.sh, Passbolt) sind die empfohlene Wahl. Für regulierte Branchen (Banken, Versicherungen, Gesundheitswesen) sollte die Lösung zusätzlich BSI-TR-02102-konform sein.

Gibt es DSGVO-kompatible Burn-after-read-Dienste mit EU-Hosting?

Ja. CryptPad bietet EU-Instanzen, Passbolt lässt sich selbst hosten (Docker-Images verfügbar), Yopass ist MIT-lizenziert und in 10 Minuten auf einem Hetzner-Server aufgesetzt. Für größere Organisationen lohnt die Eigeninstallation — volle Kontrolle, keine Drittlandübermittlung.

Quellen

#Burn-after-read#Einweglinks#Kryptografie#Datensicherheit#Privatsphäre

Verfasst von

Kevin Wu

Sicherheitsberater

Fokus auf Datenschutz und Datensicherheit – hilft, versteckte Risiken beim Bildteilen zu vermeiden.