Guía

Detección de bots sin CAPTCHA: qué funciona de verdad

Por qué el desafío dejó de ser una defensa, qué señales lo sustituyeron y cómo es en la práctica una configuración honesta de detección invisible.

El desafío dejó de funcionar antes de que se dejara de usar

Un CAPTCHA es una prueba que da por supuesto que resolverla es caro para una máquina y barato para una persona. Las dos mitades de ese supuesto han caído.

Resolver ya es barato para las máquinas. Servicios comerciales de resolución aceptan un desafío por API y devuelven el token, con precio por millar, y quienes tienen interés en tu sitio ya tienen esa línea en su presupuesto. La visión por computador resuelve la mayoría de las cuadrículas de imágenes sin ayuda humana alguna.

Y resolver ya no es barato para las personas. Las cuadrículas se endurecieron precisamente porque las máquinas mejoraron, así que el coste aterrizó en tus clientes en lugar de en el atacante. En un pago, ese coste se mide en pedidos abandonados.

Así que el desafío es hoy un impuesto sobre los usuarios reales que un bot decidido esquiva por una fracción de céntimo. Ese es todo el argumento para mirar a otra parte.

Qué lo sustituye: señales, no pruebas

La detección invisible deja de pedirle al visitante que demuestre nada y lee en su lugar lo que la sesión ya está contando. Tres capas cargan con la mayor parte de la señal.

Comportamiento. Cómo interactúa la sesión con la página: la forma del movimiento del puntero, los tiempos entre eventos, cómo se mueve el foco por un formulario. La automatización produce distribuciones distintas de las humanas, y difiere más justo donde más se esfuerza en parecer humana.

Transporte. El apretón de manos TLS y los ajustes HTTP/2 describen la pila del cliente. Una huella JA3 o JA3N te dice qué biblioteca abrió la conexión, y un navegador headless sobre una pila TLS real sigue anunciando una combinación que un Chrome auténtico en Windows no produce. Es bastante más difícil de falsificar que una cadena user-agent, porque exige reproducir la pila criptográfica de un cliente real en lugar de editar una cabecera.

Reputación. Qué hizo antes esta dirección, en tu sitio y opcionalmente en los de otros. Una dirección no se juzga solo por la sesión que tienes delante.

Ninguna capa basta por sí sola. Las señales de comportamiento son escasas en una sesión que aterriza y envía de inmediato; las huellas de transporte las comparten todos los que usan la misma biblioteca, incluidos los legítimos; la reputación está vacía la primera vez que aparece una dirección. El veredicto sale de combinarlas.

Los modos de fallo que conviene conocer

Cualquier descripción honesta de la detección invisible incluye dónde se equivoca, porque sus fallos son más silenciosos que los de un CAPTCHA y por tanto más fáciles de pasar por alto.

Los usuarios reales celosos de su privacidad parecen automatizados. Alguien con un navegador blindado a través de una VPN produce señales de comportamiento escasas y una huella inusual. Para eso existe tu lista de permitidos, y hay que mantenerla de verdad.
Direcciones de salida compartidas. Los NAT corporativos, el CGNAT móvil y las salidas de VPN ponen a miles de personas sin relación tras una sola dirección. La reputación sobre ese tipo de dirección debe ponderarse distinto, o bloquearás a una empresa porque una persona de su red lanzó un scraper.
Bots buenos que parecen malos. El reintento de webhook de tu proveedor de pagos, tu monitor de disponibilidad, la integración de un socio: todos automatizados, todos necesarios. Van en la lista de permitidos antes de activar la aplicación, no después de que alguien reporte una caída.
La primera aparición. Una dirección recién estrenada no tiene historial. Para eso sirve exactamente una lista de bloqueo compartida, y por eso un sistema que solo hace reputación y ningún análisis de sesión es débil el primer día.
Deriva silenciosa. Un CAPTCHA roto hace ruido. Un detector que ha empezado a dejar pasar en silencio un patrón de bot nuevo parece una semana tranquila. Vigila la tasa de bloqueo frente al tráfico, no solo la disponibilidad del panel.

