2) UNA PIZCA DE SAL

El hecho es que ni siquiera el uso de funciones hash proporciona protección suficiente para un sistema de contraseñas. Los atacantes cuentan a su favor con una gran potencia de computación, proveniente no sólo de la enorme capacidad de cálculo de los ordenadores actuales sino también del hecho de que cada vez se coordinan mejor. Una base de datos puede ser analizada por centenares de personas trabajando pacientemente durante meses, logrando resultados que una década antes eran tarea de un superordenador. Incluso puede usarse Google para buscar el hash correspondiente^[50].

Afortunadamente, hay otras técnicas de defensa. El administrador del sistema puede aumentar el nivel de seguridad añadiendo “sal” al sistema. Como en las aplicaciones culinarias, la sal da sabor al guiso. En este caso, lo que se denomina “sal” es una pequeña cadena de bits que se añaden a la contraseña antes de ejecutar la función hash. De este modo, lo que guarda el sistema no es H(contraseña) sino H(contraseña+sal). Las características de las funciones hash hacen que incluso valores muy próximos de sal den como resultado valores hash muy distintos; por ejemplo:

Ahora el contrincante lo tiene más difícil, ya que a cada elemento de su diccionario tendrá que añadirle muchos valores de sal hasta encontrar el correcto. Una ventaja del uso de sal es que incluso usuarios que, por azar, utilicen el mismo valor de la contraseña, tendrán valores hash muy diferentes. La base de datos de valores hash ya no tendrá valores repetidos, algo que constituye un indicativo del uso de contraseñas idénticas y frecuentes.

En el caso del robo de contraseñas en LinkedIn, los responsables tranquilizaron a sus clientes diciéndoles que “hemos incrementado nuestras medidas de seguridad mediante una capa adicional de protección técnica conocida como ‘sal’ para asegurar mejor su información”^[51]. Un aviso posterior parece sugerir que el cambio de hash a hash+sal se llevó a cabo antes del robo de datos del 6 de junio, pero no queda claro^[52]. Tampoco eHarmony usaba sal^[53].

Bien utilizado, el uso de sal es una herramienta muy útil para la defensa, pero tampoco es el remedio definitivo. Una estrategia que puede utilizar el atacante es probar conjuntos de contraseñas probables, cada una de ellas con todos los posibles valores de sal. El ataque será mucho más lento que en el caso de hash sin sal, pero en la práctica es factible gracias a dos elementos. El primero es la potencia de cálculo accesible a los atacantes: un ordenador personal con una buena tarjeta gráfica puede comprobar contraseñas al ritmo de miles de millones por segundo, y programas como el mencionado John the Ripper han sido modificados para probar grandes cantidades de valores de sal^[54].

En segundo lugar, hay aplicaciones informáticas que usan poca sal. En las versiones más antiguas de Unix, la sal disponible tenía 12 bits de longitud, lo que significa que solamente puede adoptar 4096 valores distintos. Eso complica el trabajo a un atacante, pero no lo hace inviable. Los sistemas más robustos utilizan funciones hash con granos de sal más gordos, entre 48 y 128 bits; sal gruesa, si me permiten la expresión.

Todo ello hace que el ataque a un sistema que use hash y “sal fina”, si no inmediato, sea al menos factible. Las contraseñas fáciles de atacar (sea por su sencillez o por su corta longitud) resistirán algo más gracias a la sal, pero incluso si se utilizan funciones hash y sal, un usuario que utilice una contraseña débil sigue siendo vulnerable. Armados con una lista de contraseñas de uso común, los atacantes no tienen más que probarlas combinándolas con todos los valores posibles de sal para obtener acceso a al menos algunas de las cuentas.

Tenemos ejemplos de ello. Los datos publicados hasta la fecha no proporcionan más información, pero una consulta al Tech Herald me ha permitido confirmar que el sistema de hash MD5 usado por Stratfor no contaba con ningún tipo de sal. Un año antes, en diciembre de 2010, la red Gawker Media sufrió un ataque en el que alguien robó la base de datos con más de un millón de contraseñas y nombres de usuario. La base de datos estaba protegida mediante hash y sal, pero los hackers la descifraron e hicieron pública^[55]. Eso permitió descubrir cuáles son las contraseñas más usadas por sus usuarios: 123456, password, 12345678, qwerty, abc123.

Dos meses después, un ataque similar a rootkit.com desveló las contraseñas más habituales de sus usuarios: 123456, password, rootkit, 111111, 12345678^[56]. La empresa Duo Security efectuó un análisis de la base de datos de contraseñas robada en el caso Gawker Media. Utilizando el programa John the Ripper durante unas horas en un ordenador de ocho núcleos, consiguieron extraer más de 400 000 contraseñas, de un total de 1 300 000, y eso a pesar de que el sistema de protección utilizaba sal.

El 10 de julio de 2012, la red social Formspring sufrió el robo de 420 000 hashes correspondientes a contraseñas de sus usuarios. La función hash utilizada era la SHA-256, y también empleaban sal, lo que significa que Formspring hizo bien sus deberes (salvo por el detalle de dejarse robar información)^[57]. En estos casos, el sistema es parcialmente seguro porque los usuarios de contraseñas fuertes estarán protegidos.

La única defensa eficaz contra una intrusión de este tipo consiste en deshabilitar todas las contraseñas, una medida que requiere valor porque significa molestar a millones de usuarios y enviarles el mensaje de que el sistema es inseguro (Formspring lo hizo); y, en segundo lugar, implementar en el sistema un comprobador que rechace las contraseñas cortas o débiles.

Además de ello, Formspring anunció que cambiaría la función hash de SHA-256 a bcrypt, una función mucho más útil en estos casos porque es más lenta. Sí, han leído bien. Por lo general, los criptólogos buscan funciones que no solamente sean eficaces y robustas, sino también rápidas, y las funciones hash habitualmente utilizadas se diseñan de forma eficiente. Una web con millares de accesos por segundo necesita que las funciones hash necesarias para la comprobación de las contraseñas sean rápidas y no consuman demasiados recursos.

Paradójicamente, ahora lento significa bueno. El atacante va a probar gran número de valores hash, miles de millones, y cuanto más rápida sea la función hash más eficiente será su trabajo. El objetivo ahora es que a un usuario legítimo, que introduce su contraseña para acceder al sistema, no le reporte ninguna diferencia apreciable, pero al mismo tiempo ralentice considerablemente el esfuerzo necesario para un ataque a gran escala. Por eso tiene sentido la decisión de Formspring de decantarse por bcrypt. No solamente es mucho más lenta que las del grupo SHA, sino que su grado de lentitud de ajustable: si dentro de unos años la potencia de los microprocesadores se ha hecho diez veces mayor, podemos ajustar bcrypt para que sea diez veces más lento^[58].