Un captcha no es un control de seguridad, es un reparto de costes

Todo desafío es una transacción. Gastas algo del tiempo y la paciencia de tus usuarios para comprar una reducción del abuso. Si el intercambio es bueno depende por completo de cómo se reparte el coste, y por defecto se reparte a quien parece raro, que rara vez es quien te está atacando.

1. Quién paga

Un captcha cobra a todos los que llegan, una vez por intento, en segundos y en frustración. El coste recae con más fuerza en quien usa lector de pantalla, quien tiene conexión lenta, quien tiene una discapacidad motriz, quien no tiene como primera lengua la del texto de la imagen, y quien está detrás de una VPN o de una dirección compartida que el motor de riesgo ya desconfía. Son grupos pequeños en porcentaje y están sobrerrepresentados entre tus usuarios más técnicos.

2. Por qué los falsos positivos se agrupan

Una puntuación de riesgo es un clasificador entrenado con una distribución que excluye los bordes. Un usuario con VPN corporativa, un navegador centrado en privacidad con aleatorización agresiva de huellas, un móvil en una red de operador donde miles comparten una dirección: todos parecen estadísticamente raros. Si el desafío salta con un umbral fijo, saltará constantemente para exactamente esa gente, y vivirán tu sitio como algo roto en lugar de protegido.

3. El coste de terceros que nadie presupuesta

Añadir reCAPTCHA no es gratis en términos de privacidad: es una petición a Google de cada visitante, en cada página donde carga el widget, y alimenta otro perfil. Para un sitio cuyo argumento es "puedes ver qué se recoge sobre ti", esa contradicción es cara en credibilidad. También es una cuestión legal en algunas jurisdicciones, donde un desafío que transfiere datos personales al exterior necesita una base que quizá no tengas.

4. Qué poner delante

• Límites de tasa con una clave de verdad. Por IP es el fácil y el equivocado en solitario: por cuenta, por sesión y por prefijo atrapan el abuso distribuido que el límite por IP deja pasar y dejan de castigar direcciones CGNAT compartidas.
• Prueba de trabajo. Un pequeño puzle en JavaScript cuesta CPU real por intento al atacante y unos cientos de milisegundos a un usuario legítimo. Sube el precio del volumen sin pedirle a nadie que demuestre ser humano.
• Desafíos basados en riesgo en lugar de indiscriminados. Solo cuando la puntuación, la velocidad o la acción lo justifiquen, y nunca en una lectura simple.
• Un segundo factor que el usuario ya tenga. Para acciones de cuenta, confirmar por correo o una passkey es más seguro y menos molesto que un puzle de imágenes.
• Turnstile o hCaptcha si necesitas una opción alojada: son no interactivos para casi todos, pero valida el token en el servidor y átalo a la acción, o habrás añadido un script de terceros para nada.

5. Mide el intercambio, no el bloqueo

Casi todos los equipos informan de cuánto abuso detuvieron y nunca miden cuánto costó el desafío. Instrumenta: tasa de finalización por formulario, tiempo hasta el envío, abandono en el paso del desafío y tickets que mencionan la verificación. Un desafío que bloquea el 90% de los intentos automatizados y pierde el 8% de las altas legítimas suele ser un mal negocio, y no puedes saberlo sin el segundo número.

6. La regla incómoda

Si una página se puede leer sin desafío, debería. Pon fricción en las acciones que generan valor para un atacante —crear cuenta, restablecer contraseña, pagar, enviar mensajes— y deja el descubrimiento en paz. Después acepta que algo de abuso pasará: la alternativa es pagarlo con los usuarios que no hicieron nada malo.

ipbox.one existe en parte para hacer visible ese intercambio: muestra las señales que un motor de riesgo usaría sobre tu propia conexión, que es a lo que suele reducirse el "por qué me piden verificación".