One Time Delivery (OTD) – Whitepaper
1. Ziel und Problemstellung
In IT-Projekten müssen Zugangsdaten (z.B. Passwörter, Tokens oder API-Keys) häufig kurzfristig übermittelt werden.
In der Praxis werden, leider sehr häufig und viel zu oft, diese sensiblen Informationen oft zusammen mit dem Projekt-Kontext (Serveradresse, Benutzername, Link, Ticketnummer) über denselben Übertragungskanal versendet (z.B. E-Mail oder Ticketsystem).
Wird oder ist dieser Kanal kompromittiert, sind Secret und Kontext gleichzeitig betroffen.
OTD (One Time Delivery) soll bewusst keine Wunderwaffe dagegen sein, sondern ein ergänzender Sicherheitsbaustein:
Das Secret wird kontextfrei, zeitlich begrenzt und nur einmal ausgeliefert – idealerweise über einen anderen Kommunikationsweg als die Projektinformationen.
2. Konzept und Ablauf
Der Ablauf von OTD ist bewusst einfach gehalten:
Erzeuger gibt ein Secret (max. 30 Zeichen) sowie die Empfänger-E-Mail-Adresse ein.
OTD erzeugt einen einmaligen Link (bestehend aus einer ID und einem Token).
Der Link wird ausschließlich per E-Mail an den Empfänger versendet.
Beim Öffnen des Links wird zunächst kein Secret angezeigt (Preview-sicher).
Erst nach expliziter Aktion („Anzeigen / Reveal“) wird das Secret sichtbar.
Ab diesem Zeitpunkt läuft ein unveränderlicher Timer (Standard: 300 Sekunden).
Innerhalb dieses Zeitfensters ist Reload nur im selben Browser möglich.
Nach Ablauf wird das Secret serverseitig irreversibel zerstört (Burn).
3. Sicherheitsprinzipien
OTD basiert auf klaren Sicherheitsprinzipien:
Kanaltrennung: Secret und Projekt-Kontext sollen über unterschiedliche Kommunikationswege übertragen werden.
Einmaligkeit: Das Secret ist nur kurzzeitig und nur einmalig anzeigbar.
Preview-Sicherheit: E-Mail-Scanner, Vorschauen oder Bots können das Secret nicht auslesen.
Minimierung: Keine Benutzerkonten, kein Login, keine dauerhafte Historie.
Fail-Closed-Design: Fehlerzustände führen zur Ungültigkeit, nicht zur Freigabe.
4. Kryptographie und eingesetzte Verfahren
OTD schützt gespeicherte Secrets konsequent im Ruhezustand (at rest):
Verschlüsselung: AES-256-GCM (Authenticated Encryption / AEAD)
Schlüssel: 32 Byte symmetrischer Schlüssel (Base64, Deployment-Secret)
Nonce: pro Secret zufällig (12 Byte)
Speicherung: SQLite speichert ausschließlich Nonce + Ciphertext, nicht den Klartext
Token-Validierung:
Session-Kontrolle (Reload):
5. E-Mail-Versand
Der Versand erfolgt über ein dediziertes SMTP-Postfach:
Protokolle: SMTPS (465) oder SMTP + STARTTLS (587)
Authentifizierung: Benutzername + Passwort
Kein IMAP, kein Postausgangs-Abruf
OTD speichert keine gesendeten E-Mails
Hinweis: Der Mailaccount, den OTD selbst verwendet, führt keine Postausgangshistorie.
Dieses kann ich, als Betreiber des privaten Mailserver (mx.gbrands.info), gerne auch eidesstattlich, versichern.
6. Betrieb und finale Härtungen
6.1 Betrieb über Reverse Proxy
TLS-Termination
HTTP → HTTPS Redirect
HSTS-Aktivierung (z.Zt. noch staged)
Strikte Allowlist von Pfaden
Alle anderen Requests werden verworfen (HTTP 444)
Rate-Limits & Connection-Limits
6.2 Host-Security
Firewall restriktiv konfiguriert
Fail2ban aktiv (systemd/journal basiert)
Dienst ausschließlich auf Loopback (IPv6 ::1)
Reverse Proxy als einzige Eintrittsstelle
6.3 Applikationsschutz
CSRF-Schutz (Double-Submit-Cookie)
Cache-Control: no-store (keine Caches von sensitiven Seiten)
Link wird dem Erzeuger nicht angezeigt (Link nur per E-Mail an Empfänger)
7. Empfehlung des BSI (Awareness)
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt, Zugangsdaten und zugehörige Informationen über getrennte Übermittlungswege zu versenden (Kanaltrennung), um das Risiko bei kompromittierten Kanälen zu reduzieren.
Quellen:
8. Grenzen
OTD ersetzt keine Passwortmanager- oder Identity-Lösung.
Es schützt nicht vor kompromittierten Endgeräten (Erzeuger/Empfänger), reduziert jedoch Risiko durch:
9. Zusammenfassung
OTD ermöglicht eine pragmatische und auditierbare Zustellung einzelner Secrets – kontextfrei, kurzlebig, einmalig und operativ gehärtet.