¿Cómo puede garantizar la interacción humana con su aplicación además de aplicar un sistema captcha?

(Perdón por una respuesta prolongada, generalmente es un problema no trivial que merece algo de reflexión)

Prefiero pensar en CAPTCHA como un mecanismo alternativo para cuando un sistema piensa que un usuario podría estar haciendo algo como un robot. Esto es contrario a cómo se implementan los CAPTCHA (es decir, asumir que todos los usuarios son robots y deben demostrar que son humanos). Parece tonto tratar a los usuarios como robots, ya que la mayoría de los robots tienen intenciones muy diferentes, y para que un robot coincida con nuestros usuarios humanos tomará bastante trabajo (francamente, la mayoría de los spammers no pasarán demasiado tiempo tratando de hacer coincidir).

Dicho esto, veamos qué harán potencialmente nuestros usuarios humanos en el proceso de registrarse en un sitio web:

  • Nuestro usuario creará una sola cuenta y luego iniciará sesión (o verificará, etc.)
  • Por lo general, podemos suponer que los usuarios no visitan desde una IP de centro de datos, pero hay algunas situaciones en las que los servidores proxy son útiles
  • Probablemente hayan venido de un motor de búsqueda u otro punto de nuestro sitio web (tal vez esta sea nuestra página de inicio o una página de contenido)
  • Una vez que comienzan a completar nuestro formulario, podemos hacer algunas cosas como hacer ping al servidor para ver si se ha tomado el nombre de usuario que desean usar, o verificar si la dirección de correo electrónico ya existe en nuestro sistema
  • Sabemos que los usuarios probablemente presionen “enter” o hagan clic físicamente en un botón de envío cuando hayan terminado.
  • Nuestro usuario utilizará un navegador real que tiene su propio conjunto de peculiaridades.

Vamos a contrastar esto con un robot:

  • Nuestro robot probablemente intentará crear 2 o 3 cuentas diferentes mientras visita desde una sola IP
  • Es posible que la visita del robot no haya tenido el deseo de mirar alrededor de nuestro sitio web, por lo que probablemente llegue directamente a nuestra página con un formulario de registro (para obtener el token CSRF), y luego PUBLICAR en nuestro punto final de registro
  • Además, nuestro robot probablemente no se molestó en ejecutar ninguno de nuestros JS, renderizar nuestras imágenes o recuperar nuestros archivos CSS y, por lo tanto, no preguntó si se tomó un nombre de usuario antes de enviar el formulario
  • En el caso de que nuestro robot cargue nuestras imágenes y otros medios, apuesto a que no maneja ETags u otros encabezados de almacenamiento en caché correctamente.

Dado que los perfiles tienen algunas características distintas, ahora podemos evaluar la probabilidad de que un usuario sea un robot y, si creemos que lo son, solicitar un CAPTCHA. En última instancia, no deberíamos mostrar a los humanos nuestro CAPTCHA y solo robots. Algunos factores que podemos observar al ajustar la agresividad de nuestros perfiles:

  • No todas las formas y acciones tienen el mismo valor. El proceso de registrarse por sí mismo puede no proporcionar mucho valor al spammer. Si nuestro spammer necesita una cuenta para publicar un comentario, entonces el comentario es el objetivo, no el registro. Dado que la mayoría de las personas que se registrarán se involucrarán de varias maneras antes de publicar un comentario, podemos tener perfiles aún más agresivos que los robots casi nunca replicarán durante el proceso de comentarios, pero los usuarios reales casi siempre pasarán. (En serio, ¿con qué frecuencia visita la URL exacta de la página de registro, luego escribe la URL de la página de envío del mensaje y redacta un mensaje completo con enlaces e imágenes en 35 segundos?)
  • Si permitimos que robots sofisticados interactúen con nuestro servicio e intenten spam, podemos identificar retroactivamente patrones que solo los robots realizan y luego buscar acciones adicionales que validen nuestro filtro y luego soliciten un CAPTCHA cuando intenten una acción que genere spam . O…
  • Puede ser valioso no prohibir de inmediato estos robots o darles indicios de sospecha, sino “ocultar” su contenido con la esperanza de que continúen realizando acciones de spam mientras nuestro sistema puede recopilar e identificar más patrones (en última instancia, hay habrá muy pocos robots que lleguen a este punto, por lo que es aceptable alguna intervención humana)

La mayoría de los sitios web suponen que todos los usuarios registrados son reales y humanos, por lo que colocan CAPTCHA en la fase de creación de la cuenta para verificar esto. Pero en realidad, la mayoría de los spammers solo necesitan registrarse para realizar otras acciones de spam. En lugar de castigar a nuestros usuarios que se involucran naturalmente con nuestro servicio, deberíamos intentar identificar patrones en los que los usuarios no se involucren como lo hacen otros usuarios humanos y luego solicitar la validación en ese punto.

Puede aleatorizar sus nombres de campo de formulario. Un bot no se ajustará a los cambios y, cosecuencialmente, fallará la validación. Algunos marcos como el mar lo harán por defecto.

Todavía hay un pequeño costo para el usuario en que las “características” del navegador, como el autocompletado, serán negadas por la aleatorización.

He usado flash como GUI y ‘flash remoto’ en php para generar la transacción de la base de datos. Esto dificulta que un ‘bot’ se conecte a la interfaz, pero no es imposible que un atacante determinado se conecte manualmente al código php.