Das Tool ist hier zu finden: One Time Delivery

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.

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).

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.

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:

• Tokens werden niemals im Klartext gespeichert.
• Die Verifikation erfolgt über einen Hash-Mechanismus (Argon2-basiert).

Session-Kontrolle (Reload):

• Nach erstem Reveal wird ein Browser-spezifischer Session-Cookie gesetzt.
• Hashvergleich verhindert erneute Anzeige in anderen Browsern.

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.

• 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

• Firewall restriktiv konfiguriert
• Fail2ban aktiv (systemd/journal basiert)
• Dienst ausschließlich auf Loopback (IPv6 ::1)
• Reverse Proxy als einzige Eintrittsstelle

• 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)

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:

• Deutsch: https://www.bsi.bund.de/DE/Themen/Verbraucherinnen-und-Verbraucher/Informationen-und-Empfehlungen/Cloud-Computing-Sicherheitstipps/Cloud-Risiken-und-Sicherheitstipps/cloud-risiken-und-sicherheitstipps_node.html
• Englisch: https://www.bsi.bund.de/EN/Themen/Verbraucherinnen-und-Verbraucher/Informationen-und-Empfehlungen/Cloud-Computing-Sicherheitstipps/Cloud-Risiken-und-Sicherheitstipps/cloud-risiken-und-sicherheitstipps_node.html

OTD ersetzt keine Passwortmanager- oder Identity-Lösung. Es schützt nicht vor kompromittierten Endgeräten (Erzeuger/Empfänger), reduziert jedoch Risiko durch:

• Kanaltrennung
• Zeitliche Begrenzung
• Einmalige Anzeige
• Härtung auf Netzwerk- und Applikationsebene

OTD ermöglicht eine pragmatische und auditierbare Zustellung einzelner Secrets – kontextfrei, kurzlebig, einmalig und operativ gehärtet.