Protección contra bots en el inicio de sesión

La autenticación es una función nueva. La protección está desactivada hasta que la activas. Los límites de solicitudes y los límites de intentos de código se aplican siempre.

La protección contra bots se ejecuta en cada registro, inicio de sesión y restablecimiento de contraseña. Compara el intento con seis políticas. Cada política tiene un modo:

Modo	Qué ocurre
Desactivado	La política no se comprueba.
Registrar	El intento continúa. Un evento `risk_logged` registra la coincidencia.
Desafiar	La persona debe superar una prueba adicional antes de que el intento continúe.
Bloquear	El intento falla con `403 {"error": "attempt_blocked"}`.

Configurar la protección

Consulta y cambia la configuración con GET y PATCH sobre protection/ en la API de gestión de autenticación de tu aplicación, o desde la consola.

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

enabled y breached_password_check son false de forma predeterminada. Los modos anteriores son los predeterminados una vez que activas la protección.

Políticas

Política	Coincide cuando
`bots`	El cliente informa una puntuación de bot de 0.8 o más, o el user agent corresponde a un navegador headless o automatizado conocido.
`stuffing`	Un mismo dispositivo o IP prueba 10 o más cuentas distintas en 15 minutos, o la contraseña es una contraseña filtrada conocida.
`brute`	La cuenta tiene 5 o más intentos fallidos. Cuentan las contraseñas incorrectas y los códigos incorrectos de correo electrónico, teléfono y autenticador.
`disposable`	Un registro usa un dominio de correo electrónico desechable.
`vpn`	La IP pertenece a una VPN, a Tor o a una red de centro de datos.
`travel`	El inicio de sesión está a más de 500 km del anterior, a más de 1,000 km/h, en un plazo de 24 horas.

Las políticas vpn y travel usan el análisis de IP de Didit. Si esa consulta no está disponible, el intento continúa; un inicio de sesión nunca falla por ese motivo. La ubicación de travel solo se actualiza después de un inicio de sesión completado.

Fuerza bruta y bloqueo

El modo de brute decide qué ocurre después de 5 fallos:

Block: la persona debe restablecer su contraseña antes de poder volver a iniciar sesión.
Challenge: la cuenta se bloquea durante 15 minutos y el siguiente intento requiere una prueba adicional.
Off o Log: no hay bloqueo.

El restablecimiento de contraseña sigue disponible después de un bloqueo por fuerza bruta, y un restablecimiento elimina el bloqueo. Tu equipo también puede desbloquear una cuenta desde la consola. Si nunca has guardado la configuración de protección, se aplica una regla más sencilla: 5 intentos fallidos de contraseña bloquean la cuenta durante 15 minutos.

Puntuación de bot y señales del dispositivo

Envía las señales del dispositivo en las llamadas de runtime con estos encabezados. Las páginas alojadas las envían por ti.

Encabezado	Contenido
`X-Didit-PID`	Un ID de dispositivo persistente, de 8 a 128 caracteres de `A-Z a-z 0-9 . _ : -`.
`X-Didit-FP-Hash`	Una huella digital del dispositivo.
`X-Didit-FP-Bot-Score`	Una puntuación de bot de 0 a 1. Los valores fuera de ese rango se ignoran.

Estas señales son contexto para una decisión, no una prueba de identidad. También viajan con cada evento de inicio de sesión, donde las reglas pueden leer event.device.bot_score.

AUTOMATION_FRAMEWORK_DETECTED es una comprobación distinta. Es una advertencia del análisis de IP y dispositivo en las sesiones de verificación, que se genera cuando el SDK de verificación informa de un framework de automatización de navegador. No se ejecuta en el inicio de sesión. En el inicio de sesión, la automatización la detecta la política bots descrita arriba.

Desafíos

Un intento sometido a una verificación adicional devuelve esto en lugar de un código de inicio de sesión:

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

Complétalo con POST protection/complete/:

{"challenge", "method": "email_code", "code"} con el código de 6 dígitos enviado al correo electrónico de la persona, o
{"challenge", "method": "passkey", "response"} con la respuesta de WebAuthn.

Dispones de 5 intentos en un plazo de 5 minutos. Si la persona no tiene ningún método de verificación disponible, la llamada devuelve 403 {"error": "protection_factor_unavailable"}.

Contraseñas filtradas

Con breached_password_check: true, Didit compara las contraseñas nuevas y restablecidas con contraseñas filtradas conocidas. La contraseña en sí nunca se envía a ningún sitio. Una contraseña filtrada se rechaza con password_breached. Al iniciar sesión, una contraseña filtrada cuenta como una coincidencia de stuffing. Si la comprobación no está disponible, la contraseña se acepta.

Modo de ataque

Activa el modo ataque durante un ataque en curso:

POST protection/attack-mode/ con {"duration_hours": 1} (o 6 o 24) devuelve 201.
DELETE protection/attack-mode/ lo finaliza antes de tiempo. También finaliza por sí solo una vez transcurrida la duración.

Mientras el modo ataque está activo:

cada registro e inicio de sesión debe superar un desafío de passkey. No se acepta un código por correo electrónico. Los nuevos registros no pueden completarse y las personas sin passkey no pueden finalizar el proceso hasta que finalice el modo de ataque.
se bloquea cualquier registro desde una VPN, Tor o una red de un centro de datos.

Límites de solicitudes

Cada ruta de runtime está limitada por IP y por aplicación:

Rutas	Por minuto	Por hora
Discovery y JWKS	1,200	12,000
API de runtime y páginas alojadas	30	300
Códigos por correo electrónico, códigos por teléfono y callbacks de proveedores	5	20

Al superar el límite, la llamada devuelve 429. Respeta el encabezado Retry-After cuando se envíe. Los intentos de inicio de sesión también están limitados por minuto: 60 por IP, 15 por cuenta, 30 por dispositivo, 1,000 por aplicación y 20 solicitudes de código por SMS o WhatsApp por prefijo de número de teléfono.

Eventos

Cada decisión se registra como un evento de autenticación: risk_logged, attempt_challenged, attempt_blocked, challenge_passed, challenge_failed, attack_mode_started y attack_mode_ended. El evento muestra qué política se aplicó.

Pruébalo

En una aplicación de sandbox, prueba cada modo que actives: un intento bloqueado, un desafío superado y uno fallido, un bloqueo de cuenta y su restablecimiento, y el modo de ataque activado y desactivado. Mantén los errores genéricos en tu interfaz para que no revelen si una cuenta existe.

Guías

Autenticación

Model Context Protocol (MCP)

SDKs web

SDKs nativos

SDK de servidor

Integraciones

Protección contra bots en el inicio de sesión

Configurar la protección

Políticas

Fuerza bruta y bloqueo

Puntuación de bot y señales del dispositivo

Desafíos

Contraseñas filtradas

Modo de ataque

Límites de solicitudes

Eventos

Pruébalo

​Configurar la protección

​Políticas

​Fuerza bruta y bloqueo

​Puntuación de bot y señales del dispositivo

​Desafíos

​Contraseñas filtradas

​Modo de ataque

​Límites de solicitudes

​Eventos

​Pruébalo

Configurar la protección

Políticas

Fuerza bruta y bloqueo

Puntuación de bot y señales del dispositivo

Desafíos

Contraseñas filtradas

Modo de ataque

Límites de solicitudes

Eventos

Pruébalo