Was geschützt ist und was nicht.
Ein Sicherheitswerkzeug, das nur Stärken nennt, ist nicht glaubwürdig. Hier steht das vollständige Bedrohungsmodell: wogegen ExoSeal schützt, wo es endet und wie du alles selbst prüfst.
schützt
Datenbank- oder Backup-Leck. Es liegt nur Chiffretext in der Datenbank. Geheimnisse sind Einmal-Links und kurzlebig.
Neugierige Betreiber. Wer Datenbank oder Logs liest, findet weder Schlüssel noch Klartext noch IP-Adressen.
Link-Vorschau-Bots. Slack, Teams oder Outlook rufen Links nur ab. Das Öffnen braucht einen Klick auf einen Button, der Bot verbraucht nichts.
Vertippte Passwörter. Die Passphrase wird im Browser geprüft, bevor die Antwort abgerufen und gelöscht wird.
Getauschte öffentliche Schlüssel. Der Kunden-Link trägt einen Fingerabdruck des Schlüssels. Passt er nicht, bricht der Browser ab.
Gleichzeitiges Öffnen. Öffnen und Antworten sind einzelne Datenbank-Anweisungen. Bei 30 bis 40 parallelen Versuchen gewinnt genau einer.
Einschleusen von Skripten. Strenge Content-Security-Policy mit Nonce pro Anfrage und ohne externe Quellen.
Fremde Seiten und andere Subdomains. Schreibende Aufrufe nimmt der Server nur vom eigenen Ursprung an (Sec-Fetch-Site, Origin). Eine fremde oder gehackte Seite unter derselben Hauptdomain kann in deinem Namen nichts anlegen oder löschen.
Überlastung und volle Datenbank. Ratenlimits zählen eingeloggte Nutzer einzeln und alle anderen nach IP. Jeder Nutzer hat ein Kontingent (500 laufende Links, 200 laufende Anfragen), damit ein gekaperter Zugang die Datenbank nicht füllt.
schützt nicht
Ein manipulierter Server. Der verschlüsselnde Code kommt vom Server. Wer den Server übernimmt, kann veränderten Code ausliefern. Deshalb ist ExoSeal Open Source und selbst hostbar. Bei sehr hohem Risiko nimm ein natives Werkzeug wie age oder GPG.
Eine kurze Passphrase. Bei Anfragen liegt der verpackte Private Key verschlüsselt auf dem Server. 600.000 Iterationen bremsen das Raten, eine kurze Passphrase fällt trotzdem. Nimm einen langen Satz.
Eine vergessene Passphrase. Es gibt keine Wiederherstellung. Die Antwort ist weg.
Ein kompromittiertes Gerät. Schadsoftware, Blick über die Schulter oder Zwischenablage-Programme auf einer der beiden Seiten.
Metadaten. Der Server weiß, dass eine Anfrage existiert, wann sie erstellt, beantwortet und geöffnet wurde und wem sie gehört, und welcher Nutzer wann einen Link erstellt hat. Den Empfänger und den Inhalt kennt er nicht. Der Reverse-Proxy sieht IP-Adressen, wenn du das Protokollieren nicht abschaltest.
Den ganzen Link in falschen Händen. Wer den vollständigen Link vor dem Empfänger öffnet, gewinnt. Findet der Empfänger den Link verbraucht vor, stimmt etwas nicht.
Eine gestohlene Sitzung. Die Sitzung gilt fest 8 Stunden. "Abmelden" löscht das Cookie im Browser, der Server kann eine gestohlene Sitzung nicht vorzeitig beenden. Das Cookie ist HttpOnly, die strenge CSP verhindert das Auslesen per Skript.
So prüfst du es selbst.
Du musst uns nichts glauben. Drei Wege, jede Aussage zu überprüfen.
Quellcode lesen
Die Verschlüsselung steht im Frontend, die Speicherregeln im Backend. Beides ist offen unter AGPL-3.0 und kurz genug, um es an einem Nachmittag zu lesen.
Im Browser nachsehen
Öffne die Entwicklerwerkzeuge, Reiter Netzwerk. Beim Öffnen eines Links geht nie etwas hinter dem # an den Server. Das legt der Browser fest, nicht wir.
Selbst betreiben
Mit einer Compose-Datei und deinem eigenen Login-Anbieter läuft ExoSeal auf deinem Server. Dann hängt das Vertrauen nur noch an dir.
Noch eine Frage zur Sicherheit?
Die häufigsten Fragen sind beantwortet, und die Anleitungen zeigen jeden Schritt.