Proof of Work contra los bots: el cálculo que protege tu buzón

Cómo son los ataques de spam con bots

Los servicios de preguntas anónimas son un blanco perfecto para los bots. Se puede publicar sin registrar una cuenta y el anonimato está garantizado, así que para los atacantes el riesgo es muy bajo. Con un script de automatización, es posible enviar decenas de publicaciones fraudulentas por segundo.

Los ataques de spam con bots tienen objetivos variados. Entre ellos están el acoso a un usuario concreto (llenar su panel con una avalancha de mensajes agresivos), el spam publicitario (enviar en masa preguntas con enlaces a webs de citas o webs fraudulentas) y la denegación de servicio (sobrecargar el servidor para que el servicio se caiga).

La medida contra los bots más usada tradicionalmente es el CAPTCHA (verificación con imágenes). Es un sistema que pide leer letras deformadas o exige «selecciona todas las imágenes que contienen un semáforo». Pero el CAPTCHA tiene un defecto fatal: empeora muchísimo la experiencia del usuario. Si cada vez que intentas enviar una pregunta te piden una verificación con imágenes, muchos usuarios lo encuentran pesado y se van. El CAPTCHA destruye el valor de los servicios de preguntas anónimas: poder «enviar preguntas sin complicaciones».

La prueba de trabajo, un cambio de enfoque

La prueba de trabajo (Proof of Work, PoW) excluye a los bots con un enfoque totalmente distinto del CAPTCHA. En lugar de imponer una tarea a la persona, impone una tarea de cálculo al ordenador.

El mecanismo es sencillo. Al enviar una pregunta, el navegador (el lado del cliente) recibe del servidor una cadena aleatoria llamada «desafío». Para ese desafío, el navegador hace un cálculo para encontrar un valor llamado «nonce» que cumpla una condición concreta. En concreto, busca por fuerza bruta un nonce tal que el hash SHA-256 de la cadena que une el desafío y el nonce empiece con un número determinado de bits a cero.

Cuando encuentra un nonce que cumple la condición, lo envía al servidor junto con el texto de la pregunta. El servidor puede verificar el nonce con un solo cálculo de hash (la verificación es instantánea). Si no cumple la condición, la publicación se rechaza.

La clave de este mecanismo está en la «asimetría del cálculo». Encontrar el nonce correcto requiere muchos intentos, pero comprobar si el nonce encontrado es correcto basta con un solo cálculo. Esta asimetría dispara el coste para los bots.

Por qué excluye solo a los bots sin afectar a las personas

Lo habitual es fijar la dificultad de la prueba de trabajo (el número de bits a cero al principio) en un nivel que un móvil normal resuelva en unos 0,5-2 segundos. Después de escribir la pregunta y pulsar el botón Enviar, el cálculo se ejecuta en segundo plano y, en cuanto termina, se envía al servidor. El retraso que nota el usuario es prácticamente nulo o, como mucho, ve «Enviando...» durante 1-2 segundos.

El tiempo que tarda una persona en enviar 1 pregunta, contando el tiempo de pensarla y escribirla, es como mínimo de 30 segundos a varios minutos. Aunque durante ese tiempo se ejecute un cálculo de 0,5-2 segundos, apenas afecta a la experiencia.

En cambio, si un bot intenta enviar 100 preguntas por segundo, necesita 100 cálculos de prueba de trabajo. Si cada uno cuesta 1 segundo de cálculo, enviar 100 lleva 100 segundos. La velocidad de publicación del bot se divide por 100, y la rentabilidad del spam empeora muchísimo. Si el atacante usa hardware más potente, la velocidad de cálculo aumenta, pero ese coste (electricidad, servidores) crece en proporción a la escala del ataque.

Es decir, la prueba de trabajo es un mecanismo que convierte «un coste insignificante para las personas» en «un coste nada insignificante para los bots». Se puede decir que es una defensa elegante que aprovecha la diferencia de comportamiento entre las personas y los bots (las personas publican con poca frecuencia; los bots, con mucha).

Historia y aplicaciones de la prueba de trabajo

El concepto de prueba de trabajo tiene su origen en la propuesta que hicieron Cynthia Dwork y Moni Naor en 1993 como medida contra el correo basura. La idea era imponer un coste de cálculo al enviar correos para que los envíos masivos no salieran rentables.

Quien dio a conocer ampliamente este concepto fue Bitcoin, presentado por Satoshi Nakamoto en 2008. En Bitcoin, la prueba de trabajo se usa como mecanismo de consenso de la cadena de bloques. Los mineros hacen enormes cálculos para generar bloques, y ese coste de cálculo garantiza la seguridad de la red. Eso sí, la prueba de trabajo de Bitcoin es totalmente distinta de la del buzón de preguntas, tanto en objetivo como en escala. Bitcoin exige cálculos de varios minutos a decenas de minutos, mientras que en el buzón de preguntas son 1-2 segundos.

La prueba de trabajo del buzón de preguntas se parece más a la idea original contra el correo basura que a Bitcoin. El principio de «hacer que el spam no salga rentable subiendo el coste de los envíos masivos» es el mismo en el correo y en el buzón de preguntas.

Hashcash (propuesto por Adam Back en 1997) también pertenece a la misma línea: era un sistema que excluía el correo basura incluyendo una prueba de trabajo en la cabecera del correo. Se puede decir que la implementación de la prueba de trabajo del buzón de preguntas aplica esta idea de Hashcash a una aplicación web.

Los ataques que la prueba de trabajo no puede frenar y la defensa en capas

La prueba de trabajo es una medida potente contra los bots, pero por sí sola no puede frenar todos los ataques.

Primero, no sirve contra el acoso manual de una persona. La prueba de trabajo es un mecanismo para frenar las «publicaciones automáticas en masa», y no puede impedir que una persona envíe a mano preguntas inapropiadas una a una. Prepararse ante este tipo de actos es tarea de otros mecanismos, como la función de filtrado o la identificación con el ID del remitente.

Segundo, con una GPU potente se puede acelerar el cálculo de la prueba de trabajo. Un cálculo que en un móvil normal tarda 1 segundo podría completarse en pocos milisegundos con una GPU de última generación. Frente a esto, combinarla con la limitación de frecuencia, que pone un límite a la frecuencia de publicación desde un mismo origen, permite contener la frecuencia de publicación sea cual sea la velocidad de cálculo.

Tercero, también es habitual una configuración que combina la detección de bots con un campo trampa (honeypot, un campo de entrada falso que las personas no ven pero que los bots rellenan automáticamente). Aunque un bot supere la prueba de trabajo, si cae en el campo trampa, la publicación se rechaza.

El principio básico de la seguridad es la «defensa en profundidad» (Defense in Depth). En lugar de depender de una sola medida, se superponen varias para que, si se supera una capa, la siguiente lo detenga. La configuración que superpone la prueba de trabajo, la limitación de frecuencia, el campo trampa y el filtrado se usa mucho como línea de defensa para proteger el buzón de preguntas.