Jede öffentliche Login-Seite beginnt kurz nach dem Go-Live, von automatisierten Tools gescannt zu werden. Angreifer versuchen zuvor geleakte Benutzernamen und Passwörter, hämmern ein einzelnes Konto mit Passwortraten, oder verwenden Bots, um das Login-Formular zu missbrauchen.
Diese Angriffe sehen nicht gleich aus. Manchmal kommen viele Versuche von einer einzigen IP-Adresse. Manchmal wird derselbe Username von vielen verschiedenen Quellen erneut versucht. Manchmal werden geleakte Passwörter bei niedrigem Speed auf Tausende verschiedener Konten in einem verteilten Muster angewendet.
Deshalb reichen statische Abwehrmaßnahmen nicht aus. Nur nach IP zu sperren, verpasst verteilte Angriffe und kann echte Benutzer aus gemeinsam genutzten Netzwerken fälschlicherweise blockieren. Nur nach Konto zu sperren, gibt Angreifern einen weiteren Vorteil — sie können viele Konten sperren und einen Denial-of-Service verursachen. CAPTCHA bei jeder einzelnen Anmeldung zu erzwingen, ruiniert die echte Benutzererfahrung.
Der größere Fehler ist es, die Bot- und Risikoauswertung zur Login-Zeit vollständig einem Drittanbieter-Cloud-Dienst zu überlassen. Dieses Modell schafft externe Abhängigkeit, Kosten pro Benutzer oder pro Auswertung, Datensichtbarkeitsprobleme und einen zusätzlichen Bruchpunkt im Authentifizierungspfad.
Login-Schutz sollte keine einheitliche Wand sein. Er sollte eine lokale Sicherheitsschicht sein, die Reibung erhöht, wenn das Risiko steigt, basierend auf Quelle und Ziel des Angriffs reagiert und echte Benutzer nicht unnötig bestraft.
Denn die Login-Seite zu schützen bedeutet nicht nur, den Angreifer zu stoppen — es bedeutet auch, dem echten Benutzer zu ermöglichen, sicher weiterzuarbeiten.
Gestaffelte Reibung, Multi-Scope-Policy und eine selbst-gehostete Challenge — alles auf der Plattform, die Sie bereits besitzen.
Jede Policy läuft mit drei Schwellenwerten: eine Warnung, die im Audit-Log erscheint, eine CAPTCHA-Challenge, die Automatisierung filtert ohne Menschen zu blockieren, und ein Lockout, der die Tür vollständig schließt. Legitime Benutzer sehen selten die zweite Stufe und fast nie die dritte; Angreifer eskalieren schnell.
Jede Policy gilt für einen von drei Scopes: nach Quell-IP, nach Username oder nach beidem zusammen. Ein Brute-Force-Angriff auf ein Konto von einer IP wird durch den IP-Scope erkannt; Credential Stuffing über viele Usernames von rotierenden IPs wird durch den Username-Scope erkannt; der kombinierte Scope behandelt gezielte Angriffe, die beides mischen.
Die CAPTCHA-Challenge wird serverseitig als Bild generiert, mit fünf Schwierigkeitsstufen, einem Zeichensatz, der verwirrende Zeichen (I, L, O, 0, 1) überspringt, und konfigurierbaren Farben, Abmessungen und Störungen. Es gibt kein Google reCAPTCHA, kein Cloudflare Turnstile, keine Gebühr pro Auswertung — und der sensibelste Moment der Authentifizierung verlässt nie Ihren Perimeter.
Lockout-Zähler koordinieren mit demselben Versuchs-Tracking, das von jedem MFA-Kanal verwendet wird. Ein Benutzer kann keinen Faktor bruteforcen, während ein anderer Faktor bei einem parallelen Versuch wartet, und ein CAPTCHA, das beim Passwortschritt ausgelöst wird, propagiert zum Rest des Flows, der dieselbe Identität schützt.
Die Abwehr-Primitive im Detail, plus die Roadmap, die sie vertiefen wird.
Jede Policy ist an einen von drei Scopes gebunden. Der IP-Scope erkennt einen einzelnen Angreifer, der von einem Netzwerk aus viele Konten hämmert. Der Username-Scope erkennt Credential Stuffing, bei dem jeder Versuch die Quell-IP rotiert. Der kombinierte Scope erkennt den gezielten Fall, bei dem ein bekannter Angreifer sich von einem bestimmten Netzwerk aus auf ein bestimmtes Konto konzentriert.
Jede Policy läuft mit drei Schwellenwerten, die in Reihenfolge eskalieren. Der Warn-Schwellenwert markiert verdächtige Aktivität im Audit-Log, ohne den Benutzer zu beeinträchtigen. Der CAPTCHA-Schwellenwert stellt beim nächsten Versuch eine selbst-gehostete Bild-Challenge dar. Der Lockout-Schwellenwert schließt die Tür für eine konfigurierbare Dauer — und Reihenfolge, Werte und Decay-Fenster sind alle pro Policy.
CAPTCHAs werden lokal als Bilder generiert — fünf Schwierigkeitsstufen von leichten Lesbarkeitshinweisen bis zu starker Verzerrung, konfigurierbare Farben und Abmessungen zur Markenanpassung, und ein Zeichensatz, der absichtlich visuell ähnliche Zeichen (I, L, O, 0, 1) auslässt, um die Erfahrung des legitimen Benutzers sauber zu halten.
Login-Schutz wird vollständig auf der Plattform generiert, bereitgestellt, validiert und auditiert. Es gibt keine Gebühr pro Auswertung, keine externe Abhängigkeit, keine Datenschutzimplikation des Sendens jedes Login-Versuchs an einen Anbieter, und keinen undurchsichtigen Scoring-Dienst zwischen Ihren Benutzern und Ihrer Authentifizierung.
Fehlgeschlagene Passwortversuche, fehlgeschlagene MFA-Challenges und fehlgeschlagene CAPTCHA-Antworten speisen koordinierte Zähler pro Policy-Scope. Ein Angreifer kann keinen Faktor bruteforcen, während ein paralleler Versuch bei einem anderen wartet, und ein bei einem Schritt ausgelöster Lockout propagiert zu jedem Kanal, der dieselbe Identität schützt.
Jede Policy definiert ein Decay-Fenster. Fehlgeschlagene Versuche, die älter als das Fenster sind, zählen nicht mehr zu den aktuellen Schwellenwerten, sodass ein legitimer Benutzer, der letzte Woche dreimal sein Passwort falsch eingegeben hat, heute nicht bereits bei der CAPTCHA-Stufe beginnt. Das Fenster, die Decay-Form und die Schwellenwerte sind alle pro Policy anpassbar.
Jeder Login-Versuch — Erfolg, überschrittene Warnung, ausgelöstes CAPTCHA, ausgelöster Lockout — schreibt einen strukturierten Audit-Eintrag mit Zeitstempel, Quell-IP, User-Agent, Scope und Policy-Ergebnis. Empfängerinformationen (E-Mail, Telefon) werden standardmäßig im Audit-Stream maskiert, damit der Audit-Trail nicht zu einem sekundären Leckpfad wird.
Eine geplante Korrelations-Engine wird Versuchszähler über Dienste hinweg verknüpfen, sodass ein Angreifer, der Zugangsdaten gegen eine niedrig-wertige App testet, dann nicht mit einer sauberen Weste zu einer hoch-wertigen wechseln kann. IP-Reputations-Feeds werden in dieselbe Policy-Engine einfließen, um Reibung für bekannte bösartige Netzwerke automatisch zu erhöhen.
Die Mechanismen, die gestaffelte Abwehr für gute Benutzer unsichtbar und für Angreifer klar machen.
Hintergrundfarbe, Textfarbe, Breite, Höhe, Schriftgröße, Zeichenabstand, Störlinien und Störpunkte sind alle konfigurierbar. Die Challenge kann der visuellen Identität des Login-Portals entsprechen, das sie schützt, ohne preiszugeben, dass ein externer Dienst beteiligt ist — denn nichts Externes ist beteiligt.
Der Standard-Zeichensatz überspringt I, L, O, 0 und 1 — Zeichen, die in verzerrter Form leicht miteinander verwechselt werden. Legitime Benutzer lösen CAPTCHAs schneller und mit weniger Wiederholungsversuchen; der Abwehrwert gegen automatisierte Solver bleibt bei jeder Schwierigkeitsstufe erhalten.
Warn-Schwellenwert, CAPTCHA-Schwellenwert, Lockout-Schwellenwert, Decay-Fenster und Lockout-Dauer sind alle pro Policy konfigurierbar. Eine Benutzerverwaltungsoberfläche hat andere Toleranzen als ein öffentliches Helpdesk-Login oder eine Admin-Konsole; dieselbe Engine bedient sie mit unterschiedlichen Werten.
Zähler und Lockout-Zustand liegen in Redis, sodass jeder Gateway-Pod den aktuellen Versuchszähler für jeden Scope sehen kann. Horizontal skalierte Deployments sehen konsistenten Zustand ohne Koordinationsaufwand, und eine Lockout-Entscheidung, die auf einem Pod getroffen wird, ist sofort für jeden anderen Pod sichtbar.
Ein gesperrter Benutzer wartet entweder darauf, dass der Lockout nach seiner eigenen Uhr abläuft, oder wird von einem Administrator über die Gateway-Admin-Oberfläche entsperrt. Die Recovery-Aktion wird selbst auditiert; eine Notfall-Entsperrung während eines Incidents ist ein nachverfolgbares Ereignis statt einer unsichtbaren Umgehung.
Adaptive Schwellenwerte, die sich automatisch verschärfen, wenn eine vorgelagerte Threat-Intel-Quelle erhöhtes Risiko signalisiert — bekannte schlechte Netzwerke, aktive Credential-Stuffing-Kampagnen, geleakte Zugangsdaten-Listen — sind in der Roadmap. Dieselbe Policy-Engine empfängt das Signal; derselbe Audit-Trail zeichnet die Änderung auf.
Ein Angreifer mit einer geleakten Benutzername/Passwort-Liste rotiert IPs und versucht jedes Paar gegen die Login-Seite. Username-Scope-Policies erkennen dieses Muster — Zähler steigen pro Konto, die CAPTCHA-Stufe filtert Automatisierung, und der Lockout schließt die Tür für wiederholte Ziele.
Ein einzelner Angreifer, eine einzelne Quell-IP, ein einzelnes Zielkonto, viele Rateversuche. IP-Scope-Policies erkennen das innerhalb von Sekunden — die Warnung erscheint im Audit, die CAPTCHA-Stufe filtert gescriptete Versuche, und die Lockout-Dauer multipliziert sich schnell genug, um den Angriff unwirtschaftlich zu machen.
Automatisierte Agents versuchen, sich einzuloggen, um zu scrapen, zu spammen oder auf ein entsperrtes Konto zu warten. Die CAPTCHA-Stufe ist genau dort, wo diese erkannt werden — lokal generiert, lokal validiert und vollständig außerhalb der Reichweite automatisierter CAPTCHA-Solver-Dienste, die externe SaaS-Challenges angreifen.
PCI DSS, HIPAA und ISO 27001 erfordern Nachweise, dass Fehllogin-Überwachung vorhanden ist, mit Schwellenwerten und Audit-Trails. Der Audit-Stream pro Versuch gibt dem Prüfer einen einzigen Zeitplan zur Überprüfung, mit Schwellenwerten, die als Konfiguration statt als geschriebener Prosa ausgedrückt sind.
Dreistufige gestaffelte Reibung, dreigliedrige Scope-Abdeckung und selbst-gehostetes CAPTCHA — alles auf der Plattform, die Sie bereits besitzen. Wir zeigen Ihnen ein Live-Deployment auf Ihren Anwendungen.