Para que un sistema informático pueda dar acceso a un usuario, debemos comprobar que su contraseña es válida. Necesitamos, pues, construir y asegurar una base de datos con todas las contraseñas. Pero si un hacker consigue acceso a esa base de datos, ya no importa lo compleja que sea la contraseña de un usuario. Ese es el motivo por el que una base de datos de seguridad NUNCA debería guardar las contraseñas en “texto llano,” es decir, sin cifrar. Por desgracia, no siempre se cumple esta elemental recomendación de seguridad, y los usuarios pagan las consecuencias.

En los últimos años se han sucedido los casos de robos de grandes cantidades de contraseñas, no ya unas cuantas, sino todas las que permiten el acceso a un sistema. Uno de los casos más sonados fue el de la web RockYou. En diciembre de 2009, sufrió un ataque cuya consecuencia fue el robo de la información (usuario y contraseña en texto llano) correspondiente a más de 32 millones de usuarios^[2]. Los responsables de RockYou fueron duramente criticados por las circunstancias que se combinaron en este caso:

—A pesar de que la empresa de seguridad Imperva había avisado del ataque el día 4, la web no advirtió a sus usuarios hasta diez días después.

—La cantidad de contraseñas custodiadas en texto llano, sin ningún tipo de protección, era enorme, lo que lo convierte en uno de los mayores robos de contraseñas en texto llano de la historia.

—Las normas de seguridad de RockYou permitían crear contraseñas de tan sólo cinco caracteres, y recomendaba no utilizar “caracteres especiales” (es decir, no alfanuméricos)

—La web de RockYou permitía a sus clientes acceder a sus perfiles de otras redes sociales como Myspace, Hi5, Orkut o Facebook. Para ello, el cliente introducía las contraseñas de su perfil en dichas redes, y RockYou guardaba una copia. Sí, ha leído bien: RockYou guardaba contraseñas de otras redes sociales… y lo hacía en texto llano ^[3]

Imperva aprovechó la oportunidad para realizar un análisis de las contraseñas robadas. Las más utilizadas fueron términos sencillos como 123456, 12345, 123456789, Password e iloveyou ^[4]^[5].

Me gustaría poder decir que el caso RockYou marcó un antes y un después en el mundo de la seguridad online. En cierto modo así fue, pero no precisamente para bien. La lista de candidatos a esta especie de Festival del Epic Fail no hace más que aumentar desde entonces. En febrero de 2012, Microsoft abrió una investigación con relación a un ataque contra su tienda online en India. Un grupo llamado Evil Shadow Team consiguió, entre otras cosas, acceder y robar una lista de nombres de clientes y contraseñas, de nuevo en texto llano^[6].

De forma casi simultánea (aunque, que yo sepa, no relacionada), alguien consiguió acceso a datos sobre una gran cantidad de direcciones de correo electrónico y contraseñas de la web YouPorn, entre varios miles y más de un millón, según las fuentes. El daño potencial que puede hacer la revelación de datos de una de las cien webs más populares de Internet se une a la naturaleza íntima de sus contenidos. Ser usuario de YouPorn es algo totalmente legal y legítimo, pero a nadie le gustaría que sus hijos se enterasen.

En esa ocasión, la vía de entrada de los ladrones fue vergonzosamente fácil. Un programador de YouPorn creó un servicio de chat llamado YP Chat. Los archivos de registro (los llamados logs), usados por los programadores para poder comprobar fallos de seguridad, estaban ocultos a la vista, pero eran de acceso público y estaban sin cifrar^[7]. Alguien buscó, encontró y se llevó los logs, que contenían datos personales de los usuarios, incluidas direcciones email y contraseñas desde al menos 2007^[8]. Aunque un comunicado de YouPorn afirmó que no se habían accedido a datos de YouPorn.com^[9], el hecho es que el chat estaba enlazado por ellos. Eso significa que muchos usuarios de YouPorn habrán usado las mismas contraseñas y email en YP Chat; y puede que en otros servicios totalmente diferentes, ya que la precaución “una web, una contraseña” no siempre es seguida por el usuario medio.

No les sorprenderá el hecho de que más de la mitad de las direcciones de email correspondiesen a dominios de hotmail.com, yahoo.com y gmail.com, discretas y fáciles de crear. Lo que resulta increíble es que los usuarios utilizasen contraseñas débiles para el acceso a un servicio tan íntimo y privado. La contraseña más frecuente, utilizada por un 9% del total de usuarios de YouPorn, es 123456. La segunda más frecuente es 123456789 (por lo visto, los usuarios interpretan a su manera la sugerencia de hacer contraseñas largas). Por supuesto, no podían faltar otros sospechosos habituales como 12345, 1234, password y qwerty^[10].

