Qué es CAPTCHA: cómo funciona, cuánto cuesta y qué lo sustituye

Cómo funciona un CAPTCHA

CAPTCHA son las siglas en inglés de "prueba de Turing pública y completamente automatizada para distinguir ordenadores de humanos". Investigadores de la Universidad Carnegie Mellon acuñaron el nombre en 2003 y la idea no ha cambiado desde entonces: preguntar algo fácil para una persona y difícil para un programa, y aceptar la petición solo si la respuesta es correcta.

Todo CAPTCHA, desde una palabra torcida hasta una comprobación invisible, funciona en tres pasos. El widget se ejecuta en el navegador del visitante y genera un token, la prueba de que se superó el desafío. El navegador envía ese token junto con el formulario. Y tu servidor pregunta al proveedor del CAPTCHA si el token es auténtico antes de crear la cuenta o enviar el mensaje.

El tercer paso es el que se olvida, y sin él el widget es decoración: un bot envía el formulario sin token, o con uno viejo, y pasa. Por eso los tokens caducan pronto y solo valen una vez: la comprobación tiene que hacerse en el servidor y en cada envío.

Verificación en el servidor: el paso que da sentido al widget

curl -s https://www.google.com/recaptcha/api/siteverify \
  -d secret="$RECAPTCHA_SECRET" \
  -d response="$TOKEN_DEL_FORMULARIO"

# {"success": true, "hostname": "example.com", ...}
# hCaptcha y Turnstile funcionan igual, cada uno con su propia URL siteverify.

Los tipos: de las letras torcidas a la comprobación sin acertijo

Los CAPTCHA de texto muestran letras y números deformados. Fueron la primera generación y hoy son los más débiles: el software de reconocimiento de caracteres los lee mejor que mucha gente.

Los CAPTCHA de imagen piden marcar todas las casillas con un semáforo o una bicicleta. Los CAPTCHA de audio dictan cifras sobre ruido de fondo y existen sobre todo como alternativa accesible a los dos anteriores.

reCAPTCHA v2, la casilla de Google, cambió el modelo en 2014. Marcar "No soy un robot" es sobre todo un momento para que el script observe el navegador y cómo se ha comportado; solo el visitante del que no está seguro recibe la cuadrícula de imágenes. Su variante invisible elimina también la casilla y muestra la cuadrícula solo cuando hace falta.

reCAPTCHA v3 (2018) no muestra nada. Devuelve una puntuación entre 0.0 y 1.0 para cada acción, y es tu servidor quien decide qué significa una puntuación baja: rechazar, pedir un segundo factor o mandar el envío a moderación.

hCaptcha sigue el modelo de v2, con comprobaciones en segundo plano y una tarea de imágenes en caso de duda, y se presenta como la opción centrada en la privacidad; su versión empresarial añade puntuaciones de riesgo.

Cloudflare Turnstile (2022) sustituye el acertijo por un conjunto rotatorio de comprobaciones no interactivas que se ejecutan en el navegador, y es gratuito en cualquier sitio, no solo en los que están detrás de Cloudflare. Su widget tiene tres modos: gestionado (una casilla solo si las comprobaciones dudan), no interactivo e invisible.

La dirección salta a la vista: cada generación pregunta menos al visitante y más al navegador.

Lo que te cuesta un CAPTCHA

Tiempo, y las conversiones que van detrás. Un amplio estudio de Stanford de 2010 midió unos 10 segundos para resolver un CAPTCHA de imagen y cerca de 30 para uno de audio, y muchas de las respuestas de audio eran incorrectas. Cada uno de esos segundos se interpone entre el visitante y lo que vino a hacer: registrarse, pagar, hacerte una pregunta.

Accesibilidad. Un acertijo visual deja fuera a las personas ciegas o con baja visión, y la alternativa de audio es difícil para todos e inútil para quien no ve ni oye bien. El W3C ha publicado una nota dedicada por completo a la inaccesibilidad de los CAPTCHA, y las WCAG exigen que un CAPTCHA ofrezca una alternativa para otro sentido.

