Erste Schritte
Integrieren / SDKs
Benutzerverifizierung
Unternehmensverifizierung
Transaktionsüberwachung
ChangelogSchutz konfigurieren
Lesen und ändern Sie die Einstellungen mitGET und PATCH auf protection/ in der Authentifizierungs-Management-API Ihrer Anwendung oder in der Konsole.
enabled und breached_password_check sind standardmäßig false. Die oben genannten Modi sind die Standardwerte, sobald Sie den Schutz einschalten.
Richtlinien
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 Modusbrute 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.
Bot-Score und Gerätesignale
Senden Sie Gerätesignale bei Laufzeitaufrufen mit diesen Headern. Die gehosteten Seiten senden sie für Sie.
Diese Signale dienen als Kontext für eine Entscheidung, sind aber kein Identitätsnachweis. Sie werden außerdem mit jedem Anmeldeereignis übermittelt, wo Regeln
event.device.bot_score lesen können.
AUTOMATION_FRAMEWORK_DETECTED ist eine andere Prüfung. Es ist eine Warnung der IP- und Geräteanalyse 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: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.
403 {"error": "protection_factor_unavailable"}.
Kompromittierte Passwörter
Mitbreached_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}(oder6oder24) liefert201.DELETE protection/attack-mode/beendet ihn vorzeitig. Er endet außerdem nach Ablauf der Dauer von selbst.
- 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:
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 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.