Cómo es una configuración defendible

Ordenado por cuánto decide cada paso del resultado.

Empieza en modo observación. Ejecuta la detección con la aplicación desactivada el tiempo suficiente para ver un ciclo semanal completo, incluida tu noche más tranquila y tu promoción más intensa. Buscas veredictos que contradigan cosas que ya sabes ciertas.

Rellena la lista de permitidos antes de aplicar, no después. Webhooks de pago, monitorización, integraciones de socios, tus propios rangos de oficina, los rastreadores por los que quieres ser indexado. Es el paso que la gente se salta y descubre a las tres de la mañana.

Aplica en la pasarela, no en la página. Una decisión aplicada en JavaScript es una decisión que un atacante puede saltarse. La aplicación va donde se sirve la petición.

Falla abierto con la plataforma y cerrado con tus propias reglas. Si el servicio de veredictos no responde, el tráfico debe fluir: una caída que se lleva tu sitio por delante es peor que un bot que se cuela. Tu propia lista de denegados es otra cosa: es tu instrucción explícita y debe sobrevivir.

Mantén los veredictos explicables. Cuando alguien discuta un bloqueo, necesitas ver qué señales lo produjeron. Un sistema que solo devuelve un número te deja sin respuesta ante un cliente.

Dónde encaja Karma

Karma es este diseño hecho producto: un snippet asíncrono, señales de comportamiento y de transporte enviadas a un recolector por TLS, un veredicto contra tu propia base de reputación por inquilino y —si te sumas— una lista de bloqueo compartida construida con lo que vieron otros inquilinos.

La aplicación ocurre en tu pasarela, y las decisiones se cachean localmente para que una caída del recolector no pueda llevarse tu sitio por delante. Tus listas de permitidos y denegados siempre están por encima del veredicto de la plataforma.

El plan gratuito Detect es el modo observación: 25 000 veredictos al mes, de forma permanente, sin tarjeta y sin aplicación. Es exactamente la configuración descrita arriba, y es la manera correcta de empezar sea cual sea tu elección final.

FAQ

¿Se pueden detectar bots sin CAPTCHA?

Sí, y ya es el enfoque dominante. La detección invisible lee señales de comportamiento de la sesión, huellas de transporte del apretón de manos TLS y los ajustes HTTP/2, y la reputación de la dirección, y llega a un veredicto sin preguntarle nada al visitante. No se muestra nada, así que no hay ningún paso del embudo donde perder clientes reales.

¿Siguen siendo eficaces los CAPTCHA contra los bots?

Mucho menos de lo que sugiere su despliegue. Servicios comerciales de resolución devuelven un token por API por una fracción de céntimo, y la visión por computador resuelve la mayoría de las cuadrículas de imágenes sin ayuda. El desafío se ha convertido en un coste que pagan sobre todo los usuarios reales, mientras que los atacantes que importan lo tratan como una partida pequeña.

¿Qué es el fingerprinting TLS y por qué ayuda?

El apretón de manos TLS expone un conjunto ordenado de suites de cifrado, extensiones y curvas que varía según la biblioteca cliente, resumido como un hash JA3 o JA3N. Identifica la pila que abrió la conexión, así que un script que dice ser Chrome pero usa una biblioteca TLS de Python queda a la vista. Es mucho más difícil de falsificar que un user-agent, porque exige reproducir la pila criptográfica de un cliente real en lugar de editar una cabecera.

¿Qué riesgos tiene la detección invisible de bots?

Sobre todo falsos positivos con usuarios reales que parecen automatizados —navegadores blindados, salidas de VPN y CGNAT— y con bots buenos como los webhooks de pago y la monitorización. Ambos se gestionan con una lista de permitidos rellenada antes de activar la aplicación y con un periodo de observación que cubra un ciclo semanal de tráfico completo.