métodos alternativos de captcha

Question

Estoy buscando inspiración aquí. Necesito emplear algún tipo de verificación humana para mi sitio web, pero el método más común estos días (pedirle a los usuarios que escriban las letras & números que ven en una imagen en un cuadro de entrada de texto) parece un poco basura - Me resulta difícil a veces para averiguar cuáles son las letras & números.

¡Debe haber una manera mejor!

He tenido algunas ideas, la mejor parece ser mostrar a los usuarios una serie de imágenes (4-6), y pedirles que respondan una pregunta basada en los contenidos de las imágenes, tales como:

(muestra algunas formas geométricas) "¿Qué imagen tiene 3 lados?"

o

(muestra la imagen de los animales) "¿Qué animal puede volar?"

Esto tiene la ventaja de ser fácil de programar y, con suerte, fácil de pasar.

¿Alguien puede pensar en algún otro enfoque para este problema? ¿O posiblemente detectar defectos en el sistema descrito anteriormente? ¿Es posible hacer que estos sistemas sean más fáciles de pasar para los humanos y más difíciles de superar para los bots?

Answer 1

Aunque es un poco viejo, realmente encontré que KittenAuth es un enfoque de captcha divertido (y probablemente muy efectivo). Sin embargo, parece que solo hay uno demo on their contact page.

El problema con los enfoques basados ​​en imágenes puras (a diferencia de las imágenes de texto) es que básicamente se está evitando que los usuarios invidentes usen su sitio. El autor de KittenAuth reconoció esto en uno de los comentarios en su sitio.

Como pequeño jinete divertido a KittenAuth, this page tiene "10 de los peores captchas de todos los tiempos", incluyendo uno de mis favoritos:

Answer 2

trate de usar un sistema de pregunta de seguridad, donde una simple pregunta demanda una respuesta cognitiva simple. Por ejemplo, solicite a un usuario que responda la siguiente pregunta de ejemplo:

Tres automóviles en la calle pueden ver tres automóviles más. ¿Cuántos carros totales hay?

La tecnología no es tan avanzada como para que un robot sensible al ancho de banda sea capaz de responder a esa pregunta y, sin embargo, la pregunta es fácil de responder. Un usuario debe ingresar tres o tres para verificar que son humanos y no una máquina. Tendría que tener un banco de preguntas lo suficientemente grande como para que un bot simplemente no haga ping a su sitio mirando las preguntas para registrar para que pueda regresar con las respuestas disponibles.

Answer 3

Me gusta especialmente el ejemplo "qué animal puede volar". Simple & Efectivo.

Pero este tipo de cosas se pueden abusar. No sería difícil darle un sesgo cultural — o uno percibido.

Y, como austin cheney mostró, podría convertirse fácilmente en una especie de prueba de inteligencia, y tendría un problema de accesibilidad.

Answer 4

Intenta usar un proceso de envío basado en Ajax que se activa haciendo clic en un botón normal (no en un botón de envío), es muy fácil con jQuery.

Por lo que yo sé, los spambots no tienen javascript.

Si le preocupan los usuarios sin javascript habilitado, creo que está perfectamente bien que no puedan enviar el formulario. Si no pueden confiar en que habilite javascript en su sitio, no es su culpa que no puedan usar el sitio web en toda su extensión.

EDIT:

Véase también: Practical non-image based CAPTCHA approaches?

El problema, sin embargo, si alguien se dirige a su sitio a propósito, este tipo de técnica no funcionará.

Edit2:

no puedo proporcionar un enlace a un ejemplo de la vida real, pero me blogged de ello con un poco más de detalles, así que aquí tiene un código de ejemplo:

function submit_form() 
{ 
    jQuery.ajax({ 
     "type": "POST", // or GET 
     "url": 'action_url', // The url you wish to send the data to, the url you'd put in the "action" attribute on the form tag 
     "data": jQuery("form#the-form").serialize(), // The data you'll send. You need to get the form somehow. Easiest way is to give it an id. 
     "dataType": "json", // Only put this if the server sends the response in json format 
     "success": function(data, textStatus) // server responded with http status 200 
     { 
      // This is the happy case: server response has arrived 
     }, 
     "error": function(req, textStatus, errorThrown) // maybe HTTP 404 or HTTP 500 
     { 
      // something went wrong, the response didn't go through or the response didn't come. Handle the situation: let the user know, or something. 
     }, 
     "complete": function(req, textStatus) // This one always gets called anyway 
     { 
      // cleanup after yourself 
     } // XXX careful: if you put a comma here, IE6 will fail 
     }); 
}