Version 0.1.0-dev18
Basis: **0.1.0-dev17**, sämtliche bisherigen Dateien bleiben erhalten. Neue Datei: `lib/security-hardening.php`.
- ## Authentifizierung
- Loginversuche werden **serverseitig in SQLite** für normalisierte, HMAC-geschützte Account-Kennung und Remote-IP registriert. Voreinstellung: acht erfolglose Versuche pro Account beziehungsweise 40 pro IP in 15 Minuten; 15-minütige Sperre. Der Account-Zähler wird bei erfolgreicher Passwortprüfung gelöscht, der gemeinsame IP-Zähler nicht. CAPTCHA bleibt separat adaptiv (standardmäßig ab drei Fehlschlägen); Voraussetzung: funktionierende CW-Frontend-CAPTCHA-Bridge.
- Gemeinsame Login-Logik für `/account/login` und externe Module wie MediPlan; keine separaten Passwortbestände.
- „Eingeloggt bleiben“ (maximal 30 Tage) speichert **keine Passwörter**. Es verwendet ein `Secure`, `HttpOnly`, `SameSite=Lax`, hostgebundenes Cookie `__Host-cw_customers_remember` mit zufälligem Selector und Verifier. In SQLite liegt ausschließlich dessen SHA-256-Prüfsumme. Beim Wiederanmelden wird der Verifier atomar rotiert. Kein Ausstellen über HTTP.
- Abmelden widerruft den aktuellen Dauertoken; Passwortänderung und Passwortreset widerrufen **alle** Dauertokens des Kontos. Deaktivierte/gesperrte Konten sind nicht wiederherstellbar, selbst wenn ein Cookie existiert. E-Mail-Änderung widerruft Dauerlogins. Abschalten der Funktion in den Einstellungen entfernt alle Dauerlogins.
- Eine optionale 2FA-Challenge bleibt vorgeschaltet: Der Dauertoken wird erst von `cw_customers_login_session()` **nach** erfolgreichem 2FA-Abschluss ausgestellt. Fehlt ein gültiges Challenge-Weiterleitungsziel, erfolgt **kein** Login. Der 2FA-Adapter muss seine Verifizierung abschließend mit `cw_customers_login_session()` beenden; andere Integrationen erfordern Anpassung.
- Checkbox ist standardmäßig **nicht** aktiviert. Passwortspeicherung kann nur der Browser/Passwortmanager übernehmen; CW speichert dafür keine Zugangsdaten.
- ## Installation und Sicherheit
- 1. Vor dem Update `project/storage/customers/` vollständig sichern (einschließlich WAL/SHM bei SQLite).
- 2. Customers **vor** MediPlan aktualisieren. Danach Customers im CW Backend aktivieren / aufrufen, damit die Migration der Tabellen `frontend_login_limits` und `frontend_remember_tokens` ausgeführt wird.
- 3. In CW Customers → Einstellungen CAPTCHAs prüfen, Limits und Erinnerungsdauer konfigurieren; empfohlen Login-CAPTCHA adaptiv, Registrierung immer. Funktioniert die CAPTCHA-Bridge nicht, muss sie zuerst repariert werden.
- 4. Auf dem **HTTPS-Host** echte Loginversuche testen, anschließend gesperrte Anmeldungen, 2FA, Passwortwechsel, Logout, Cookies mit Browser-Devtools kontrollieren.
- 5. Separater PHP-/SQLite-Test: `php tests/security-hardening.php`. Dieser Test arbeitet mit einer In-Memory-Datenbank und verändert keine echten Konten.
- *Bekannte Grenzen:** Keine Produktions-/Hosting-Tests in der Buildumgebung (`pdo_sqlite` ist dort nicht installiert). Dieser Release fügt keine vollständige Verwaltung einzelner Geräte im Profil hinzu. Bestehende bereits eingeloggte PHP-Sitzungen anderer Geräte werden bei Passwortwechsel weiterhin bis zu ihrem regulären Ablauf akzeptiert; **nur Dauerlogin-Tokens** werden widerrufen. Für sensibles Hosting sollten Sitzungslaufzeiten, WAF, TLS, HTTPS-Redirect und Zugriffsverbote auf `/project/stor
CW ≥ 3.0.0-beta11.9 PHP ≥ 8.3.0
