¿Por qué volver a verificar con CAPTCHA en una entrada de formulario fallida?

Si el sitio tiene un medio para saber que es el mismo usuario en la misma sesión, entonces no. Entonces, por ejemplo, dada una cookie o una sesión ssl, entonces parece correcto asumir que aún es un usuario humano (dentro de los límites de captcha).

Si solo es una cookie la que establece la sesión (es decir, se trata de http sin SSL), entonces asegúrate de que se agote el tiempo. Y deberías usar SSL de todos modos :-)

No. Pero entonces, ¿hubo alguna razón para solicitar un CAPTCHA en primer lugar?

Tomemos un ejemplo aleatorio de una plataforma que implementa CAPTCHA; por ejemplo, Stack Exchange. Lo que los sitios de Stack Exchange quieren es una colección de preguntas y respuestas de alta calidad sobre un tema en particular. No hay nada allí que requiera intrínsecamente a humanos proporcionar las preguntas y respuestas: solo necesitan ser buenos. Esta calidad de bondad está determinada y filtrada para después el contenido ha sido publicado por la comunidad de votantes y moderadores.

Tampoco hay garantía de que una vez que hayas determinado que el hardware de la capa 8 es un ser humano, estén predestinados para proporcionar un buen contenido. De hecho, esa es la forma más fácil de eludir los CAPTCHA del sitio web: encontrar a algunas personas pobres y no darles mucho dinero para que llenen los CAPTCHA por usted.

Por lo tanto, la implementación de CAPTCHA hace que sea más difícil para las personas (mucho más difícil, en algunos casos, ya que muchos mecanismos CAPTCHA son inaccesibles para las personas con dificultades visuales) para usar la plataforma, mientras que solo hace que sea un poco más difícil para las personas abusar del plataforma. A cambio, no obtiene información útil relacionada con su objetivo.

Creo que las principales razones son:

• Es el comportamiento predeterminado que funciona fuera de la caja. Si el programador debe recordar que se resolvió el captcha, tendrá que escribir código adicional. Y tiene que ser recordado de una manera que no pueda ser manipulada por el usuario (por ejemplo, la sesión), por lo que un < input type="hidden" > el campo con una bandera no es bueno.
• Después de que la validación de la información personal haya fallado una o dos veces y los usuarios tengan que volver a ingresar al captcha cada vez, se volverá realmente molesto. Por lo tanto, es más probable que las personas proporcionen datos personales reales en lugar de datos falsos. (Este elemento solo se aplica a la compañía que solicita información personal que no es estrictamente necesaria para ofrecer el servicio que el usuario está buscando).

En lo que respecta a la facilidad de uso de los nombres de usuario, sugiero verificarlos de inmediato con Ajax antes de enviar el formulario. Alternativamente, puedes usar direcciones de correo electrónico que son (en su mayoría) únicas.

Saber el nombre de usuario puede facilitar a un atacante descifrar contraseñas: un atacante inteligente, que no está interesado en una cuenta en particular, elegirá una contraseña y luego las fuerzas brutas a través de los nombres de usuario. Así que eso es algo que se debe tener en cuenta, a menos que tenga un directorio de usuarios público de todos modos. Incluso sin un directorio de usuarios, hay un conjunto de nombres de usuarios que probablemente son seleccionados por las personas. De modo que, de todos modos, se requiere un límite de velocidad para los intentos fallidos de inicio de sesión para evitar este tipo de ataque.

Eso dependerá completamente de cuál sea el propósito del formulario, es decir, qué tipo de información se recopila.

Un caso muy común es un reintento de inicio de sesión después de un inicio de sesión fallido en un sitio web. En este caso, el CAPTCHA tiene un doble propósito:

1. Hace que sea más difícil automatizar los intentos de inicio de sesión con un bot, por lo que es más difícil automatizar un ataque de adivinación de contraseña, y
2. Se está ralentizando los intentos de inicio de sesión; Haciendo un ataque de fuerza bruta en línea más difícil de montar. (Tenga en cuenta que esto no se debe dejar solo en el CAPTCHA, el sistema de autenticación backend debe tener un límite de velocidad y / o un máximo de intentos de inicio de sesión fallidos).

También es común que se deba volver a enviar el formulario completo si solo un campo es incorrecto. Realmente no hay una buena razón tecnológica para eso, no se trata de dar prioridad a la usabilidad. Uso de SSL, sesiones y tokens de protección CSRF la aplicación web puede saber de manera confiable que el usuario final resolvió el CAPTCHA en su primer intento, y luego no necesita CAPTCHA nuevamente, pero es más trabajo implementarlo correctamente.

La razón para cambiar siempre el desafío es hacer más difíciles los ataques de fuerza bruta. Imagina que el CAPTCHA no cambia después del primer intento fallido. Entonces, un pirata informático podría primero intentar manualmente rellenar el formulario, presentar el desafío correcto y luego iniciar una herramienta de fuerza bruta, que llena el cuadro de entrada de los captchas con el mismo valor haciendo que el CAPTCHA sea inútil. Es útil para crear, por ejemplo, la creación masiva de usuarios en servicios como, por ejemplo, gmail.