// security_manifest.md

Technische Spezifikationen & Sicherheitsarchitektur

Das verifizierte technologische Fundament von Schnackzeit für Entwickler und Auditoren.

Chat-Verschlüsselung (Confidentiality & Integrity)

AES-256-GCM · Application-Layer Encryption (ALE)

Sämtliche Transkripte und Gesprächsinhalte werden applikationsseitig verschlüsselt, bevor sie die Datenbank berühren. Der symmetrische Chat-Schlüssel wird flüchtig auf Serverebene via HKDF-SHA-256 pro Slot generiert (unter Verwendung der slotId als Salt). Pro Nachricht wird ein kryptografisch zufälliger Initialisierungsvektor (IV, 12 Byte) verwendet. Der PostgreSQL-Storage enthält zu keinem Zeitpunkt Klartext-Payloads.

Passcode-Verifikation & Authentifizierung

PBKDF2-HMAC-SHA-256 · 600.000 Iterationen · Blind Index

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.

Kryptografische Domänentrennung

HKDF-SHA-256 (RFC 5869) · Web Crypto API

Zur konsequenten Verhinderung von Key-Reuse-Schwachstellen wird das globale SESSION_SECRET als primäre Entropiequelle genutzt, um mittels HKDF-SHA-256 strikt getrennte, isolierte Sub-Schlüssel für separate Sicherheitsdomänen abzuleiten. Jede Ableitung verwendet ein spezifisches Kontext-Label:

schnackzeit-chat-encryption → Symmetrische Payload-Verschlüsselung
schnackzeit-ip-privacy → Token- und IP-Pseudonymisierung
schnackzeit-session-signing → Signierung flüchtiger Sitzungen

Ein kompromittierter Teilschlüssel isoliert den Schaden somit strikt auf das betroffene Subsystem.

Identitätsschutz & Transientes Rate-Limiting

HMAC-SHA256 · 24h Key-Rotation · In-Memory Sliding Window

Der Brute-Force-Schutz basiert auf einem flüchtigen, im RAM verwalteten Sliding Window. IP-Adressen werden auf Applikationsebene normalisiert 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. Es erfolgt keine persistente Speicherung oder Protokollierung von IP-Adressen oder deren Hashes in Datenbanken oder System-Logs.

Replay-Schutz & Transportsicherheit

In-Memory IV-Tracking (replay-guard.ts) · TLS 1.3 · Session-TTL ≤ 60 Min

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 Transportsicherheit wird über TLS 1.3 erzwungen. Autorisierte Sitzungs-Tokens im Partner-Bereich sind flüchtig und verfallen nach maximal 60 Minuten (hartes Invalidate).

Datenbank-Isolation & Datenlebenszyklus

PostgreSQL Row-Level Security (RLS) · Ephemeral Logs · Dead-Tuple-Minimierung

Die logische Datenisolation wird auf Datenbankebene über PostgreSQL Row-Level Security (RLS) erzwungen, gesteuert durch verifizierte Rollen-Variablen pro Request. Technische Verbindungslogs und Transkripte werden unmittelbar nach Gesprächsende oder Timeout explizit gelöscht. Die Server-Infrastruktur ist so konfiguriert (optimierte VACUUM-Intervalle, restriktive Write-Ahead-Log-TTL), dass die Verweildauer von Datenresten (Dead Tuples) auf den physischen Speichermedien auf das technisch unvermeidbare Minimum reduziert wird.

$ Zum Sicherheits-Überblick in einfacher Sprache

→ /sicherheit