Cuatro meses después de la intrusión de YouPorn, el 12 de julio de 2012, el famoso hacker Kevin Mitnick anunció que un servicio perteneciente a la empresa Yahoo! había sido comprometido^[11]. La empresa se apresuró a arreglar el fallo, que atribuyó a un antiguo fichero propiedad de la Associated Content, ahora integrada en Yahoo^[12]. La autoría fue reivindicada por el grupo D33Ds, quienes publicaron en una web los nombres de 450 000 usuarios y contraseñas en texto llano^[13]. Poco tardó el experto en seguridad sueco Anders Nilsson en analizar el botín. Las contraseñas más habituales resultaron ser (sorpresa, sorpresa) 123456, password, welcome, ninja y abc123^[14]. Una contraseña que llamó especialmente la atención, cuando fue mencionada en una web española sobre seguridad, era mercadona ^[15].

Y no fueron los únicos casos. Julio de 2012 fue un mes récord en las contraseñas robadas en masa:

—Foros nvidia (12/7): 390 000 usuarios, número de contraseñas desconocido ^[18]^[19].

—Pinterest (5 a 16/7): Número desconocido de usuarios afectados por un hacking contra sus cuentas que, según algunos indicios, pudo comenzar en marzo^[20].

—Gamingo (6/7): 8 200 000 contraseñas, robadas en febrero y hechas públicas en julio ^[21]^[22]^[23]

Y la lista sigue y sigue: Philips^[24], AMD^[25], Blizzard^[26], ITWallStreet.com^[27], RevTT^[28], el registro de dominios de Perú^[29], el gobierno ruso^[30], Adobe^[31]… mejor paramos aquí. Lo que sorprende es que entre las víctimas de hacks masivos se encuentran algunas de las empresas más tecnificadas del mundo. No son unos pardillos precisamente.

¿Cómo es posible que los hackers tengan acceso a tantas contraseñas? En contra de lo que pueda parecer, los atacantes no se dedican a buscar el valioso archivo de contraseñas, copiarlo y salir corriendo a estilo Indiana Jones. No tienen que devanarse los sesos buscando privilegios de administrador, adivinando la contraseña maestra o ejecutando trucos de película. En la mayoría de los casos, se limitan a engañar al sistema mediante una técnica denominada Inyección SQL que pasa por “inyectar” información que el sistema interpreta erróneamente como órdenes legítimas.

Un ejemplo real, tomado de la Wikipedia, nos ayudará a entenderlo^[32]. Supongamos que una página web nos pide el nombre de usuario. El código SQL usado por el programador que usó el programador es:

En esta consulta, el sistema seleccionará los registros para los cuales nombre coincida con la entrada del usuario (nombreUsuario). Si éste teclea la palabra Alicia, la orden que recibe el sistema es:

Esa orden hará que la base de datos busque todos los registros con nombre Alicia. Hasta aquí todo normal. Pero supongamos que el atacante teclea esto:

SELECT * FROM usuarios WHERE nombre = ‘’Alicia’;

DROP TABLE usuarios;

SELECT * FROM datos WHERE nombre LIKE '%';

Ahora, en lugar de una línea de instrucciones, tenemos tres. Las dos últimas han sido “inyectadas” en el sistema, que hará esto:

—Seleccionar toda la tabla de datos (que en condiciones normales no debería estar accesible al usuario)

Es algo así como si un guardia de seguridad me interceptase en la puerta. El guardia me pregunta por mi nombre, y yo respondo diciendo “mi nombre es Arturo Dametucartera”. El guardia cree que el apellido es una orden y me entrega su cartera. Estúpido, ¿verdad? Pues así se roban contraseñas a millones. En el caso del guardia de seguridad, bastaría con contratar a alguien menos tonto, y por lo que corresponde a la inyección SQL existen formas de mitigar sus efectos. Ahora bien, si la web no ha tomado en serio este tipo de ataques (sea por desconocimiento, ignorancia, negligencia, o sencillamente para ahorrar), tarde o temprano un hacker efectuará una inyección SQL con éxito y logrará acceso a información confidencial, como por ejemplo la lista de usuarios y contraseñas.

Una solución al problema de tener un archivo de contraseñas consiste en no tener un archivo de contraseñas, es decir, no guardar las contraseñas en su forma original. En su lugar, se guardan datos que están relacionados con las contraseñas pero que no revelan ninguna información sobre ellas. Voy a ponerles un ejemplo sencillo. Supongamos que yo deseo acceder a un sistema mediante el uso de mi número de DNI. Llego a la entrada, y de repente tengo miedo de que, al sacar mi documento de identidad de la cartera, alguien pueda copiar o escuchar el número. Una opción para evitarlo podría ser comprobar tan sólo la letra final, que depende del número completo. Así, yo le digo al vigilante de la entrada “mi letra del DNI es la V,” él lo comprueba y me deja pasar. De ese modo, he demostrado que conozco un secreto sin revelarlo.