Privacidad y peso de la página. El widget es un script del proveedor, cargado en tu página, que ve el navegador del visitante; eso debe constar en tu política de privacidad. Además es una porción considerable de JavaScript de terceros, así que cárgalo solo en la página que tiene el formulario, nunca en todo el sitio.

Equivocarse con las personas. Los sistemas basados en riesgo aprenden cómo es el tráfico típico, y quien usa una VPN, un navegador centrado en la privacidad o la conexión de una oficina concurrida parece menos típico. Recibe más acertijos, o una puntuación más baja, sin haber hecho nada malo.

Por qué los acertijos dejaron de bastar

Un CAPTCHA solo funciona mientras resolverlo le salga más barato a una persona que a una máquina. Eso dejó de ser cierto hace tiempo.

Las máquinas mejoraron. Los CAPTCHA de texto cayeron primero ante el reconocimiento de caracteres, y las cuadrículas de imágenes, después, ante los modelos de visión modernos. Un estudio presentado en USENIX Security en 2023 halló que los bots resolvían varios tipos de CAPTCHA muy extendidos más rápido que las personas, y el texto deformado con más acierto.

Las personas se abarataron. Donde el software no llega, los servicios de resolución de CAPTCHA envían el acertijo a trabajadores humanos y devuelven la respuesta por una API, por unos pocos dólares cada mil resoluciones. Para quien envía spam es calderilla; para tus visitantes reales, el acertijo sigue siendo la misma molestia de diez segundos de siempre.

Así que hoy un CAPTCHA filtra sobre todo la automatización barata: scripts que ni se molestaron en parecer un navegador. A la entrada de un formulario eso sigue mereciendo la pena. Pero no es una defensa para el resto del sitio, y el valor de los sistemas modernos está en las señales que recogen, no en el acertijo que muestran de vez en cuando.

Las alternativas invisibles

Estas son las comprobaciones que sustituyen al acertijo. Ninguna pregunta nada al visitante, y funcionan mejor combinadas.

JS challenge (desafío JavaScript). El servidor responde a una primera petición sospechosa con una pequeña página que ejecuta un script en el navegador. Un navegador real lo completa en un segundo aproximadamente y recibe una cookie firmada; un script que solo descarga HTML no pasa de ahí. El visitante ve una breve página de "comprobando tu conexión", o nada en absoluto.

Prueba de trabajo. Una variante en la que el navegador resuelve un pequeño problema de cálculo. Las personas no lo notan, pero cada petición le cuesta al bot tiempo de CPU, y eso se acumula a escala.

Limitación de tasa. Cuenta las peticiones de cada cliente a lo largo del tiempo. Una persona lee una página y hace unos pocos clics por minuto; un scraper hace cientos. Contar revela un comportamiento que ninguna petición aislada delata.

Puntuaciones de bots y señales de riesgo. De dónde viene la petición (una conexión doméstica o una red de centro de datos), si sus cabeceras encajan con el navegador que dice ser, cómo se comporta a lo largo de varias peticiones. Algunos sistemas lo resumen en una puntuación; otros actúan según señales concretas. En ambos casos la decisión se toma antes de servir la página.

Campos trampa (honeypot). Un campo del formulario oculto a las personas con CSS. Los humanos lo dejan vacío; los bots ingenuos rellenan todos los campos y se delatan. Gratis, invisible y eficaz contra el spam barato.

Rastreadores verificados. Los buscadores tienen que atravesar todo lo anterior sin tropiezos. Se reconocen por la red de la que vienen, no por su user agent, un texto que cualquiera puede escribir.

Dónde sigue teniendo sentido un CAPTCHA

En un formulario donde un solo envío con éxito le vale algo a un atacante: alta de cuentas, restablecimiento de contraseña, formularios de contacto y comentarios, campos de tarjetas regalo y cupones. Ahí un paso extra para una persona es un precio razonable, y un token verificado en el servidor es justo el control adecuado.

