Protection anti-bots à la connexion : force brute

L’authentification est une nouveauté. La protection reste désactivée tant que vous ne l’activez pas. Les limites de débit et le nombre limité de tentatives de saisie de code s’appliquent toujours.

La protection contre les bots s’applique à chaque inscription, connexion et réinitialisation de mot de passe. Elle vérifie la tentative selon six politiques. Chaque politique a un mode :

Mode	Ce qui se passe
Désactivé	La politique n’est pas vérifiée.
Journaliser	La tentative se poursuit. Un événement `risk_logged` enregistre la correspondance.
Vérifier	La personne doit fournir une preuve supplémentaire avant que la tentative se poursuive.
Bloquer	La tentative échoue avec `403 {"error": "attempt_blocked"}`.

Configurer la protection

Lisez et modifiez les paramètres avec GET et PATCH sur protection/ dans l’API de gestion de l’authentification de votre application, ou depuis la console.

{
  "enabled": true,
  "breached_password_check": true,
  "policies": {
    "bots": "block",
    "stuffing": "block",
    "brute": "challenge",
    "disposable": "block",
    "vpn": "challenge",
    "travel": "block"
  }
}

enabled et breached_password_check valent false par défaut. Les modes décrits ci-dessus sont les valeurs par défaut une fois la protection activée.

Politiques

Politique	Correspondance lorsque
`bots`	Le client signale un score de bot de 0,8 ou plus, ou l’agent utilisateur est un navigateur sans interface graphique ou automatisé connu.
`stuffing`	Un même appareil ou une même IP tente 10 comptes différents ou plus en 15 minutes, ou le mot de passe figure parmi les mots de passe compromis connus.
`brute`	Le compte a enregistré 5 échecs ou plus. Les mots de passe erronés et les codes erronés envoyés par e-mail, par téléphone ou par l’application d’authentification comptent tous.
`disposable`	Une inscription utilise un domaine e-mail jetable.
`vpn`	L’IP est un VPN, un réseau Tor ou un réseau de centre de données.
`travel`	La connexion est à plus de 500 km de la précédente, à plus de 1 000 km/h, dans les 24 heures.

Les politiques vpn et travel utilisent l’analyse IP de Didit. Si cette recherche est indisponible, la tentative se poursuit : une connexion n’échoue jamais à cause de cette recherche. La position utilisée par travel n’est mise à jour qu’après une connexion réussie.

Force brute et verrouillage

Le mode brute détermine ce qui se passe après 5 échecs :

Bloquer : la personne doit réinitialiser son mot de passe avant de pouvoir se reconnecter.
Vérifier : le compte est verrouillé pendant 15 minutes, et la tentative suivante exige une preuve supplémentaire.
Désactivé ou Journaliser : aucun verrouillage.

La réinitialisation du mot de passe reste disponible après un blocage par force brute, et une réinitialisation lève le verrouillage. Votre équipe peut également déverrouiller un compte depuis la console. Si vous n’avez jamais enregistré de paramètres de protection, une règle plus simple s’applique : 5 mots de passe erronés verrouillent le compte pendant 15 minutes.

Score de bot et signaux d’appareil

Envoyez les signaux d’appareil lors des appels d’exécution avec ces en-têtes. Les pages hébergées les envoient à votre place.

En-tête	Contenu
`X-Didit-PID`	Un identifiant d’appareil persistant, de 8 à 128 caractères parmi `A-Z a-z 0-9 . _ : -`.
`X-Didit-FP-Hash`	Une empreinte d’appareil.
`X-Didit-FP-Bot-Score`	Un score de bot de 0 à 1. Les valeurs hors de cette plage sont ignorées.

Ces signaux servent de contexte à une décision, et non de preuve d’identité. Ils sont aussi transmis avec chaque événement de connexion, où les règles peuvent lire event.device.bot_score.

AUTOMATION_FRAMEWORK_DETECTED est un contrôle distinct. Il s’agit d’un avertissement d’analyse de l’appareil et de l’IP sur les sessions de vérification, émis lorsque le SDK de vérification signale un framework d’automatisation de navigateur. Ce contrôle ne s’exécute pas lors de la connexion. À la connexion, l’automatisation est détectée par la politique bots ci-dessus.

