Sicherheit

Passwortspeicherung

Passwörter werden mit bcrypt (Cost Factor 12) gehasht gespeichert. Klartext-Passwörter werden nie gespeichert, auch nicht vorübergehend im Serverspeicher — sie werden sofort nach dem Hashing verworfen. Bei der Registrierung werden Passwörter über die Have I Been Pwned API auf bekannte Datenlecks geprüft, und kompromittierte Passwörter werden abgelehnt.

Tokens und Sitzungen

Authentifizierungstokens sind JWTs, die mit dem HS256-Algorithmus signiert werden. In der Produktionsumgebung ist ein JWT-Secret von mindestens 32 Zeichen erforderlich — der Server startet ohne dieses nicht.

Refresh-Tokens werden vor der Speicherung mit bcrypt (Cost Factor 10) gehasht. Refresh-Tokens werden bei jeder Verwendung rotiert — jede Aktualisierung gibt ein neues Token aus und invalidiert das vorherige. Die TTLs beider Token sind pro Projekt konfigurierbar.

Sitzungen werden serverseitig verwaltet mit IP-Adresse, User Agent und Zeitstempel der letzten Aktivität. Benutzer können aktive Sitzungen einsehen und einzelne oder alle Sitzungen über das Dashboard widerrufen.

Multi-Faktor-Authentifizierung

TOTP-basierte Multi-Faktor-Authentifizierung wird unterstützt. TOTP-Secrets werden vor der Speicherung mit AES verschlüsselt. Pro Benutzer werden 10 Backup-Codes generiert, jeweils mit HMAC-SHA256 gehasht. Die Verifizierung von Backup-Codes verwendet Constant-Time-Vergleich zur Vermeidung von Timing-Angriffen.

OAuth und Social Login

OAuth-State-Parameter werden mit crypto.randomBytes(32) generiert, um CSRF-Angriffe zu verhindern. 20 OAuth-Anbieter werden unterstützt, und Callback-URLs sind pro Projekt eingeschränkt.

Passkeys (WebAuthn)

Passkey-Authentifizierung basiert auf dem FIDO2/WebAuthn-Standard. Die serverseitige Verifizierung verwendet die SimpleWebAuthn-Bibliothek.

Netzwerksicherheit

Jegliche Kommunikation wird über TLS verschlüsselt. HSTS (HTTP Strict Transport Security) wird mit einem Max-Age von 1 Jahr erzwungen.

CORS ist mit einer dynamischen Whitelist konfiguriert, die nur für jedes Projekt registrierte Domains zulässt. Wildcard-Origins werden nicht verwendet.

Der API-Server verwendet die Helmet-Middleware zur Konfiguration von Sicherheitsheadern einschließlich Content-Security-Policy, X-Frame-Options (DENY) und X-Content-Type-Options (nosniff).

Brute-Force-Schutz

Fehlgeschlagene Anmeldeversuche werden pro Benutzer erfasst. Standardmäßig werden Konten nach 5 Fehlversuchen für 300 Sekunden (5 Minuten) gesperrt. Diese Schwellenwerte sind in den Sicherheitseinstellungen jedes Projekts konfigurierbar. Eine erfolgreiche Anmeldung setzt den Fehlzähler zurück.

Cloudflare Turnstile CAPTCHA kann pro Projekt aktiviert werden und fügt Bot-Schutz-Herausforderungen zu Registrierungs- und Anmeldeabläufen hinzu.

Eingabevalidierung

Alle API-Eingaben werden mit class-validator validiert. Nicht erkannte Felder werden automatisch entfernt (Whitelist-Modus), und Anfragen mit explizit verbotenen Feldern werden abgelehnt. Passwörter erfordern mindestens 8 Zeichen. Datenbankabfragen verwenden parametrisierte TypeORM-Abfragen zur Verhinderung von SQL-Injection.

Webhook-Sicherheit

Jedem Webhook-Endpunkt wird bei der Erstellung ein eindeutiges Signing-Secret zugewiesen. Webhook-Payloads werden mit HMAC-SHA256 signiert und mit einem Zeitstempel im X-Authon-Signature-Header übermittelt. Fehlgeschlagene Zustellungen werden automatisch bis zu 3 Mal wiederholt.

Schwachstellen melden

Wenn Sie eine Sicherheitslücke entdecken, melden Sie diese bitte an security@authon.dev. Eröffnen Sie kein öffentliches Issue — kontaktieren Sie uns direkt per E-Mail.