Security-Hardening Runde 17: JWT-TTL + Pentest-Marker-Detection

Pentest Runde 17:

21.1 Access-Token TTL war 7 Tage statt 15min:
docker-compose.yml und .env.example standen schon richtig auf 15m
als Default. Die alten Beispiel-.env-Files (backend/.env.example,
docker/.env.example) hatten noch die alte Konvention "7d". Beide
auf 15m korrigiert + explizites JWT_REFRESH_EXPIRES_IN=7d ergänzt.
Auf prod muss die echte .env entsprechend angepasst werden.

17.5 Alte Pentest-Daten in DB:
Cleanup-Script erweitert um Pentest-Marker-Erkennung:
- Email-Pattern: ^hacker@, ^attacker@, ^pentest@, @evil\.
- XSS-Marker: <script, onerror=, javascript:
- Sonstige: SQL-Injection, Path-Traversal

Bewusst eng gefasst (Marker MUSS am Email-Anfang stehen), damit
legitime Kunden wie "stefanhacker@gmx.de" nicht als Pentest-Daten
durchgehen.

Default: nur warnen + Records auflisten. Opt-In via
CLEANUP_PURGE_PENTEST=true löscht die markierten Customer/User.

Live-verifiziert:
- stefanhacker@gmx.de (echt) → durchgelassen
- hacker@evil.de (Pentest) → erkannt + Warnung
- Mit Purge-Env → gelöscht

18.4 Klartext-Portal-PW-Abruf:
Bewusst drin gelassen (Admin-UI-Komfort). Endpoint ist mit
customers:update-Permission gated + Audit-Log (READ →
PortalPassword) – kein Bypass-Risiko, nur explizite Audit-Pflicht.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/todo.md

@@ -97,6 +97,39 @@ isolierte Instanz (keine Multi-Tenancy im Code), Provisioning + Abrechnung
 
 ## ✅ Erledigt
 
+- [x] **🚨 Pentest Runde 17 – JWT-TTL + Pentest-Marker-Detection**
+  - **21.1 Access-Token 7 Tage**: Bug-Quelle waren die `.env`-Files,
+    die noch die alte Konvention vor der Refresh-Token-Trennung
+    hatten (`JWT_EXPIRES_IN=7d`). docker-compose.yml und
+    `.env.example` standen schon richtig auf 15m als Default.
+    Alle `.env`-Files (Root, backend/, docker/.env.example,
+    backend/.env.example) jetzt auf `JWT_EXPIRES_IN=15m` mit
+    explizitem `JWT_REFRESH_EXPIRES_IN=7d`. Auf prod kann der
+    Container mit dem neuen Default neu hochgezogen werden.
+  - **17.5 Alte Pentest-Daten in DB**: das Cleanup-Script läuft
+    schon bei jedem Container-Start, strippt HTML aus Customer/
+    User-Strings und entfernt nicht-whitelisted AppSettings. Es
+    erkannte aber keine Test-Records ohne HTML (z.B. Customer mit
+    `email: hacker@evil.de`). Erweiterung:
+    * Neue Marker-Pattern-Liste: `^hacker@`, `^attacker@`,
+      `^pentest@`, `@evil\.`, `<script\b`, `onerror=`,
+      `javascript:`, SQL-Injection + Path-Traversal-Pattern.
+    * Bewusst eng: nur EMail-Adressen die mit dem Marker BEGINNEN,
+      damit legitime Kunden mit "hacker" o.ä. im Nachnamen
+      (z.B. `stefanhacker@gmx.de`) NICHT als Pentest-Marker
+      durchgehen.
+    * Default-Verhalten: nur warnen + Aufzählen. Mit
+      `CLEANUP_PURGE_PENTEST=true`-ENV werden die markierten
+      Customer/User-Records gelöscht.
+    * Live-verifiziert: `stefanhacker@gmx.de` (echt) → durch;
+      `hacker@evil.de` (Test) → erkannt + Warnung; mit Purge-Env
+      → gelöscht.
+  - **18.4 Klartext-Portal-PW-Abruf**: BEWUSST DRIN GELASSEN auf
+    Wunsch (Admin-UI-Komfort). Klartext bleibt für Admin via
+    `GET /customers/:id/portal/password` abrufbar; ist mit
+    `customers:update`-Permission gated und mit Audit-Log
+    (`READ → PortalPassword`) auditiert.
+
 - [x] **🚨 Pentest Runde 15 – KRITISCH: portalPasswordHash in PUT/POST-Response**
   - **20.3 KRITISCH**: `PUT /customers/:id` gab den vollen bcrypt-Hash
     (`$2a$12$…`) zurück, weil `updateCustomer` Service-Output ohne