added security settings

changed fixes and issues

docs/fixes-todo.md

@@ -46,6 +46,11 @@ Sortiert nach Risikoklasse. Datei-/Zeilenreferenzen beziehen sich auf den Stand
 - [x] **8. Bearer-Token aus Frontend-`localStorage` entfernen** ✅ erledigt
   - `frontend/src/api.js` — nur noch Cookie-Auth (`withCredentials: true`). `localStorage`-Token und `VITE_API_TOKEN` entfernt.
 
+- [x] **45. Secrets in `GET /settings` maskieren (Write-only)** ✅ erledigt
+  - Datei: `agent/src/config.js` (`readEnvSettings`/`writeEnvSettings`), `frontend/src/components/Settings.jsx`
+  - Problem: `readEnvSettings` gab den Wert *aller* Felder zurück — inkl. `RESTIC_PASSWORD`, `AWS_SECRET_ACCESS_KEY`, `API_TOKEN`. Über den Management-Proxy konnte damit jeder eingeloggte UI-User das Restic-Verschlüsselungspasswort und die S3-Credentials enthüllen (= alle Backups entschlüsseln und löschen).
+  - Fix: Secret-Felder liefern beim Lesen keinen Wert mehr, nur `hasValue: true|false`. Beim Schreiben gilt ein leeres Secret-Feld als „unverändert" (bestehender Wert bleibt erhalten). Frontend zeigt Platzhalter „gesetzt – leer lassen zum Beibehalten".
+
 ---
 
 ## 🟠 Hoch
@@ -88,6 +93,21 @@ Sortiert nach Risikoklasse. Datei-/Zeilenreferenzen beziehen sich auf den Stand
   - Datei: `agent/src/routes/settings.js`
   - Hängt mit Fix #2 zusammen — nach #2 automatisch erfüllt, hier zur Sicherheit dokumentieren/testen.
 
+- [x] **46. Agent-Token-Vergleich timing-safe machen** ✅ erledigt
+  - Datei: `agent/src/index.js:28`
+  - Problem: `header === \`Bearer ${config.apiToken}\`` — normaler String-Vergleich am root-Agent (das wertvollste Ziel), während das Login-Passwort bereits `timingSafeEqual` nutzte.
+  - Fix: Vergleich über `crypto.timingSafeEqual` mit Längen-Guard. Leerer/fehlender konfigurierter Token verweigert weiterhin (`config.apiToken &&`).
+
+- [ ] **47. Pre-Restore-Volumes aufräumen (Disk-Space-GC)**
+  - Datei: `agent/src/routes/restore.js`
+  - Aktuell: Jeder erfolgreiche Restore behält das alte Volume als `*.pre-restore-*` Rollback-Kopie — es gibt aber keinen Cleanup. Jeder Restore verdoppelt den Plattenbedarf der VM dauerhaft; bei mehreren Restores läuft der ZFS-Pool voll.
+  - Fix: Aufbewahrungsregel (z.B. „keep last N pre-restore/failed-restore Volumes pro VM") oder expliziter Cleanup-Schritt/UI-Aktion. Mindestens im Health/Operations-View sichtbar machen.
+
+- [ ] **48. Agent-Tokens im Management-SQLite nicht im Klartext speichern**
+  - Datei: `management/src/store.js` (`nodes.token`), `management/src/db.js`
+  - Aktuell: `nodes.token` liegt im Klartext in der Management-DB. DB-Diebstahl = alle Agent-Tokens = root auf allen Hosts.
+  - Fix: Verschlüsselung at-rest mit einem Management-Key (z.B. aus `SESSION_SECRET`/dediziertem Key abgeleitet), oder zumindest DB-Dateipermissions/Disk-Encryption-Anforderung im Deployment-Doc verbindlich dokumentieren.
+
 ---
 
 ## 🟡 Mittel
@@ -142,6 +162,11 @@ Sortiert nach Risikoklasse. Datei-/Zeilenreferenzen beziehen sich auf den Stand
 - [ ] **28. Pre-Backup VM-Zustand prüfen**
   - Live-Migration, laufende interne Snapshots, fehlende Berechtigungen → klare Fehler statt halb durchgeführter Pipeline.
 
+- [ ] **49. Abgelaufene Sessions serverseitig löschen + Rotation**
+  - Datei: `management/src/store.js:12` (`getUserBySession`), `createSession`
+  - Aktuell: Abgelaufene Sessions werden beim Lesen nur gefiltert, nie aus der DB entfernt → unbegrenztes Tabellenwachstum. Außerdem keine Session-Rotation nach erfolgreichem Login.
+  - Fix: Periodischer Cleanup (`DELETE FROM sessions WHERE expires_at <= now`) und neue Session-ID nach Login ausstellen.
+
 ---
 
 ## 🟢 Niedrig / Aufräumen
@@ -187,11 +212,17 @@ Sortiert nach Risikoklasse. Datei-/Zeilenreferenzen beziehen sich auf den Stand
 | 7 | Backup-Verifikation | ⬜ offen |
 | 8 | Bearer-Token aus localStorage | ✅ erledigt |
 | 9 | Session-Cookie `Secure`-Flag | ⚠️ teilweise |
+| 45 | Secrets in `GET /settings` maskieren | ✅ erledigt |
+| 46 | Agent-Token-Vergleich timing-safe | ✅ erledigt |
+| 47 | Pre-Restore-Volume-GC | ⬜ offen |
+| 48 | Agent-Tokens in DB verschlüsseln | ⬜ offen |
+| 49 | Session-Cleanup serverseitig | ⬜ offen |
 
 ## Nächste Prioritäten
 
 1. **#7** Backup-Verifikation weiter härten — Pipeline-/Stream-Fehler testen und vollständiger absichern.
-2. **#9** `SESSION_COOKIE_SECURE=true` in Deployment-Doku festschreiben.
-3. **#12** Toten `SESSION_SECRET` entfernen.
-4. **#15** ENV-Escaping vervollständigen (`$`, Backticks, Newlines).
-5. **#11 Folgearbeit** ressourcenspezifische Cleanup-Recovery nach Agent-Crash definieren.
+2. **#47** Pre-Restore-Volume-GC — sonst läuft der ZFS-Pool bei wiederholten Restores voll.
+3. **#9** `SESSION_COOKIE_SECURE=true` in Deployment-Doku festschreiben.
+4. **#12** Toten `SESSION_SECRET` entfernen.
+5. **#15** ENV-Escaping vervollständigen (`$`, Backticks, Newlines).
+6. **#11 Folgearbeit** ressourcenspezifische Cleanup-Recovery nach Agent-Crash definieren.