Login-Versuche begrenzen (Schutz gegen Passwort-Raten) #151

New issue

Open

opened 2026-10-25 08:33:49 +00:00 by claude · 0 comments

claude commented

2026-10-25 08:33:49 +00:00

Collaborator

Die Zahl der Login-Versuche ist nirgends begrenzt. Wer einen Benutzernamen kennt, kann über POST /api/auth-tokens beliebig oft Passwörter durchprobieren.

Stand (25.10.2026, main 67413ac), am Code geprüft:

Backend: AuthResource.login (AuthResource.java:47-68) zählt keine Fehlversuche und sperrt nicht. Fehlversuche werden nur geloggt, mit Benutzernamen (:57, :62).
Caddy: Caddyfile.prod leitet /api/* auf registration., content. und der Hauptdomain ans Backend, ohne Begrenzung. Das Caddy-Image (caddy/Dockerfile) enthält nur die DNS-Module, kein Modul zur Begrenzung.
Bremse heute: nur bcrypt (PasswordService.java:8), also die Rechenzeit pro Prüfung.
In älteren Notizen steht „Rate-Limiting vor Prod nachziehen“, aber für den öffentlichen Weg der KI-Resultaterfassung (docs/offene-punkte-2026-07-31.md:112), nicht für den Login.

Warum jetzt: Bevor Spielleiter und Captains in Produktion arbeiten, schützt ein Passwort Vereinsdaten und Personendaten (Adressen, Telefonnummern).

Mögliche Wege (zu entscheiden):

Caddy-Modul zur Begrenzung (z.B. caddy-ratelimit per xcaddy): Begrenzung je IP auf /api/auth-tokens. Ohne Code im Backend, aber ein eigenes Modul im Image.
Zähler im Backend: nach n Fehlversuchen je Benutzer eine kurze Sperre (z.B. Minuten), Antwort 429. Prüfbar mit Tests, schützt auch vor verteilten Versuchen auf einen Benutzer.
fail2ban auf dem Server, das die Log-Zeilen „Login fehlgeschlagen“ auswertet und IPs sperrt. Ohne Code, aber Betrieb je Server (IONOS, Hetzner, Staging).

Kombinationen sind möglich, z.B. 1 gegen Masse je IP und 2 gegen gezieltes Raten auf einen Benutzer.

Gefunden im Gespräch zur URL-Neuordnung, Etappe 5a (25.10.2026).

Die Zahl der Login-Versuche ist nirgends begrenzt. Wer einen Benutzernamen kennt, kann über `POST /api/auth-tokens` beliebig oft Passwörter durchprobieren. **Stand (25.10.2026, `main` `67413ac`), am Code geprüft:** - **Backend:** `AuthResource.login` (`AuthResource.java:47-68`) zählt keine Fehlversuche und sperrt nicht. Fehlversuche werden nur geloggt, mit Benutzernamen (`:57`, `:62`). - **Caddy:** `Caddyfile.prod` leitet `/api/*` auf `registration.`, `content.` und der Hauptdomain ans Backend, ohne Begrenzung. Das Caddy-Image (`caddy/Dockerfile`) enthält nur die DNS-Module, kein Modul zur Begrenzung. - **Bremse heute:** nur bcrypt (`PasswordService.java:8`), also die Rechenzeit pro Prüfung. - In älteren Notizen steht „Rate-Limiting vor Prod nachziehen“, aber für den öffentlichen Weg der KI-Resultaterfassung (`docs/offene-punkte-2026-07-31.md:112`), nicht für den Login. **Warum jetzt:** Bevor Spielleiter und Captains in Produktion arbeiten, schützt ein Passwort Vereinsdaten und Personendaten (Adressen, Telefonnummern). **Mögliche Wege (zu entscheiden):** 1. **Caddy-Modul zur Begrenzung** (z.B. `caddy-ratelimit` per `xcaddy`): Begrenzung je IP auf `/api/auth-tokens`. Ohne Code im Backend, aber ein eigenes Modul im Image. 2. **Zähler im Backend:** nach n Fehlversuchen je Benutzer eine kurze Sperre (z.B. Minuten), Antwort `429`. Prüfbar mit Tests, schützt auch vor verteilten Versuchen auf einen Benutzer. 3. **fail2ban auf dem Server**, das die Log-Zeilen „Login fehlgeschlagen“ auswertet und IPs sperrt. Ohne Code, aber Betrieb je Server (IONOS, Hetzner, Staging). Kombinationen sind möglich, z.B. 1 gegen Masse je IP und 2 gegen gezieltes Raten auf einen Benutzer. Gefunden im Gespräch zur URL-Neuordnung, Etappe 5a (25.10.2026).