Merken Sie sich einen prüfbaren Satz: Das erste Öffnen der Leseseite darf nur die Hülle laden. Es darf noch keinen Chiffretext holen. Nach einem Klick auf Öffnen und ansehen erscheint in Network eine Anfrage per id. Nach einem erfolgreichen Abruf, der die Anzahl ausschöpft, sollte dieselbe id 410 liefern. In der Adresszeile darf der Schlüssel hinter # stehen. In der Anfragezeile darf dieselbe Zeichenkette nicht vorkommen.
Der Link kann noch existieren, der Chiffretext nicht mehr
„Nach dem Lesen gelöscht“ wird oft so gehört: der blaue Link fängt Feuer, also ist der Inhalt weg. Die Metapher zeigt meist auf das falsche Objekt. Messenger löschen eine Nachricht nicht, nur weil das Ziel 410 zurückgibt. Browser-Historie, die Originalmail und der Ticketkommentar bleiben. Was verbrennt, ist der kurzlebige Chiffretext auf dem Host. Die volle URL in einer Hand ist weiterhin eine Zeichenkette. Beim nächsten Öffnen zeigt die id auf ein Objekt, das nicht mehr da ist.
Bevor Sie fragen, was übrig bleibt, trennen Sie zwei Nachweise. Der eine ist der Locator: die id hinter dem Fragezeichen, mit der der Server den Datensatz findet. Der andere ist der Entschlüsselungsschlüssel: das Fragment hinter der Raute, das im aktuellen Tab bleibt. Der Host soll den ersten sehen und den zweiten nie. Nach einem erfolgreichen Lesen kann der Locator noch auf einen leeren Platz zeigen. Steht der Schlüssel noch im Chatverlauf, entschlüsselt er nichts – der Chiffretext ist weg.
Ein Share-Link in der Cloud arbeitet umgekehrt. Solange der Link gültig ist, liegt die Datei in der Regel noch auf dem Laufwerk. Sie entziehen eine Berechtigung; Sie löschen das Objekt nicht beim ersten Öffnen. Ein Einmal-Link bindet „Lesen“ und „Löschen“ an denselben Abruf. Beim Erstellen setzen Sie eine Leseanzahl (1–10, Standard 1) und eine Laufzeit (1 Stunde, 24 Stunden, 7 Tage, oder nur nach dem Lesen löschen). Der Standardweg ist: erster erfolgreicher Abruf, Chiffretext weg. Ungelesen und abgelaufen: dieselbe Löschung. In keinem der beiden Fälle bleibt eine Klartextkopie, die Sie später zurückholen könnten.
Auf dem Server lag nie Klartext
„Klartext nach dem ersten Lesen löschen“ ist die andere häufige Fehlannahme. Die Reihenfolge ist: Klartext existiert nur im Tab der sendenden Seite; der Browser zieht mit Web Crypto einen 256-Bit-Zufallsschlüssel und verschlüsselt mit AES-256-GCM; ausgehend gehen Chiffretext, Ablaufzeit und maximale Leseanzahl. Der Server gibt eine nicht erratbare id zurück. Die Seite hängt den Schlüssel an s.html?id={id}#{key}. Es gibt keinen Schritt, der die Passphrase zuerst in eine Datenbank schreibt und sie danach verschlüsselt.
Die Parameter sind prüfbar, kein Slogan. NIST SP 800-38D empfiehlt für GCM eine 96-Bit-IV (12 Byte), damit Implementierungen interoperabel und einfach bleiben; das Authentifizierungs-Tag ist üblicherweise 128 Bit (16 Byte). Die AesGcmParams von Web Crypto folgen dieser Form. Bei MakePwd ist der Chiffretext Base64 aus 12-Byte-IV + Chiffretext + 16-Byte-Tag. Der Schlüssel ist 32 Byte. Ein Eintrag ist auf 32 KB begrenzt. Diese Zahlen stehen auf der Erstellungsseite. Sie können einen gerade erzeugten Link auch selbst prüfen: hinter der Raute steht der Schlüssel in Base64URL, nicht der Satz, den Sie getippt haben.
GCM liefert außerdem Integrität. Wurden Chiffretext oder Tag verändert, scheitert die Entschlüsselung in diesem Tab. Sie bekommen keinen „ungefähr richtigen“ Klartext. Das blockiert Manipulation unterwegs. Es blockiert keinen Screenshot, nachdem jemand den Text bereits gelesen hat. Der Server hat den Schlüssel nie, kann also nicht in Ihrem Namen entschlüsseln, den Inhalt nicht prüfen und nach dem Lesen keine Klartextkopie nachlegen. Was er tun kann: Chiffretext per id herausgeben und ihn danach nach Anzahl oder TTL löschen.
| Phase | Im Browser | Auf dem Server |
|---|---|---|
| Erstellen abgeschlossen | Klartext, den Sie gerade eingegeben haben, plus voller Link | Chiffretext, id, TTL, verbleibende Lesungen |
| Leseseite zeichnet zum ersten Mal | id und #-Schlüssel in der Adresszeile |
Noch Chiffretext; dieses Zeichnen hat ihn nicht gelöscht |
| Bestätigter Abruf erfolgreich | In diesem Tab entschlüsselter Klartext | Gelöscht, wenn die Anzahl ausgeschöpft ist; sonst um eins verringert |
| Dieselbe id erneut geöffnet | Der Schlüssel kann noch in der Adresszeile stehen | Gelöscht oder abgelaufen; eine Antwort der Klasse 410 |
Locator hinter dem Fragezeichen, Schlüssel hinter der Raute
Ein einmaliger Link muss zwei Dinge gleichzeitig tun: dem Server sagen, welchen Datensatz er holen soll, und dem Browser der empfangenden Seite sagen, welchen Schlüssel er nutzen soll. Diese beiden Aufgaben gehören nicht in dasselbe HTTP-Feld. Die Query hinter ? landet in der Anfragezeile; Reverse-Proxy und Access-Log sehen sie absichtlich. Das Fragment hinter # bleibt nach Spezifikation beim Client.
RFC 9110, Abschnitt 7.1 ist eindeutig: die Ziel-URI enthält kein Fragment, weil Fragmentkennungen der Client verarbeitet. Der Browser fordert s.html?id=… an, nicht die ganze Adresszeile. Wandert der Schlüssel nach ?key=, ist „nur Chiffretext“ auf der Protokollebene bereits falsch: wer das Access-Log des Tages öffnet, hält die zweite Hälfte, die zur Entschlüsselung fehlt.
Die vorige Notiz hat diese Schicht bereits ausgebreitet. Die Grenze hier ist kurz: die Trennung hält den Schlüssel vom Host fern. Sie macht die volle Zeichenkette nicht frei weiterleitbar. Fügen Sie eine URL mit # in den Chat ein, sehen Empfängerin, Empfänger und der Chat-Anbieter den Schlüssel. Ein Fragment blockiert HTTP. Es blockiert nicht die Zwischenablage. Prüfschritte, die Sie in Network nachvollziehen können, stehen in Warum ein URL-Fragment hinter der Raute ein passender Ort für einen Schlüssel ist – und wann dieser Schutz wegfällt.
Der Abruf des Chiffretexts ist der Löschpunkt, nicht das erste Zeichnen
Die Leseseite zu öffnen und ein Lesen zu verbrauchen sind nicht dasselbe Ereignis. Das HTML der Leseseite kann zuerst zeichnen: prüfen, ob die Adresse ?id= und einen #-Schlüssel hat, und dann auf einer Bestätigungsschaltfläche stehen bleiben. Dieser Schritt kostet nur statische Ressourcen. Die Anfrage, die den Server zum Löschen bringt, ist der spätere Abruf per id. Nach dem Klick, dem erfolgreichen Abruf und der ausgeschöpften Anzahl wechselt der Datensatz von „noch holbar“ zu „gelöscht“.
Ohne Schlüssel darf kein Abruf laufen. Steht in der Adresse nur eine id – weil ein Messenger die Raute abgeschnitten hat – soll die Leseseite das fehlende Fragment melden, nicht zuerst Chiffretext vom Server holen. Sonst verbrauchen Sie das einzige Lesen: der Server gibt Chiffretext heraus und löscht ihn, der Browser kann nicht entschlüsseln, und die sendende Seite glaubt, die Gegenseite habe bereits gelesen. Das prüfbare Verhalten ist: ohne # darf in Network keine Chiffretext-API erscheinen; mit vollem Link und Bestätigungsklick schon.
Die Anzahl ist nicht immer 1. Beim Erstellen sind 1 bis 10 möglich. Setzen Sie 3, liegt der Chiffretext nach den ersten beiden erfolgreichen Abrufen noch auf dem Server; nur die Restanzahl sinkt. Der dritte Erfolg löscht ihn. Der Standard 1 passt zur Aufgabe „ein Passwort übergeben“, nicht zu einem Protokoll, das nur einmal gelesen werden könnte. TTL ist eine unabhängige Löschbedingung: nach 24 Stunden ungelesen ist der Chiffretext ebenfalls weg, und der Zustand sollte sich von „schon gelesen“ unterscheiden lassen. Die MakePwd-Leseseite wertet expired in einer 410-Antwort als Ablauf; andere gelöschte Zustände als bereits zerstört.
Testen Sie nicht mit einem echten Passwort, einem Produktions-API-Key oder einer ungeschwärzten Verbindungszeichenkette. Nehmen Sie einen wegwerfbaren Canary, etwa canary-burn-2026-do-not-reuse. Sie prüfen Statuscodes und die Anfragezeile, Sie verbreiten kein weiteres Geheimnis.
410 und 404: gelöscht, abgelaufen oder nie vorhanden
Nachdem der Chiffretext weg ist, muss der Server die nächste Anfrage trotzdem beantworten. RFC 9110, Abschnitt 15.5.11 beschreibt 410 Gone so: die Zielressource ist auf dem Ursprungsserver nicht mehr verfügbar, und dieser Zustand ist wahrscheinlich dauerhaft. Kann der Ursprung das nicht sagen, soll er 404 verwenden. Die MDN-Erläuterung zu 410 ergänzt: Clients sollen nicht weiter wiederholen, und die Website soll Links entfernen, die noch auf die Ressource zeigen.
Für einen Einmal-Link passt 410 besser als 404: diese id hat einmal ein Chiffretextobjekt benannt, das Objekt wurde absichtlich gelöscht, und es kommt nicht zurück. Ablauf und ausgeschöpfte Anzahl können beide 410 liefern; der Antwortkörper trennt expired von einer normalen Löschung, damit die Gegenseite nicht denkt, der Link sei vertippt. 404 kann trotzdem auftreten – ungültige id oder ein Datensatz, der so gründlich bereinigt wurde, dass der Host nicht mehr behauptet, er habe je existiert. Für die sendende Seite bedeuten beide Antworten dasselbe: erwarten Sie nicht, dass der Host den Inhalt zurückgibt.
410 sagt Crawlern außerdem, sie sollen nicht wiederkommen. Die Leseseite ist eine vorübergehende Chiffretext-Landung. Sie gehört für Suchmaschinen auf noindex und nicht in eine Sitemap. Eine Einmal-Passwortseite soll nicht indexiert werden. Die Erstellungsseite darf indexiert werden, weil sie erklärt, wie ein Link entsteht. Die Leseseite bedient nur Personen, die die volle URL bereits halten.
Warum eine Chat-Vorschau das einzige Lesen verbrauchen kann
Der häufigste Unfall ist kein Kryptograf, der AES bricht. Es ist ein Vorschaubot, der schneller klickt als die Kollegin. Sie fügen die volle URL in den Chat ein. Der Client fordert die Adresse an, um eine Karte zu zeichnen. Die Unfurl-Dokumentation von Slack sagt es geradeheraus: erscheint ein Link in einer Nachricht, holt Slack ihn standardmäßig und bietet eine Vorschau. Teams, Discord und manche Mail-Sicherheits-Scanner machen einen ähnlichen Abruf. Sie wollen Titel und Kurztext, nicht Ihr Passwort. Holt „das erste GET“ bereits den Chiffretext und löscht ihn, verbraucht dieser Crawl das einzige Lesen. Die Kollegin öffnet eine bereits gelöschte Seite.
Ein Schlüssel hinter # schützt gegen diesen serverseitigen Abruf eine Schicht weit: der Bot fordert s.html?id=… an, das Fragment geht nicht über HTTP. Die Vorschau kann in der Regel nicht entschlüsseln, die Karte zeigt keine Passphrase. Was sie verbrennen kann, ist die Leseanzahl, nicht der Schlüssel. Holt Ihre Leseseite den Chiffretext schon beim Laden, entspricht die Vorschau einem Klick auf Öffnen und ansehen für die empfangende Seite. Sie sieht 410. Sie denken, sie habe bereits gelesen.
Die tragfähige Gegenmaßnahme ist nicht „nie einen Link einfügen“. Sie trennt „Seite zeichnen“ von „Chiffretext holen“. Die Leseseite zeigt zuerst die Bestätigung und sagt, dieser Klick verbraucht ein Lesen; erst dann geht der Abruf raus. Eine Vorschau, die HTML holt und die Schaltfläche nicht klickt, bleibt auf der Bestätigung stehen. Das hält keinen Scanner auf, der das volle Skript ausführt und einen Klick simuliert, und es hält keine Person auf, die die falsche Karte trifft. Es ändert den häufigen Fall „die Karte hat einmal geöffnet“ vom Standardfehler zum überlebenden Link.
Ein zweiter Habit hilft in Kanälen, die automatisch aufklappen: zuerst „Passwort geht über einen Einmal-Link, URL folgt getrennt“ schreiben, oder die volle Zeichenkette in eine Direktnachricht legen, die nicht vorschaut. Die volle URL bleibt ein Inhabernachweis. Unfurl verbraucht nur eine Anzahl. Es ändert nicht: wer die ganze Kette hat, kann entschlüsseln.
Sofort prüfen: zuerst auf der Bestätigung bleiben, dann Network durchsuchen
Die Sätze „nach dem Lesen gelöscht“ und „Zero Knowledge“ beweisen sich nicht selbst. Vier Dinge können Sie sehen: ob das Erstellen Klartext gesendet hat; ob das erste Laden der Leseseite Chiffretext geholt hat; ob die Bestätigungs-Anfragezeile den Schlüssel enthält; und ob das zweite Öffnen nach ausgeschöpfter Anzahl 410 ist.
Legen Sie zuerst einen Canary an. Öffnen Sie die Einmal-Link-Erstellungsseite, tippen Sie einen wegwerfbaren Satz, setzen Sie die TTL auf 1 Stunde und lassen Sie die Leseanzahl auf 1. Schicken Sie das Ergebnis niemandem. Sehen Sie sich die Trennung im Ergebnisbereich an: die Query-Seite ist nur die id; die Fragment-Seite ist der Schlüssel. Öffnen Sie dann die Entwicklertools, Network, aktivieren Sie Preserve log und suchen Sie den ganzen Canary. Der Erstellungsrumpf soll Chiffretext sein, nicht dieser Satz. Analytics soll den Satz ebenfalls nicht tragen.
- Öffnen Sie die Leseseite mit demselben vollen Link. Klicken Sie die Bestätigung noch nicht. In Network sollen nur Dokument und statische Ressourcen stehen – kein Chiffretext-Abruf per id.
- Legen Sie Adresszeile und Anfragezeile des Dokumentabrufs nebeneinander. Die Adresszeile behält
#und alles danach. Die Anfragezeile soll nur Pfad und?id=zeigen. - Klicken Sie auf Bestätigen. Jetzt soll der Chiffretext-Abruf erscheinen. Nach Erfolg zeigt die Seite Klartext. Öffnen Sie denselben Link ein zweites Mal. Sie sollen auf „bereits gelöscht“ oder 410 landen, nicht wieder auf demselben Canary.
Drei saubere Durchläufe stützen nur eine enge Aussage: in diesem Browser, bei diesem Lauf, ist Klartext nicht als beobachtetes Geschäftsfeld hinausgegangen, der Schlüssel ist nicht in die Anfragezeile gelaufen, und der Chiffretext war nach einem erfolgreichen Abruf nicht mehr holbar. Das beweist nicht, dass eine Erweiterung das Eingabefeld nie gelesen hat, und es beweist nicht, dass eine kompromittierte Festplatte niemals historischen Chiffretext gehalten hat. Wechseln Sie den Browser, lohnt sich der Canary erneut. Wollen Sie außerdem prüfen, ob Klartext irgendeine Werkzeugseite verlassen hat, stehen die Schritte in Im Browser verschlüsseln: so prüfen Sie, dass Klartext das Gerät nicht verlassen hat.
Kopieren, Screenshot und Weiterleiten der vollen URL stoppt er nicht
Ein selbstzerstörender Einmal-Link senkt zwei Risiken: langfristigen Klartext auf dem Server und dass derselbe Chiffretext immer wieder geöffnet wird. Ein drittes senkt er nicht: was die empfangende Seite tut, nachdem sie Klartext sieht. Sie kann kopieren, einen Screenshot machen, weiterleiten oder den Text vorlesen. Der Link selbst lässt sich vollständig weiterleiten – Schlüssel und id reisen zusammen – und die nächste Person kann auf der Leseseite entschlüsseln, solange noch eine Lesung übrig ist.
Deshalb löst „die Gegenseite muss sich anmelden“ die Übergabe nicht. Die Zugriffskontrolle ist die volle URL. Ein Kontotor auf der Leseseite hält den Schlüssel nicht vom Server fern – der Schlüssel darf den Server nie erreichen. Es setzt der empfangenden Seite nur eine weitere Tür vor und ändert „wer den Link hält“ in „wer ein Konto hat“. MakePwd hat weder Konten noch einen Passworttresor. Erstellen und Lesen sind sofort nutzbar. Die Leseseite ist für Empfängerinnen und Empfänger öffentlich.
Auch die Kapazität hat eine Grenze. 32 KB reichen für eine Passphrase, einen API-Key, einen Wiederherstellungscode und eine kurze Notiz. Sie reichen nicht für einen Datenbankdump oder ein ganzes Zertifikatspaket. Eine ganze Datei soll auf diesem Gerät zu .lock / .enc werden und über Laufwerk oder Mail reisen. Die Dateiverschlüsselung nimmt eine Datei bis 5 GB, ebenfalls ohne Konto, und lädt Klartext standardmäßig nicht hoch. Eine große Datei in den kurzen Textkanal zu zwängen ist nicht „sicherer“. Es liegt außerhalb dessen, wofür dieser Weg gebaut ist.
Den gelöschten Zustand auf einer sofort nutzbaren Erstellungsseite üben
Wenn Sie ein Werkzeug wollen, das die Trennung von Query und Fragment in den Ergebnisbereich schreibt, beginnen Sie mit dem Einmal-Link von MakePwd. Er ist auf beiden Seiten sofort nutzbar, ohne Registrierung. Die Verschlüsselung beim Erstellen läuft in diesem Tab mit AES-256-GCM. Der Server erhält Chiffretext, ttl_hours (0–168, Standard 24) und max_reads (1–10, Standard 1). Der erzeugte Link hat immer die Form s.html?id={id}#{key}. Die Leseseite bleibt zuerst auf der Bestätigung, holt dann den Chiffretext und entschlüsselt in diesem Tab.
Nutzen Sie den Canary oben und lassen Sie die Leseanzahl auf 1. Beobachten Sie drei Stellen gleichzeitig: die Query-/Fragment-Trennung beim Erstellen, ob Network beim ersten Laden der Leseseite schon Chiffretext holt, und ob das zweite Öffnen den gelöschten Zustand zeigt. Die Trennung bestätigt, dass der Schlüssel nicht in die Query gelaufen ist. Das erste Laden bestätigt, dass eine Vorschau nicht versehentlich verbrennt. Das zweite Öffnen bestätigt, dass „nach dem Lesen gelöscht“ keine Werbezeile ist.
Muss der übrige Inhalt vor dem Versand noch Tracking-Parameter verlieren, zuerst die Linkbereinigung nutzen und erst den kurzen Text, der wirklich geheim bleiben muss, in den Einmal-Link legen. Die Bereinigung entfernt UTM und Klick-IDs aus einer Query. Sie ersetzt keinen einmaligen Chiffretextkanal. Keiner dieser Schritte verlangt ein Konto, und keiner zeigt ein Support-Postfach, das nicht angeschlossen ist.
Häufige Fragen
Liegt nach dem einmaligen Öffnen noch Klartext auf dem Server?
Klartext lag dort nie. Der Browser verschlüsselt zuerst. Der Server erhält nur Chiffretext. Nach einem erfolgreichen Abruf, der die gesetzte Anzahl ausschöpft, wird der Chiffretext gelöscht. Eine spätere Anfrage derselben id sollte 410 oder den Zustand „bereits gelöscht“ zeigen. Die URL-Zeichenkette kann im Chatverlauf stehen. Das ist keine Klartextkopie auf dem Host.
Verbraucht eine Chat-Vorschau den Inhalt zuerst?
Sie kann die Anzahl verbrauchen. Den Klartext in der Regel nicht. Die Vorschau holt die Seite; der Schlüssel hinter # geht nicht über HTTP. Holt die Leseseite den Chiffretext schon beim Laden, verbraucht die Vorschau das einzige Lesen. Die richtige Umsetzung bestätigt zuerst, dann holt sie. Slack und vergleichbare Produkte holen Links in einer Nachricht standardmäßig, um eine Karte zu zeichnen.
Worin unterscheiden sich 410 und 404?
410 heißt: die Ressource war verfügbar und wurde dauerhaft entfernt; Clients sollen nicht wiederholen. 404 ist unschärfer: die id kann ungültig sein, oder der Datensatz ist bereits bereinigt. Ein Einmal-Link ist klarer, wenn 410 gelöscht und abgelaufen trennt. In beiden Fällen gibt es keinen Klartext zum Wiederherstellen.
Muss ich mich anmelden, um die Leseseite zu öffnen?
Nein. Erstellen und Lesen sind sofort nutzbar. Die empfangende Seite holt den Chiffretext über die id und entschlüsselt in diesem Tab mit dem Schlüssel hinter der Raute. MakePwd hat weder Konten noch einen Passworttresor. Die Zugriffskontrolle ist der volle Link selbst.
Drei Dinge vor dem nächsten Einmal-Geheimnis
Erstens: wenn Sie fragen, was nach dem Lesen übrig bleibt, fragen Sie zuerst, ob auf dem Server je Klartext lag. Das war nicht der Fall. Gelöscht wird Chiffretext. Eine URL im Chat entschlüsselt nichts. Zweitens: der Löschpunkt ist der Chiffretext-Abruf, nicht das erste Zeichnen der Leseseite. Die Bestätigungsschaltfläche gilt Vorschaubots, nicht jemandem, der die ganze Kette schon hat. Drittens: Network prüfen – beim Erstellen den Canary suchen, beim Lesen Anfragezeile und # vergleichen, beim zweiten Öffnen 410 erwarten.
Wenn Sie weiterverfolgen wollen, warum ein Schlüssel hinter der Raute stehen darf, lesen Sie Warum ein URL-Fragment hinter der Raute ein passender Ort für einen Schlüssel ist – und wann dieser Schutz wegfällt. Dieser Text macht aus „was nach einmaligem Lesen auf dem Server bleibt“ einen Bereich, den Sie an Statuscodes und Anfragezeitpunkt legen können.