En la práctica, la letra del DNI no resulta útil para este fin. El motivo es que el número de letras es escaso y predecible. En realidad la letra del DNI se ideó con otros fines (fundamentalmente, para evitar que alguien falsifique un documento con un DNI inventado sobre la marcha). Pero la idea es buena, y podríamos utilizarla para comparar contraseñas sin revelarlas. Para ello, nada mejor que las llamadas funciones hash (una palabra inglesa que significa condensado, o destilado). Se toma un texto o mensaje cualquiera M y se le aplica una transformación representada mediante la función H, de forma que el resultado h=H(M) es el destilado o hash del mensaje.

En ocasiones, el hash h se utiliza para representar un mensaje M de mucho mayor tamaño, lo que resulta muy útil, por ejemplo, en los casos de firma digital. Pero también tienen aplicación para ocultar contraseñas, ya que las propiedades anteriormente mencionadas me permitirán asociar un único valor hash a cada contraseña.

Una empresa con conciencia de seguridad tomaría todas las contraseñas de los usuarios, sometería cada una a la función hash, y guardaría el resultado. Cuando el usuario introduzca una contraseña C, el sistema usará una función hash H y determinará su valor: h=H(C). A continuación, el sistema consultará la base de datos de hashes. Si el hash que corresponde a la contraseña C coincide con h, eso significa que el usuario ha tecleado una contraseña válida. Ya no hace falta almacenar las contraseñas. En teoría, un ladrón que se llevase la base de datos de hashes no podría obtener ninguna información sobre las contraseñas.

El uso de funciones hash para protección de contraseñas debería ser política habitual en todo sistema de acceso con gran número de usuarios, pero aún hay sistemas donde no se utiliza. En el caso de Billabong.com, de julio de 2012, se reveló que las 35 000 contraseñas capturadas estaban en texto llano ^[17b].

Incluso los grandes cometen este tipo de errores de vez en cuando. No tienen más que preguntarle a Sony. El 20 de abril de 2011, PlayStation Network, la red de juegos de Sony, tuvo que ser desconectada durante casi un mes tras el descubrimiento que los datos personales de sus usuarios habían sido robados. El número de clientes afectados, más de 77 millones, lo convirtió en uno de los mayores casos sobre robo de información de usuarios de la historia. Por fortuna, la información sobre tarjetas de crédito estaba cifrada de modo independiente. En cuanto a la información sobre contraseñas, Sony afirmó que estaban protegidas con una función hash, aunque no dio más detalles^[33]. Se ignora qué uso se dio a la información robada, pero en caso de que se hubiese recuperado información sobre las contraseñas o los números de tarjetas, se hubiera filtrado a Internet como en otros casos.

Aunque Sony incrementó la seguridad de su red de juegos, no pareció haber aprendido la lección. Acosado por grupos hackers que le habían declarado la guerra, el gigante japonés sufrió una oleada de ataques. En junio de 2011, la web de Sony Pictures sufrió el robo de la información privada correspondiente a más de un millón de personas, incluyendo direcciones de email y contraseñas en texto llano, es decir, sin protección hash alguna. El grupo LulzSec, que se atribuyó la autoría del ataque, colgó parte de esa información en el portal The Pirate Bay, fácilmente accesible para cualquier usuario de Torrent ^[34]. Un tercer ataque, en octubre, permitió el acceso a 93 000 cuentas de PlayStation Network y Sony Online Entertainment. En este caso, los atacantes probaron técnicas de fuerza bruta y consiguieron acceder a cuentas de usuarios con contraseñas débiles ^[35].

Aunque el uso de valores de hash en lugar de contraseñas aumenta la seguridad de un sistema, no es la panacea universal y existen diversos fallos explotables por un atacante con recursos. El más eficaz sigue siendo el hecho de que algunos usuarios utilicen contraseñas sencillas de forma habitual.

Digamos que la contraseña password tiene como hash la cadena alfanumérica 1c24A, esto es, H(password)=1c24A. Eso significa que, si en la base de datos de funciones hash que acabamos de robar, aparece un hash igual a 1c24A, ya sabemos que la contraseña correspondiente es password.

Un atacante podría tomar un “diccionario” compuesto por las contraseñas y palabras más comunes, y aplicar la función hash H a cada una de sus términos; luego comprobaría esos valores con los que aparecen en la base de datos robada. Hay herramientas informáticas capaces de comprobar millones de hashes por segundo, como el programa John the Ripper ^[36], usado habitualmente por los administradores de sistemas para comprobar la fortaleza de las contraseñas de usuario.

