root@bissolux:~/blog/security-architektur$_
[cd ..]
DATE: 2026-02-18CATEGORY: SECURITY-ARCHITEKTUR

>Sicheren MFA-Login-Flow für Enterprise-SaaS designen (ohne Passwort-Validität zu leaken)

Ein gehärtetes Authentifizierungsmuster für ERP- und Fintech-nahe Systeme: immer eine MFA-Challenge ausgeben, um Angreifer-Feedback zu reduzieren.

In einem ERP-SaaS für Buchhaltung ist Authentifizierung nicht nur ein Feature — sie ist eine Angriffsfläche.

Jeder Login-Endpunkt im Internet kann angegriffen werden. Die praktische Frage ist: Wie viel Feedback gibst du Angreifern pro Versuch?

TL;DR_SUMMARY
  • >Nach der Passwort-Eingabe immer eine MFA-Challenge zurückgeben.
  • >password_valid nur serverseitig im Challenge-State speichern.
  • >Session nur ausstellen, wenn Passwort und MFA beide gültig sind.
  • >Reduziert Feedback-Leaks, ersetzt aber keine Abuse-Controls.

SCHNELLÜBERSICHT

1. Standard-MFA-Flow und wo er Informationen leakt
2. Gehärteter Flow mit einheitlicher Challenge-Antwort
3. Erforderliche Controls zusätzlich zu MFA
4. Implementierungs-Checkliste und Tradeoffs

Standard-2-Stufen-MFA-Flow (üblich)

SCHRITT_1_PASSWORT

POST /login
email + password

Typisches Verhalten: korrektes Passwort liefert MFA-Challenge, falsches Passwort liefert Fehler.

SCHRITT_2_MFA

POST /login/mfa
challenge_id + mfa_code

Bei gültigem Code wird eine Session ausgestellt.

Warum das Informationen leakt

Unterschiedliche Backend-Reaktionen in Schritt 1 liefern Angreifern Signal. Selbst mit generischen Fehlermeldungen lassen sich Zustand und Passwort-Validität oft über Timing, Struktur oder Folgeverhalten ableiten.

Feedback ist eine Angriffsfläche.

Gehärtetes Muster: Immer Challenge zurückgeben

LEAKY

Falsches Passwort -> ablehnen
Korrektes Passwort -> Challenge

HARDENED

Passwort gesendet -> immer Challenge

Schritt 1 — Login-Endpunkt

POST /login
email + password

SERVER_AKTIONEN

  1. Request rate-limiten.
  2. Passwort prüfen.
  3. Kurzlebige MFA-Challenge erzeugen.
  4. Challenge-State inkl. Passwort-Validität speichern.

CHALLENGE_STATE

challenge_id
user_id
password_valid
expires_at
attempt_counter

EINHEITLICHE_ANTWORT

{
  status: "CHALLENGE",
  challenge_id: "uuid"
}

Schritt 2 — MFA-Verifikation

POST /login/mfa
challenge_id + mfa_code

VERIFIKATIONS_GATE

  1. Challenge existiert und ist nicht abgelaufen.
  2. Versuchslimit wurde nicht überschritten.
  3. MFA-Code ist gültig.
  4. password_valid ist true.

Session nur ausstellen, wenn alle Prüfungen bestehen. Sonst generischer Fehler.

Was sich verbessert

1) Kein klares Passwort-Validitäts-Feedback

Angreifer können falsch vs. korrekt in Schritt 1 nicht zuverlässig unterscheiden.

2) Schlechteres Feedback für Credential Stuffing

Einheitliche Antworten verschlechtern automatisierte Entscheidungslogik.

3) Weniger Timing-/State-Leaks

Konsistentes Verhalten reduziert verwertbare Side-Channel-Unterschiede.

4) Stärkere Enterprise-Sicherheitslage

Passend für ERP/Fintech-nahe Systeme mit Finanz- und Payroll-Daten.

Was das NICHT löst

WEITERHIN_ERFORDERLICHE_CONTROLS
  • IP-basierte Rate Limits
  • Account-basierte Rate Limits
  • Progressive Delays
  • Temporäre Lockouts
  • MFA-Versuchslimits
  • Audit-Logging und Monitoring

Warum MFA allein kein Brute-Force-Schutz ist

Es gibt zwei getrennte Brute-Force-Flächen, die jeweils abgesichert werden müssen:

  • Passwort-Endpunkt
  • MFA-Endpunkt

MFA reduziert den Schaden bei geleakten Zugangsdaten, stoppt aber kein Online-Guessing von allein.

Implementierungs-Checkliste

1. Passwort-Validität in der Challenge persistieren

Verhindert versehentlichen Passwort-Bypass im MFA-Schritt.

2. Kurze Challenge-TTL

Ziel: 2–5 Minuten.

3. MFA-Versuche pro Challenge begrenzen

Beispiel: max. 5, danach invalidieren.

4. Vor Hash-Verifikation rate-limiten

Schützt CPU vor bcrypt/argon2-Exhaustion-Angriffen.

5. Verarbeitung so konstant wie praktikabel halten

Aussagekräftige Timing-Unterschiede zwischen Pfaden vermeiden.

Tradeoffs

Vorteile

  • + Höhere Resistenz gegen Auth-State-Leaks
  • + Weniger verwertbares Signal für Credential Stuffing
  • + Einheitlicheres Login-Verhalten
  • + Gute Eignung für Systeme mit hohem Schutzbedarf

Nachteile

  • - Höhere Implementierungs-Komplexität
  • - Zusätzlicher Storage für Challenge-State
  • - Strengeres Lifecycle-/State-Handling
  • - Weiterhin abhängig von starken Abuse-Controls

Enterprise-Perspektive

Viele Finanzplattformen antworten bewusst generisch, etwa mit "Zusätzliche Verifikation erforderlich", unabhängig davon, ob das Passwort korrekt war.

Wenn dein SaaS Payroll-, Steuer-, Buchhaltungs- und bankrelevante Daten verarbeitet, ist diese defensive Haltung absolut sinnvoll.

Finale Architektur (kompakt)

1. Rate limit request
2. Passwort verifizieren
3. Immer Challenge erstellen
4. password_valid intern speichern
5. MFA + Challenge-Regeln prüfen
6. Session nur bei beiden gültig ausstellen
7. Alle Auth-Events loggen und monitoren

Fazit

Security ist immer mehrschichtig. MFA ist wichtig, aber kein Brute-Force-Schutz für sich allein.

Passwort-Validitäts-Leaks über einheitliche Challenge-Antworten zu reduzieren ist ein reifes, gut begründbares Upgrade für Enterprise-SaaS.

Nicht das Token ist die Sicherheit — die Schichten sind es.

NÄCHSTE_POST_IDEEN
  • • Redis-basierter MFA-Challenge-Store in Go
  • • Risk-Based Authentication für ERP-Systeme
  • • Warum MFA kein Brute-Force-Schutz ist
IMPORTANT

Dieses Muster verbessert die Resistenz gegen Informationslecks, funktioniert aber nur als eine Schicht in einer vollständigen Anti-Abuse-Architektur.

END_OF_FILE