fix(2.9.3): Der zweite Faktor war neben der Zeremonie umgehbar

Ergebnis einer beauftragten Sicherheitsbegutachtung. Die WebAuthn-
Zeremonie selbst ist nicht angefasst worden - sie war in Ordnung. Alle
Befunde lagen DANEBEN:

  Ein zweiter Faktor ist nur so stark wie der schwaechste Weg zum Konto,
  und Sitzungen, die aus ihm entstehen, erben seinen Schutz nicht.

KRITISCH
/api/setup/v1/login prueste auf totp_secret - eine Spalte, die kein
Anmeldeweg auswertet - und nicht auf dc_user_credentials. Ein
Administratorpasswort genuegte dort fuer ein setup:install-Token ohne
Hardwarekey. Neu: Konten mit zweitem Faktor abgewiesen, und die
Rollentrennung gilt symmetrisch. Der Docblock behauptete sie seit jeher;
erzwungen hat sie nichts.

HOCH
secondFactorRequired(), accountLockoutSeconds() und lockoutSeconds()
fingen jedes Throwable und fielen auf "kein Faktor" bzw. "nicht
gesperrt" zurueck. Gefangen wurden damit auch Verbindungsabbrueche und
Lock-Timeouts - jeder davon schaltete still fuer alle Konten auf
Passwort-allein. Toleriert werden jetzt nur noch 42S02 und 42S22.

HOCH
Fuenf Aktionen aenderten die Anmeldemittel ohne erneute Bestaetigung.
Eine uebernommene Sitzung konnte sich damit dauerhaft einnisten. Neu:
Authentifizierung aus den letzten zehn Minuten noetig, geprueft an
derselben Stelle, an der auch der Leerlauf sperrt.

WEITER
- Leerlauf 30 statt 120 Minuten, und GESPERRT statt beendet: AAL2 laesst
  zur Reaktivierung einen Faktor genuegen. Wer alle 30 Minuten den
  Hardwarekey vorzeigen muss, laesst ihn stecken.
- Migration 022: session_epoch. Ein Passwortwechsel beendet die uebrigen
  Sitzungen des Kontos, die eigene bleibt.
- Kontosperre wirkt auf der zweiten Stufe; Zaehler gegen unbegrenztes
  Raten im Zwischenzustand.
- Drosselung auf login.php (10/60s) und /api/auth/v1/ (30/60s).
- Anmeldefehler ununterscheidbar; die IP-Sperre darf benannt bleiben,
  sie sagt nichts ueber ein Konto.
- HSTS, TLS-Zwang VOR allen Routen, CSP. Die CSP traegt wegen 93
  Inline-Handlern nicht gegen XSS - das steht so im Kommentar.
- session.use_strict_mode, CSRF-Token bei der Anmeldung verworfen,
  Secure-Flag aus app.url statt aus $_SERVER['HTTPS'].
- rpId/expectedOrigin nicht mehr aus dem Host-Header. /api/health meldet
  unter checks.webauthn_anchor, ob der Anker steht.
- Notfalltoken laeuft nach 180 Tagen ab, geprueft nach dem Hashvergleich.
- config.example.php ohne echtes Passwort, verify_ssl auf true.
- Serverdaten.txt.bak mitgesperrt, dc_login_attempts raeumt auf.

BELEGT
188 von 188 Testfaellen gruen, darunter drei neue in der Gruppe
"haertung". Die Blockade einer veralteten Sitzung liess sich nicht in
der Suite pruefen - sie verlangt, das Zehn-Minuten-Fenster wirklich
abzuwarten. Dafuer gibt es ein Werkzeug ausserhalb; es belegt, dass der
Formularweg auf den Sperrbildschirm fuehrt, die Regel dabei unveraendert
bleibt, der JSON-Weg reauth_required meldet und das Passwort allein
wieder oeffnet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

tests/e2e/suite_dienste.py

@@ -418,11 +418,25 @@ def _(ctx):
 # Erstinstallation
 # ---------------------------------------------------------------------------
 
+def _installer(ctx):
+    """Zugangsdaten des Installationskontos, oder ueberspringen."""
+    konto = ctx.get('installer')
+    if not konto or not konto.get('username'):
+        ueberspringen('Kein Installationskonto - Lauf ohne --reset oder vor Migration 012.')
+    return konto
+
+
 @test('setup', 'Anmeldung liefert ein kurzlebiges Token')
 def _(ctx):
+    """
+    Bewusst mit dem INSTALLATIONSKONTO, nicht mit dem Administrator. Bis
+    2.9.3 nahm dieser Endpunkt jedes Konto an, und dieser Testfall bildete
+    das ab - er pruefte damit einen Weg, den es nicht geben sollte.
+    """
+    konto = _installer(ctx)
     r = ctx.client.post('/api/setup/v1/login', token=None, body={
-        'username': ctx.cfg['admin']['user'],
-        'password': ctx.cfg['admin']['pass'],
+        'username': konto['username'],
+        'password': konto['password'],
         'hostname': MASCHINE,
     })
     erwarte_erfolg(r)
@@ -445,10 +459,30 @@ def _(ctx):
             "Unerwartete Rechte am Setup-Token: %s" % scopes)
 
 
+@test('setup', 'Ein Administratorkonto kommt hier nicht herein')
+def _(ctx):
+    """
+    Die Rollentrennung gilt seit 2.9.3 in beide Richtungen: Installer nicht
+    ins WebUI, Administratoren nicht in die Setup-API. Wer auf jedem
+    Zielsystem sein Administratorpasswort eingibt, verteilt den Zugang zur
+    gesamten Verwaltung - und bis 2.9.3 bekam er dafuer auch noch ein Token,
+    ohne den hinterlegten Hardwarekey vorzeigen zu muessen.
+    """
+    r = ctx.client.post('/api/setup/v1/login', token=None, body={
+        'username': ctx.cfg['admin']['user'],
+        'password': ctx.cfg['admin']['pass'],
+        'hostname': MASCHINE,
+    })
+    erwarte_status(r, 403)
+    erwarte(r.fehlercode in ('installer_account_required', 'second_factor_required'),
+            'Erwartet wurde eine Ablehnung wegen Rolle oder zweitem Faktor, kam: %s' % r.kurz(300))
+
+
 @test('setup', 'Anmeldung mit falschem Passwort abgewiesen')
 def _(ctx):
+    konto = _installer(ctx)
     r = ctx.client.post('/api/setup/v1/login', token=None, body={
-        'username': ctx.cfg['admin']['user'], 'password': 'garantiert-falsch',
+        'username': konto['username'], 'password': 'garantiert-falsch',
     })
     erwarte_fehler(r, http=(401, 429), code=['invalid_credentials', 'locked_out'])