Vérifications

Une tentative soumise à une vérification renvoie ceci à la place d’un code de connexion :

{
  "protection_required": true,
  "challenge": "...",
  "methods": ["passkey", "email_code"],
  "options": { "...": "WebAuthn options when a passkey is offered" },
  "expires_in": 300
}

Complétez-la avec POST protection/complete/ :

{"challenge", "method": "email_code", "code"} avec le code à 6 chiffres envoyé à l’e-mail de la personne, ou
{"challenge", "method": "passkey", "response"} avec la réponse WebAuthn.

Vous disposez de 5 tentatives en 5 minutes. Si la personne ne dispose d’aucune preuve disponible, l’appel renvoie 403 {"error": "protection_factor_unavailable"}.

Mots de passe compromis

Avec breached_password_check: true, Didit vérifie les nouveaux mots de passe et les mots de passe définis lors d’une réinitialisation par rapport aux mots de passe compromis connus. Le mot de passe lui-même n’est jamais transmis. Un mot de passe compromis est refusé avec password_breached. À la connexion, un mot de passe compromis compte comme une correspondance stuffing. Si la vérification est indisponible, le mot de passe est accepté.

Mode attaque

Activez le mode attaque pendant une attaque en cours :

POST protection/attack-mode/ avec {"duration_hours": 1} (ou 6 ou 24) renvoie 201.
DELETE protection/attack-mode/ y met fin plus tôt. Il s’arrête aussi automatiquement à l’issue de la durée.

Lorsque le mode attaque est activé :

chaque inscription et chaque connexion doit réussir une vérification par clé d’accès. Un code e-mail n’est pas accepté. Les nouvelles inscriptions et les personnes sans clé d’accès ne peuvent pas aboutir tant que le mode attaque n’est pas terminé.
une inscription depuis un réseau VPN, Tor ou de centre de données est bloquée.

Limites de débit

Chaque route d’exécution est limitée par IP, par application :

Routes	Par minute	Par heure
Découverte et JWKS	1 200	12 000
API d’exécution et pages hébergées	30	300
Codes e-mail, codes téléphoniques et rappels des fournisseurs	5	20

Au-delà de la limite, l’appel renvoie 429. Respectez l’en-tête Retry-After lorsqu’il est envoyé. Les tentatives de connexion sont aussi limitées par minute : 60 par IP, 15 par compte, 30 par appareil, 3 000 par application et 20 demandes de code SMS ou WhatsApp par préfixe de numéro de téléphone. Le renouvellement des tokens dispose d’un quota propre à l’application, de 6 000 par minute, afin que les renouvellements ne consomment jamais vos connexions.

Événements

Chaque décision est enregistrée dans un événement d’authentification : risk_logged, attempt_challenged, attempt_blocked, challenge_passed, challenge_failed, attack_mode_started et attack_mode_ended. L’événement indique la politique qui a été déclenchée.

Tester

Dans une application sandbox, testez chaque mode que vous activez : une tentative bloquée, une vérification réussie et une vérification échouée, un verrouillage et sa réinitialisation, ainsi que le mode attaque activé puis désactivé. Gardez des messages d’erreur génériques dans votre interface afin de ne pas révéler si un compte existe.

Guides

Authentification

Model Context Protocol (MCP)

SDK web

SDK natifs

SDK serveur

Intégrations

Protection anti-bots à la connexion : force brute

Configurer la protection

Politiques

Force brute et verrouillage

Score de bot et signaux d’appareil

Vérifications

Mots de passe compromis

Mode attaque

Limites de débit

Événements

Tester

​Configurer la protection

​Politiques

​Force brute et verrouillage

​Score de bot et signaux d’appareil

​Vérifications

​Mots de passe compromis

​Mode attaque

​Limites de débit

​Événements

​Tester

Configurer la protection

Politiques

Force brute et verrouillage

Score de bot et signaux d’appareil

Vérifications

Mots de passe compromis

Mode attaque

Limites de débit

Événements

Tester