Decoupled Security: Den Auth-Flow absichern, ohne die Implementierung anzufassen

Die Integration zusätzlicher Security-Maßnahmen in bestehende Authentifizierungssysteme birgt oftmals operative Risiken. Mit unserem neuen Caddy-Plugin verlagern wir diese Ebene in die Infrastruktur. Ein Belastungstest mit 40.000 Requests demonstriert die Stabilität dieser Architektur.

Für technische Entscheider stellt der Authentifizierungsprozess eine geschäftskritische Komponente dar. Jede Änderung am Code-Fundament erhöht das Risiko von Ausfällen. Bei der Einführung neuer Prüfmechanismen – wie dem Abgleich gegen geleakte Passwörter – entstehen in der Regel Aufwände für Refactoring und das Management neuer Abhängigkeiten im Backend. Eine grundlegende Anforderung bleibt dabei unverhandelbar: Die Latenz oder der Ausfall eines Drittanbieter-Dienstes darf den regulären Login-Prozess der Nutzerschaft nicht beeinträchtigen.

Lösungsansatz: Quality Assurance am Edge

Anstatt Teams dazu zu zwingen, ihre Backend-Implementierungen (Node, PHP, Go, Java) zu modifizieren, verfolgen wir einen infrastrukturellen Ansatz.

Mit dem offiziellen caddy-hansestack Plugin für den Caddy Reverse Proxy wird die Security-QA vollständig aus der Applikation entkoppelt. Im vorgesehenen enrich_response Modus verhält sich das System wie folgt:

Das Plugin agiert als Middleware. Es fängt den Request ab, extrahiert k-anonymisiert das Passwort und reicht den originalen Login-Request umgehend und parallel an das Backend weiter. Die Backend-Implementierung bleibt unberührt und verarbeitet den Login wie gewohnt. Caddy wartet lediglich beim Zurücksenden der Antwort auf das asynchrone API-Ergebnis und injiziert den HTTP-Header (X-Hansestack-Leaked: true) in die ausgehende Response an den Client.

Dies erfordert keine Code-Änderungen im Backend und fügt dem primären Login-Vorgang keine Latenz hinzu.

Systemverhalten unter Last

Ein Architektur-Konzept muss sich unter Extrembedingungen beweisen. Um die Ausfallsicherheit zu validieren, haben wir das System einem kontrollierten Belastungstest unterzogen.

In einem isolierten Demo-Setup haben wir mittels eines Bash-Skripts 40.000 parallele Login-Versuche (in 40 Blöcken à 1.000 Hintergrundprozessen) auf den lokalen Caddy-Server simuliert:

for j in $(seq 40); do \
  for i in $(seq 1000); do \
    curl --silent --url '[http://127.0.0.1/login](http://127.0.0.1/login)' \
    --data-raw '{"email":"demo@example.com","password":"asdfghjkl;\\"}' & \
  done; \
done;

Ziel war es, das System gezielt zu überlasten, um das Verhalten des integrierten Circuit Breakers messbar zu machen.

Die Traffic Overview im Grafana-Dashboard visualisiert den Lastverlauf:

(Der Last-Spike von 40.000 Requests wird vollständig vom Caddy-Proxy verarbeitet, während die Backend-Prozesse ungestört weiterlaufen.)

Die detaillierten Metriken aus den Bereichen Verdicts, Fail-Open Outcomes und Health:

(Metriken nach dem Lasttest: Über 36.700 Requests wurden vom Fail-Open-Mechanismus abgefangen. Es traten keine Client-Errors auf.)

Anatomie der Resilienz (Fail-Open)

Die erfassten Metriken belegen die beabsichtigte Fehlertoleranz der entkoppelten Architektur:

1. Initiale Verarbeitung (Checked: 1.307): Die Hansestack-API verarbeitet die ersten 1.307 Requests regulär und identifiziert das Test-Passwort als kompromittiert.
2. Rate Limiting (Rate Limited: 1.924): Aufgrund der massiven Parallelität greift die Schutzfunktion der API. 1.924 Requests werden reguliert. Sechs weitere Anfragen scheitern bedingt durch lokale Netzwerk-Überlastung (Skip Error: 6).
3. Auslösen des Circuit Breakers: Das Caddy-Plugin registriert diese Fehlschläge an der Edge. Nach fünf aufeinanderfolgenden Fehlern aktiviert sich der Circuit Breaker gemäß Konfiguration.
4. Graceful Degradation (Circuit Open: 36.715): Das System wechselt in den Fail-Open Modus. Die verbleibenden 36.715 Requests treffen auf den offenen Circuit Breaker. Sie werden lokal ohne API-Aufruf passiert (und formal als not leaked gewertet), um die externe Schnittstelle zu entlasten und den Auth-Flow nicht zu blockieren.

Resultat und Latenzen: Das System verzeichnet 0 Client Errors. Die Zustellung der Requests an das Backend erfolgte durchgehend. Die gemessenen Latenzen dokumentieren die Stabilität: Der p50-Wert (Median) lag bei 2,73 ms, p95 bei 150 ms und das p99-Quantil bei 345 ms – und damit signifikant unter dem definierten 500ms-Timeout. Der Login-Prozess blieb uneingeschränkt performant, während die Security-Schicht auf die Überlastung reagierte.

Zusammenfassung

Zusätzliche Prüfmechanismen im Auth-Flow dürfen die Systemstabilität nicht gefährden. Die Verlagerung des k-Anonymity Leak-Checks als enrich_response Middleware in den Reverse Proxy, abgesichert durch Circuit Breaker, bietet verlässliche Security-Metriken bei minimalem Implementierungsaufwand und geschütztem Kerngeschäft.

Reproduzierbarkeit:
Das vollständige Setup inklusive Caddy, Dummy-Backend, Prometheus und Grafana steht als Open-Source-Umgebung zur Verfügung. Das Repository kann lokal ausgeführt werden, um das Systemverhalten selbst zu validieren:

Zur interaktiven caddy-hansestack Sandbox