> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Bot-Schutz bei Anmeldung: Stuffing, Brute Force > Didit schützt Anmeldung und Registrierung vor Bots, Credential Stuffing, Brute Force und riskanten Netzwerken. Inkl. Attack Mode. > [!WARNING] > > Die Authentifizierung ist neu. Der Schutz ist ausgeschaltet, bis Sie ihn einschalten. Rate-Limits und begrenzte Code-Versuche gelten immer. Der Bot-Schutz läuft bei jeder Registrierung, Anmeldung und jedem Zurücksetzen des Passworts. Dabei wird der Versuch gegen sechs Richtlinien geprüft. Jede Richtlinie hat einen Modus: | Modus | Was passiert | | - | - | | **Aus** | Die Richtlinie wird nicht geprüft. | | **Protokollieren** | Der Versuch wird fortgesetzt. Ein `risk_logged`-Ereignis erfasst den Treffer. | | **Herausforderung** | Die Person muss einen zusätzlichen Nachweis erbringen, bevor der Versuch fortgesetzt wird. | | **Sperren** | Der Versuch schlägt mit `403 {"error": "attempt_blocked"}` fehl. | ## Schutz konfigurieren Lesen und ändern Sie die Einstellungen mit `GET` und `PATCH` auf `protection/` in der Authentifizierungs-Management-API Ihrer Anwendung oder in der Konsole. ```json theme={null} { "enabled": true, "breached_password_check": true, "policies": { "bots": "block", "stuffing": "block", "brute": "challenge", "disposable": "block", "vpn": "challenge", "travel": "block" } } ``` `enabled` und `breached_password_check` sind standardmäßig `false`. Die oben genannten Modi sind die Standardwerte, sobald Sie den Schutz einschalten. ## Richtlinien | Richtlinie | Trifft zu, wenn | | - | - | | `bots` | Der Client meldet einen Bot-Score von 0,8 oder mehr, oder der User-Agent ist ein bekannter Headless- oder automatisierter Browser. | | `stuffing` | Ein Gerät oder eine IP versucht innerhalb von 15 Minuten, sich bei 10 oder mehr verschiedenen Konten anzumelden, oder das Passwort ist ein bekanntes kompromittiertes Passwort. | | `brute` | Das Konto hat 5 oder mehr fehlgeschlagene Versuche. Falsche Passwörter sowie falsche E-Mail-, Telefon- und Authenticator-Codes zählen alle mit. | | `disposable` | Eine Registrierung verwendet eine Wegwerf-E-Mail-Domain. | | `vpn` | Die IP gehört zu einem VPN, Tor oder Rechenzentrumsnetzwerk. | | `travel` | Die Anmeldung liegt mehr als 500 km von der vorherigen entfernt, mit mehr als 1.000 km/h, innerhalb von 24 Stunden. | Die Richtlinien `vpn` und `travel` verwenden die IP-Analyse von Didit. Ist diese Abfrage nicht verfügbar, wird der Versuch fortgesetzt; eine Anmeldung schlägt nie deswegen fehl. Der Standort für `travel` wird erst nach einer abgeschlossenen Anmeldung aktualisiert. ### Brute-Force und Sperre Der Modus `brute` entscheidet, was nach 5 Fehlversuchen passiert: * **Sperren**: Die Person muss ihr Passwort zurücksetzen, bevor sie sich wieder anmelden kann. * **Herausforderung**: Das Konto ist 15 Minuten gesperrt, und der nächste Versuch benötigt einen zusätzlichen Nachweis. * **Aus** oder **Protokollieren**: Keine Sperre. Das Zurücksetzen des Passworts bleibt nach einer Brute-Force-Sperre verfügbar, und ein Zurücksetzen hebt die Sperre auf. Ihr Team kann ein Konto außerdem in der Konsole entsperren. Wenn Sie nie Schutzeinstellungen gespeichert haben, gilt eine einfachere Regel: 5 fehlgeschlagene Passworteingaben sperren das Konto für 15 Minuten. ### Bot-Score und Gerätesignale Senden Sie Gerätesignale bei Laufzeitaufrufen mit diesen Headern. Die gehosteten Seiten senden sie für Sie. | Header | Inhalt | | - | - | | `X-Didit-PID` | Eine dauerhafte Geräte-ID mit 8 bis 128 Zeichen aus `A-Z a-z 0-9 . _ : -`. | | `X-Didit-FP-Hash` | Ein Geräte-Fingerprint. | | `X-Didit-FP-Bot-Score` | Ein Bot-Score von 0 bis 1. Werte außerhalb dieses Bereichs werden ignoriert. | Diese Signale dienen als Kontext für eine Entscheidung, sind aber kein Identitätsnachweis. Sie werden außerdem mit jedem [Anmeldeereignis](https://docs.didit.me/de/authentication/events-and-webhooks.md) übermittelt, wo Regeln `event.device.bot_score` lesen können. > [!NOTE] > > `AUTOMATION_FRAMEWORK_DETECTED` ist eine andere Prüfung. Es ist eine [Warnung der IP- und Geräteanalyse](https://docs.didit.me/de/core-technology/ip-analysis/warnings-ip-analysis.md) bei **Verifizierungssitzungen**, die ausgelöst wird, wenn das Verifizierungs-SDK ein Framework zur Browser-Automatisierung meldet. Sie wird bei der Anmeldung nicht ausgeführt. Bei der Anmeldung wird Automatisierung über die Richtlinie `bots` oben erkannt. ## Prüfungen Ein Versuch, für den eine Prüfung verlangt wird, liefert dies anstelle eines Anmeldecodes: ```json theme={null} { "protection_required": true, "challenge": "...", "methods": ["passkey", "email_code"], "options": { "...": "WebAuthn options when a passkey is offered" }, "expires_in": 300 } ``` Schließen Sie sie mit `POST protection/complete/` ab: * `{"challenge", "method": "email_code", "code"}` mit dem 6-stelligen Code, der an die E-Mail-Adresse der Person gesendet wurde, oder * `{"challenge", "method": "passkey", "response"}` mit der WebAuthn-Antwort. Sie haben 5 Versuche innerhalb von 5 Minuten. Hat die Person keinen verfügbaren Nachweis, liefert der Aufruf `403 {"error": "protection_factor_unavailable"}`. ## Kompromittierte Passwörter Mit `breached_password_check: true` prüft Didit neue und zurückgesetzte Passwörter gegen bekannte kompromittierte Passwörter. Das Passwort selbst wird nirgendwohin gesendet. Ein kompromittiertes Passwort wird mit `password_breached` abgelehnt. Bei der Anmeldung zählt ein kompromittiertes Passwort als Treffer der Richtlinie `stuffing`. Ist die Prüfung nicht verfügbar, wird das Passwort akzeptiert. ## Angriffsmodus Schalten Sie den Angriffsmodus während eines laufenden Angriffs ein: * `POST protection/attack-mode/` mit `{"duration_hours": 1}` (oder `6` oder `24`) liefert `201`. * `DELETE protection/attack-mode/` beendet ihn vorzeitig. Er endet außerdem nach Ablauf der Dauer von selbst. Solange der Angriffsmodus aktiv ist: * muss jede Registrierung und Anmeldung eine **Passkey**-Prüfung bestehen. Ein E-Mail-Code wird nicht akzeptiert. Neue Registrierungen und Personen ohne Passkey können erst abschließen, wenn der Angriffsmodus endet. * wird eine Registrierung aus einem VPN-, Tor- oder Rechenzentrumsnetzwerk gesperrt. ## Rate-Limits Jede Laufzeitroute ist pro IP und pro Anwendung begrenzt: | Routen | Pro Minute | Pro Stunde | | - | - | - | | Discovery und JWKS | 1.200 | 12.000 | | Runtime-API und gehostete Seiten | 30 | 300 | | E-Mail-Codes, Telefon-Codes und Provider-Callbacks | 5 | 20 | Bei Überschreitung des Limits liefert der Aufruf `429`. Beachten Sie den Header `Retry-After`, falls er gesendet wird. Anmeldeversuche sind außerdem pro Minute begrenzt: 60 pro IP, 15 pro Konto, 30 pro Gerät, 3.000 pro Anwendung und 20 SMS- oder WhatsApp-Code-Anfragen pro Telefonnummern-Präfix. Token-Aktualisierungen haben ein eigenes Kontingent pro Anwendung, 6.000 pro Minute, damit Token-Aktualisierungen nie Ihr Kontingent für Anmeldeversuche aufbrauchen. ## Ereignisse Jede Entscheidung wird als [Authentifizierungsereignis](https://docs.didit.me/de/authentication/events-and-webhooks.md) erfasst: `risk_logged`, `attempt_challenged`, `attempt_blocked`, `challenge_passed`, `challenge_failed`, `attack_mode_started` und `attack_mode_ended`. Das Ereignis zeigt an, welche Richtlinie ausgelöst wurde. ## Testen Testen Sie in einer Sandbox-Anwendung jeden Modus, den Sie aktivieren: einen gesperrten Versuch, eine bestandene und eine fehlgeschlagene Prüfung, eine Sperre und deren Zurücksetzen sowie das Ein- und Ausschalten des Angriffsmodus. Halten Sie Fehlermeldungen in Ihrer Oberfläche allgemein, damit sie nicht verraten, ob ein Konto existiert. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.