feat: add admin authenticator 2FA and configurable login email alerts

docs/DEPLOYMENT.md

@@ -33,6 +33,18 @@ App läuft als unprivilegierter Benutzer `node`, PID-1-Verwaltung über `tini`.
 
 Session-Cookie: HTTP-only, SameSite Strict, 7 Tage absolute Gültigkeit, optional Secure. Datenbank enthält ausschließlich den SHA-256-Hash des zufälligen 256-Bit-Tokens. Passwortwechsel widerruft alle bisherigen Sessions. Origin-Prüfung gilt auch für Login und Uploads.
 
+## Admin-2FA und Mail
+
+In `.env` `ADMIN_EMAIL` auf die Admin-Adresse setzen. Mit `openssl rand -hex 32` einen **separaten, dauerhaften** `AUTH_ENCRYPTION_KEY` erzeugen und ebenfalls eintragen. Nach Änderungen `docker compose up -d app` ausführen. Der Schlüssel verschlüsselt Authenticator-Geheimnisse und SMTP-Passwörter mit AES-256-GCM; er darf bei Updates nicht neu erzeugt werden und gehört in das geschützte Konfigurationsbackup. Ohne den ursprünglichen Schlüssel lassen sich vorhandene Geheimnisse nicht entschlüsseln.
+
+Unter **Administration → Einstellungen → Zwei-Faktor-Anmeldung** das aktuelle Passwort eingeben, QR-Code mit einer TOTP-App scannen und den sechsstelligen Code bestätigen. Erst dann wird 2FA aktiviert. Die zehn Wiederherstellungscodes werden nur einmal angezeigt; herunterladen und sicher aufbewahren. Jeder Code ersetzt einmal den App-Code. Neue Codes machen die bisherigen ungültig. Aktivierung, Deaktivierung und Code-Neugenerierung beenden andere Sitzungen. Für sicherheitsrelevante Änderungen werden Passwort und bei aktiver 2FA ein frischer App- oder Wiederherstellungscode benötigt.
+
+Nach der Passwort-Anmeldung gilt die zweite Stufe fünf Minuten und erlaubt höchstens fünf Fehlversuche. App-Codes gelten im 30-Sekunden-Takt mit einer Periode Toleranz und können nur einmal verwendet werden. Server und Smartphone sollten die Uhrzeit automatisch synchronisieren. Bei Verlust des Telefons einen Wiederherstellungscode verwenden; sind beide verloren, kann der Serverbetreiber über das bestehende Admin-CLI einen weiteren Zugang anlegen.
+
+Unter **Mail & Benachrichtigungen** Admin-Adresse, SMTP-Host, Port, TLS-Verfahren, Benutzername, Passwort und Absender hinterlegen. Unterstützt werden implizites TLS (üblicherweise 465) und verpflichtendes STARTTLS (üblicherweise 587). Leeres SMTP-Passwort behält das gespeicherte Passwort bei; zum Löschen dient die eigene Checkbox. Anschließend speichern und **Testmail senden**. Die Option **E-Mail bei erfolgreicher Anmeldung** aktiviert Login-Benachrichtigungen. Ein Versandfehler sperrt die Anmeldung nicht; der Status ist im Loginverlauf sichtbar.
+
+Benachrichtigungen enthalten Zeitpunkt (UTC), gemeldete IP-Adresse und User-Agent, keine geografische Ortung. Ohne `TRUST_PROXY=true` werden Proxy-IP-Angaben ausdrücklich als nicht verifiziert gekennzeichnet. Die rechte Adresse aus `X-Forwarded-For` wird verwendet; die oben beschriebenen Proxy-Voraussetzungen bleiben erforderlich. Der Loginverlauf speichert erfolgreiche Anmeldungen für bis zu 90 Tage (Bereinigung bei der nächsten Anmeldung), angezeigt werden die letzten 20. SMTP-Zugang und 2FA-Geheimnisse werden nicht über die Einstellungs-API zurückgegeben.
+
 ## Backup
 
 Ein konsistentes Backup umfasst Datenbank **und** Bilder. Für ein kleines Haushaltskochbuch ist eine kurze Schreibpause am einfachsten:

docs/VERIFICATION.md

@@ -81,6 +81,15 @@ Nach der gestalterischen Überarbeitung wurden TypeScript-Prüfung und Produktio
 
 Der mobile Überlauf wurde am veröffentlichten Pljeskavica-Rezept reproduziert: lange Bildquellen-URLs in den Tipps vergrößerten die minimale Grid-Spaltenbreite und damit auch die Zutatenliste. Die Spalte verwendet nun `minmax(0, 1fr)`, ihre Kinder dürfen schrumpfen und lange Texte umbrechen. Mit dem echten Rezept und dem korrigierten Stylesheet wurden 320, 360, 390, 430 und 768 Pixel Breite ohne Überlauf geprüft. Produktionsbuild und alle 15 öffentlichen Browserabläufe bestanden. Der Regressionstest enthält eine lange Quellen-URL und vergleicht die Inhaltsbreite mit `document.documentElement.clientWidth`; `innerWidth` kann sich auf mobilen Browsern selbst mit dem Überlauf vergrößern und ist dafür ungeeignet.
 
+### Nachprüfung: Admin-2FA und Mail (25. Oktober 2026)
+
+- Formatprüfung, TypeScript und Produktionsbuild erfolgreich; **55/55 Unit-Tests** bestanden, darunter RFC-6238-Vektoren, Zeitfenster, Replay-Schutz, verschlüsselte Geheimnisse und Wiederherstellungscodes.
+- **6/6 betroffene Browser-/API-Abläufe** gegen eine isolierte PostgreSQL-17-Testdatenbank auf dem Server bestanden. Docker und PostgreSQL auf dem Entwicklungs-Mac blieben ausgeschaltet.
+- Authenticator-Einrichtung per QR-Code, Passwort-/2FA-Stufen, CSRF, Sitzungswiderruf, fünf Fehlversuche, abgelaufene Challenges, gleichzeitige Verwendung desselben Wiederherstellungscodes und Code-Neugenerierung geprüft.
+- Echte SMTP-Zustellung mit TLS und Authentifizierung an einen Testserver; Testmail, Login-Herkunft, Opt-out, Passwortbeibehaltung, Geheimnisverschlüsselung und fehlende Geheimnisse in API-Antworten geprüft. Ein absichtlicher SMTP-Verbindungsfehler verhindert die Anmeldung nicht.
+- Einstellungen auf Desktop und bei 390 Pixel Breite visuell kontrolliert; kein horizontaler Überlauf. Screenshots liegen in den ignorierten Playwright-Artefakten.
+- Die Ziel-Mailbox benötigt noch vom Betreiber eingetragene SMTP-Zugangsdaten. 2FA wird vom Admin persönlich durch Scannen und Codebestätigung aktiviert.
+
 ## Präzise Grenzen
 
 - Kein Test auf physischem Smartphone, Safari oder Firefox; keine tatsächliche iOS-/Android-Installation über das Betriebssystem-Installationsmenü.