Pueden ver ustedes un ejemplo del uso de esta herramienta, y en general del proceso de ruptura de contraseñas, en las referencias^[37] y ^[38]. Recientemente fue modificado para aprovechar la potencia de los procesadores GPU (que controlan las tarjetas gráficas), haciéndolo especialmente útil contra las funciones hash que están diseñadas para ser lentas, y por tanto son difíciles de asaltar en un ataque de fuerza bruta ^[39].

Ha habido casos sonados de ataques contra bases de datos de contraseñas protegidas con hash. El caso Gamingo, en el que más de ocho millones de contraseñas fueron robadas en julio de 2012, fue un ejemplo típico. En diciembre de 2011 hubo otra intrusión. En esa ocasión, la víctima fue nada menos que Stratfor Global Intelligence, una empresa dedicada a la recogida y procesado de datos de inteligencia. Algunos la consideran una CIA privada, aunque oficialmente se dedica a realizar análisis geopolíticos: nuestro fin es simple, hacer que la complejidad del mundo sea comprensible para un lector inteligente, al margen de ideología, agenda y prejuicios nacionales^[40]. Según parece, pretenden ser al mundo de la inteligencia privada lo que Blackwater es al de los mercenarios. No todos comparten esa opinión, y hay quien afirma que Stratfor “es tan sólo [el diario] The Economist con una semana de retraso y mucho más caro”. ^[41]

Sea cual sea nuestra opinión sobre su naturaleza o fines, se supone que una agencia como Stratfor debería mantener una férrea seguridad en sus sistemas. Por dicho motivo, sorprendió que en Navidad de 2011 el propio fundador reconociese que su empresa había sufrido una intrusión informática. Los atacantes consiguieron una lista de miembros y clientes, incluyendo números de tarjetas de crédito y, como se reconoció posteriormente, casi un millón de direcciones de email y contraseñas de acceso. Las contraseñas se guardaban en forma de hash, para lo cual utilizaron la función de hash MD5. Ese robo de contraseñas fue tan sólo una parte dentro de la masiva filtración de correos electrónicos de Stratfor apodada The GI Files y desvelada a finales de febrero de 2012 por Wikileaks^[42].

Un ataque similar fue llevado a cabo sobre la web de juego Battlefield Heroes en junio de 2011. El grupo de hackers conocido como LulzSec afirmó haberlo hecho como despedida y cierre. La información filtrada incluía datos sobre 500 000 direcciones de e-mail, contraseña, números de teléfono y fechas de nacimiento^[43]. El sistema usado para proteger las contraseñas era nuevamente la ya obsoleta función de hash MD5. El “paquete de despedida” de LulzSec incluía saqueos procedentes de otras fuentes como hackforum.net (200 000 nombres de usuario y contraseñas) e incluso la librería online de la OTAN (12 000 usuarios)^[44].

La red social LinkedIn fue otro caso de libro. Sus contraseñas estaban ocultas gracias a la función de hash SHA-1 considerada más segura que MD5 no sólo por su fortaleza criptoanalítica sino también por la mayor longitud de sus valores hash (160 frente a los 128 de MD5). El 6 de junio de 2012 sucedió lo inevitable: aproximadamente 6 500 000 contraseñas de sus usuarios fueron colgadas en una página web^[45]. Para ser exacto, fue el valor hash de esas funciones lo que se hizo pública, y en este caso no se incluyó información sobre cuentas de email. Se especula con la posibilidad de que los ladrones hayan publicado la lista de hashes para que otros hackers les ayudasen en su descifrado^[46]. Eso significa que los 6,5 millones de hashes son los valores únicos (no repetidos). Es posible que algunos usuarios usen la misma contraseña, con lo que el número total de cuentas comprometidas puede ser mucho mayor. En un comunicado en el que reconocían el robo de información, la red social pedía a sus miembros que cambiasen su contraseña a otra que fuese difícil y rara (al menos 10 caracteres complejos)^[47].

En adición a los 6,5 millones de hashes de LinkedIn, la base de datos expuesta incluía aproximadamente un millón y medio de valores hash (y lo que es peor, nombres de usuario) correspondientes a los clientes de eHarmony, un portal online de citas. La seguridad de eHarmony era evidentemente menor, ya que además de permitir contraseñas cortas usaba como función de hash MD5, considerada como inferior a SHA-1. Al igual que LinkedIn, eHarmony reconoció casi de inmediato la gravedad del ataque^[48] y recomendaron a sus usuarios el cambio de contraseña a una más robusta. Para rematar la faena, también había información sobre unos 8000 usuarios de last.fm^[49].

1) MISIÓN: PROTEGER LAS CONTRASEÑAS