Gebaut für das Quantenzeitalter
UniAuth ist von Grund auf mit Sicherheit als Standard konzipiert — nicht nachträglich aufgesetzt. Jeder Hash, jedes Token, jede Sitzung ist mit Kryptografie geschützt, die sowohl heutigen als auch künftigen Angriffen standhält.
Kryptografische Grundlagen
AES-256-GCM-Verschlüsselung im Ruhezustand
Jeder sensible Wert — TOTP-Geheimnisse, OAuth-Zugriffstokens, private PQC-Schlüssel, LDAP-Bind-Passwörter — wird mit AES-256-GCM verschlüsselt, bevor er die Datenbank berührt. Format: iv:tag:ciphertext.
Der Verschlüsselungsschlüssel ist ein separates 256-Bit-Geheimnis (ENCRYPTION_KEY), nicht vom JWT-Secret abgeleitet. Die Rotation des einen kompromittiert das andere nicht.
ML-DSA-44-Sitzungssignaturen
Jede Sitzung trägt eine post-quantum-digitale Signatur (FIPS 204 ML-DSA-44, ehemals CRYSTALS-Dilithium). Bei jeder Anfrage prüft touchSession() die Signatur; eine Abweichung widerruft die Sitzung sofort und protokolliert das Ereignis.
Selbst wenn eine klassische ECDSA- oder RSA-Signatur von einem Quantencomputer gebrochen würde, bleiben ML-DSA-Sitzungen sicher.
Argon2id-Passwort-Hashing
Neue Passwörter verwenden Argon2id (OWASP-empfohlen: 64 MB Speicher, 3 Iterationen, 4 Parallelität). Ältere bcrypt-Hashes werden bei der Anmeldung transparent migriert. Die Passwortstärke wird mit zxcvbn bewertet (Score ≥ 2 erforderlich) und über die k-anonymity-API von HaveIBeenPwned geprüft.
Paarweise Subjektkennungen
Verbundene Apps sehen niemals Ihre echte UUID. Jede App erhält eine eindeutige, deterministische, app-spezifische Kennung: HMAC-SHA256(userId:clientId, secret). Apps können Nutzer nicht über Dienste hinweg korrelieren — Ihre Privatsphäre ist strukturell, nicht richtlinienbasiert.
Laufzeitschutz
Adaptive Bedrohungserkennung
Statistische Bewertung des Anmelderisikos über 6 Faktoren: neue IP, neuer User-Agent, ungewöhnliche Uhrzeit, Häufung fehlgeschlagener Versuche, geografische Anomalie und Gerätevertrauen. Anmeldungen mit hohem Risiko lösen automatisch eine verstärkte 2FA oder ein CAPTCHA aus.
Progressive Kontosperrung
5 Fehlversuche = 1 Min., 10 = 5 Min., 15 = 15 Min., 20+ = 1 Stunde. Gibt einen generischen 401 zurück (keine Kontoenumeration). Wird bei erfolgreicher Authentifizierung zurückgesetzt. Die Sperrung gilt gleichermaßen für Passwort-, Passkey- und Magic-Link-Abläufe.
Sitzungslebenszyklus
24-Stunden-Inaktivitäts-Timeout + 30-Tage-Gesamtlebensdauer. Ein SHA-256-Fingerabdruck (IP + UA) wird bei jeder Anfrage geprüft: Ein Wechsel des Clients beendet die Sitzung, während gewöhnliches Netzwerk-Roaming auf demselben Client sie neu bindet. Maximal 10 gleichzeitige Sitzungen pro Nutzer, die älteste wird verdrängt.
SSRF-sichere ausgehende Anfragen
Jede ausgehende HTTP-Anfrage (Webhooks, OIDC-Discovery, Backchannel-Logout) läuft über safeFetch — DNS-aufgelöst, an die validierte IP-Adresse gebunden. DNS-Rebinding zwischen der Prüfung und dem Socket-Connect ist unmöglich.
CORS + CSP + Ratenbegrenzung
Strikte Same-Origin-CORS auf allen API-Routen. CSP mit frame-ancestors 'none'. Zweischichtige Ratenbegrenzung (In-Memory + Redis-Sliding-Window). Schwellenwerte pro Route, abgestimmt auf das Risikoprofil jedes Endpunkts.
Alles in konstanter Zeit
Jeder Hash-Vergleich, jede Token-Prüfung, jede Backup-Code-Prüfung und jede SCIM-Token-Suche verwendet crypto.timingSafeEqual. Keine zeitbasierten Seitenkanäle, nirgendwo.
Compliance & Audit
Jede Aktion wird protokolliert, jede Kette wird verifiziert, jeder Export wird bereinigt.