Technische Spezifikationen & Sicherheitsarchitektur

Live-Nachrichten werden im Browser via Web Crypto API mit AES-256-GCM verschlüsselt, bevor sie die Datenbank berühren. Der symmetrische Chat-Schlüssel wird serverseitig deterministisch per HKDF-SHA-256 für den jeweiligen Slot abgeleitet (unter Verwendung der slotId als Salt), an die autorisierten Clients übermittelt und dort nur im React-State gehalten. Pro Nachricht wird ein kryptografisch zufälliger Initialisierungsvektor (IV, 12 Byte) verwendet. Die Live-Nachrichtentabelle enthält ausschließlich Ciphertext und IV; das beim ordentlichen Schließen erzeugte Redaktionsarchiv ist davon getrennt und wird in Abschnitt 06 beschrieben.

Zugangspasscodes werden irreversibel gehasht. Die Implementierung nutzt PBKDF2-HMAC-SHA-256 mit 600.000 Berechnungsrunden und einem eindeutigen, zufälligen 16-Byte-Salt pro Datensatz. Die Verifikation erfolgt in konstanter Zeit (Constant-Time Verification) zum Schutz vor Timing-Angriffen. Der Datenbank-Lookup erfolgt datenschutzkonform über einen deterministischen Blind Index (HMAC-SHA-256 mit serverseitigem Pepper) – der Server authentifiziert Nutzer, ohne deren Klartext-Passcode oder den primären Passwort-Hash für die Suche heranzuziehen.

Der Brute-Force-Schutz basiert auf einem flüchtigen, im RAM verwalteten Fixed Window: Nach drei Fehlversuchen wird der Zugriff für zehn Minuten gesperrt. IP-Adressen werden zuvor gekürzt (IPv4 auf /24, IPv6 auf /48) und via HMAC-SHA256 pseudonymisiert. Um eine tagesübergreifende Verkettbarkeit (Linkability) von Nutzeraktivitäten systemisch auszuschließen, rotiert der im RAM gehaltene Pseudonymisierungs-Key vollautomatisch alle 24 Stunden. Weder IP-Adressen noch deren Pseudonyme werden in der Anwendungsdatenbank gespeichert.

Da AES-GCM manipulationssicher ist, aber keinen inhärenten Schutz vor dem Wiedereinspielen identischer Payloads bietet, verfügt die Anwendung über einen dedizierten Replay-Guard. Dieser trackt alle verwendeten GCM-IVs pro Slot flüchtig im Arbeitsspeicher mit einer Time-To-Live (TTL) von 5 Minuten – bereits bekannte IVs werden blockiert. Die Anwendung erzwingt für veröffentlichte Zugriffe HTTPS-Upgrades per HSTS; die konkrete TLS-Version wird von der Hosting-Infrastruktur ausgehandelt. Das geschützte, als HttpOnly-, Secure- und SameSite-Lax-Cookie gesetzte Partner-Session-Cookie hat eine konfigurierte Lebensdauer von 60 Minuten und wird beim expliziten Abmelden gelöscht.

Die logische Datenisolation wird auf Datenbankebene über PostgreSQL Row-Level Security (RLS) erzwungen; administrative Zugriffe werden anhand verifizierter JWT-Claims geprüft. Beim ordentlichen Schließen werden die verschlüsselten Live-Nachrichten und die zugehörige Buchung explizit gelöscht. Zuvor wird aus den im autorisierten Admin-Browser entschlüsselten Nachrichten ein redaktionelles Gesprächsprotokoll erzeugt und dauerhaft in einer separaten Archiv-Tabelle gespeichert. Dieses Archiv ist nicht öffentlich und durch RLS ausschließlich für den authentifizierten Administrator zugänglich. IP-Adressen, Session-Cookies und die flüchtigen Rate-Limit-Pseudonyme werden nicht in diesem Archiv gespeichert.