Así lo usamos nosotros. Los formularios de registro y contacto de cdn.com.tr llevan un CAPTCHA de casilla, y en la página de precios el script del CAPTCHA solo se carga al abrir el formulario de contacto empresarial, de modo que quien consulta precios no lo descarga.

Dónde no tiene sentido: la navegación normal, los listados de productos, los artículos, las API y las apps móviles. Un acertijo delante de la navegación cobra un peaje a cada visitante para frenar un tráfico que una comprobación invisible en el edge frena mejor.

Cómo protege CDN.com.tr un sitio sin acertijos

La protección contra bots de cdn.com.tr es un desafío JavaScript que se ejecuta en el edge, delante de tu servidor de origen. En el panel es la tarjeta Protección contra bots (JS Challenge), en la sección Protection, con tres modos: desactivado, visitantes de riesgo (recomendado) y todos. El cambio de modo llega al edge por sí solo; no hay nada que desplegar.

En el modo visitantes de riesgo solo se comprueban las peticiones que muestran una señal de riesgo: tráfico de redes de centros de datos y de nube, desde donde casi nunca navega un lector real; un cliente que dice ser un buscador pero llega desde una red que ese buscador no usa; un user agent ausente o casi vacío; y una ráfaga de páginas vistas desde una misma dirección. Un lector con conexión doméstica o móvil no ve nada.

Solo se desafían las navegaciones de página. Las imágenes, hojas de estilo, scripts, llamadas a API y envíos de formularios pasan sin tocar, así que ni tu tasa de aciertos de caché ni tus aplicaciones se ven afectadas. Los rastreadores verificados de los buscadores (Google, Bing, Yandex, Apple y DuckDuckGo) pasan siempre, comprobados según la red de la que realmente vienen y no según el nombre que envían: el desafío nunca te cuesta indexación.

El visitante desafiado ve durante un segundo aproximadamente una breve página de "Comprobando tu conexión" en su idioma (hay siete incluidos y el resto recibe inglés), y después la página que pidió. La página de comprobación se sirve como 503 con noindex, de modo que nunca puede acabar en los resultados de búsqueda. A quien la supera no se le vuelve a preguntar durante 30 minutos, y la cookie de acceso está ligada a su dirección y su navegador, así que no se puede copiar a otra máquina.

El modo todos hace pasar por la comprobación la primera página vista de cada visitante nuevo. Es una palanca para mitad de un ataque, no un ajuste para los días normales, y el panel pide confirmación antes de activarlo.

Qué frenó y qué hay detrás

Ese es el techo de cualquier desafío JavaScript: un bot que maneja un navegador real puede ejecutar el script. Por eso el desafío es una capa entre varias del mismo edge. Un límite de tasa, fijado para toda la cuenta o por regla de entrega y contado por dirección de cliente, responde con un 429 a todo lo que supere su cupo, y eso es lo que encarece una flota de navegadores headless. El WAF inspecciona lo que llevan las peticiones, y las reglas por país y ASN cierran con un 403 una red de la que nunca quieres saber nada.

La tarjeta del desafío lleva sus propias estadísticas: desafíos servidos, desafíos superados, rastreadores verificados que pasaron, por qué se desafió a los visitantes y qué redes recibieron más desafíos, para la última hora, día, semana o mes. Una tasa de superación cercana a cero es el resultado que buscas: significa que lo que se frenó no eran personas.

Qué herramienta usar en cada caso

Páginas raspadas o inundadas por clientes que parecen navegadores: protección contra bots en modo visitantes de riesgo.

Un ataque en curso: el modo todos mientras dure, y después de vuelta a visitantes de riesgo.

Intentos de adivinar contraseñas en el login: un límite de tasa estricto en esa ruta y un CAPTCHA en el formulario.

Registros y mensajes de contacto de spam: un CAPTCHA o Turnstile en el formulario, verificado en el servidor, más un campo trampa.

Tráfico de una red a la que nunca das servicio: una regla por ASN o por país.

Contenido malicioso, como la inyección SQL: el WAF. El desafío comprueba quién pregunta, no lo que envía. Para las inundaciones de volumen, consulta la protección DDoS.