Los sitios web que no amaban a las contraseñas

Lamentablemente cada vez son más frecuentes las noticias de fugas de información, ataques a servicios en Internet, y en muchos casos comprobamos como millones de contraseñas terminan expuestas de forma pública. Las buenas prácticas y un poco de lógica nos dice que todos los servicios deberían almacenar las contraseñas de sus usuarios de forma segura, pero… ¿se cumple realmente esta regla en todos los casos?

Todos los usuarios nos enfrentamos diariamente con diferentes formularios de autenticación. Incluso de vez en cuando nos registramos en un sitio nuevo y debemos proceder con un nuevo proceso de alta. Ya sabemos, nombre, correo, algunos otros datos en función del tipo que servicio, y por supuesto la ya clásica contraseña.

A los usuarios se nos recomienda (y hasta se nos obliga) que la contraseña que creemos sea segura, de una determinada longitud, con caracteres en mayúscula y minúscula, con números, etc. Además, se nos recuerda que no debemos dejar la contraseña apuntada en un sitio que la pueda ver todo el mundo (evitar el clásico post-it con la clave apuntada). ¿Pero estamos seguros que tras introducir esa compleja contraseña el servicio la trata y mantiene con el mismo cuidado con el que se nos insta a nosotros? Ya que ideal y técnicamente no deberían guardar la contraseña, sino una imagen (en sentido funcional) irreversible.

Está claro que nuestra clave, de una forma u otra, pasa a formar parte de una base de datos. Queremos pensar que siempre se almacena de una forma segura. Pero… ¿es siempre cierto? ¿Todos los programadores piensan en la seguridad cuando desarrollan?

No es menos frecuente que tras el proceso de alta recibamos un correo indicando que el alta en el servicio se ha llevado a cabo de forma correcta. Pero llama la atención cuando en ese mismo mensaje se nos indica en texto claro la contraseña que hemos introducido. Desde luego esto no es una buena práctica. Es un pecado mortal de consecuencias catastróficas y un indicativo directo de la postura en materia de seguridad de la organización. En pocas palabras, un correo con una contraseña en texto claro podría indicar una compañía con una cultura de seguridad potencialmente baja.

Por otra parte, esto nos puede hacer sospechar que nuestra contraseña se ha guardado en texto plano. Es cierto que el mensaje puede construirse y enviarse antes de almacenarla de forma segura en la base de datos, pero desde luego no es un buen síntoma. La contraseña en texto claro no debería aparecer en ningún sitio, ni mucho menos enviarse en un correo electrónico.

Las buenas prácticas de gestión de contraseñas dictaminan que una contraseña nunca, repetimos, nunca debe ser almacenada en texto plano.

Cada vez que recibo un mail con una contraseña en claro un escalofrío recorre mi cuerpo. ¿Se habrá guardado esa contraseña de forma correcta?

El proyecto OWASP (Open Web Application Security Project) tiene como objetivo ofrecer una metodología, de libre acceso y utilización, que pueda ser utilizada como material de referencia por parte de los arquitectos de software, desarrolladores, fabricantes y profesionales de la seguridad involucrados en el diseño, desarrollo, despliegue y verificación de la seguridad de las aplicaciones y servicios web.

En este sentido la OWASP es muy clara, y ofrece claros consejos a seguir sobre el almacenamiento de contraseñas:

La primera recomendación pasa por no limitar ni el conjunto de caracteres ni la longitud máxima de la contraseña.

Por otra parte, la forma más recomendable para almacenar una contraseña es mediante el uso de funciones hash. Hay que aclarar que una función hash no cifra el texto, sino que crea un resumen o “firma” del mismo. De forma que al introducir posteriormente la contraseña, se puede comprobar si ese resumen coincide con el de la contraseña introducida.

Un hash es una función criptográfica que produce una salida de longitud fija a partir de una entrada arbitrariamente larga. Un buen “hash” debe cumplir las siguientes propiedades:

a) El resultado final no debe dejar traslucir ninguna información sobre los datos originales.

b) Dado un resultado determinado, no hay otro sistema aparte de la fuerza bruta que genere datos de entrada capaces de producir dicho resultado.

c) Dados unos datos de entrada y su “hash“, no debe haber un atajo (aparte de la fuerza bruta) para generar otros datos de entrada distintos y con el mismo “hash“.

Una característica fundamental de las funciones hash, es que teniendo el hash no es posible conseguir la contraseña original. Pero sí se puede intentar probar diferentes contraseñas hasta que alguna coincida con el hash dado. Pura fuerza bruta.

Existen muchos algoritmos de “hash“, pero lo más recomendable en la actualidad pasa por usar la familia SHA2 como mínimo. La OWASP recomienda el uso de las funciones PDKDF2 o scrypt.

Lo que sí que existen son las conocidas tablas arcoíris (“rainbow tables“) para diferentes funciones, básicamente son listas de millones de hashes y sus correspondientes contraseñas. De esta forma basta realizar una búsqueda en un archivo para obtener la contraseña. Podemos encontrar una amplia lista de tablas arcoíris en:

Para complicar los ataques por diccionario, surge la necesidad de emplear hash con sal o “salt“. Que no es sino una cadena aleatoria que se añade al principio o final de la contraseña antes de crear el hash. Para cada contraseña se debe usar un salt diferente. Así se consigue eliminar la posibilidad de que el resultado pueda buscarse en alguna tabla rainbow.

Resumiendo, se deben usar funciones irreversibles (tipo PDKDF2 o scrypt) y aplicar una sal de gran tamaño (64bits) en la fórmula de generación de la “imagen” (de nuevo, en sentido matemático).

Tratando con contraseñas, no podemos olvidar a la madre de todos los problemas: el método de regeneración de contraseñas. Según nuestra experiencia en la realización de auditorías es en este punto en el que suelen fallar muchas de las aplicaciones y sistemas que auditamos. Una debilidad en este aspecto puede permitir a un atacante acceder a la cuenta de cualquier usuario. De ahí la importancia de que este proceso se realice correctamente.

Es una funcionalidad que no se puede evitar, todos los sistemas tienen que tener un método para cuando hayamos olvidado nuestra contraseña. Y es que con la gran cantidad de contraseñas que mantenemos actualmente, esto suele ocurrir con frecuencia.

Existen diferentes estrategias para llevar esto a cabo. Pero siempre se debe generar una contraseña nueva. Como dijimos anteriormente las contraseñas nunca deben ser almacenadas en texto plano. Por lo que el servicio no puede tener capacidad para saber nuestra contraseña anterior. En caso de que al tratar de recuperar el acceso al servicio tras haber olvidado la contraseña se nos envíe la que habíamos introducido originalmente deben saltar todas las alarmas. Ningún sistema correctamente desarrollado puede acceder a la contraseña original en texto plano. Por desgracia ocurre más veces de lo que quisiéramos.

Otro punto débil, todavía empleado en algunos sitios, es el de las preguntas de seguridad. Las preguntas secretas siempre han resultado un método polémico para la recuperación de contraseñas en caso de olvido de la contraseña empleada habitualmente. Las clásicas preguntas del nombre de tu mascota, la fecha de nacimiento, o el nombre de la pareja nunca han parecido un método muy seguro para proteger una contraseña. ¿Dejarías entrar en tu casa a cualquiera que sepa en qué colegio estudiaste?

Son muchos los casos de famosos (París Hilton, Sarah Palin o Scarlett Johansson entre otros) que han visto sus datos y hasta fotos personales al descubierto porque alguien obtuvo su contraseña a través de este mecanismo. Por fortuna cada vez se encuentran menos sitios que recurren a este método para confirmar que quien recupera la contraseña es quien dice ser.

Por otra parte, en los sitios que aún emplean este método… ¿se aplica el mismo nivel de cifrado o seguridad a la pregunta de seguridad que a la contraseña? Conocer la respuesta de esa pregunta puede permitir a un atacante acceder a la cuenta del usuario, por lo que sin duda debería seguir las mismas reglas de seguridad que la propia contraseña. Si se puede acceder a la respuesta de seguridad en texto plano, ¿qué sentido tiene almacenar correctamente el hash de la contraseña?

En este punto sería interesante analizar el tratamiento que los diferentes sitios que aún emplean este método realizan sobre las diferencias tipográficas. Por ejemplo, si la pregunta es la calle en la que naciste, se puede escribir C/ Olmos, calle olmos c/olmos… todas serían igualmente correctas. Se consideran correctas esas variaciones a la hora de recuperar la contraseña o no. Evidentemente si se guarda el hash solo se admitiría una respuesta como correcta si se escribe igual que como se introdujo originalmente.

Nuestra experiencia nos dice que, por lo general, cuando desgraciadamente se usa este burdo sistema de restablecimiento se guardan las cadenas en texto plano; y el fallo al poner mayúsculas-minúsculas simplemente se trata a través de un “case-insensitive” aplicado a la función de comparación de cadenas.

Por fortuna cada vez se emplea menos la pregunta de seguridad y se utilizan opciones más seguras. Entre los métodos más habituales para obtener una nueva contraseña, suele estar la generación de una nueva contraseña aleatoria y temporal, que se envía al usuario e instarle a cambiarla tras entrar en el sistema.

Aunque un método más adecuado, es enviar al correo del usuario una URL única, generada específicamente (y no predecible) y con un tiempo de vida útil (tras el cual debe caducar) que le permita introducir una nueva contraseña. El usuario solo debe seguir el enlace que recibe e introducir la nueva contraseña que solo él conoce. Fácil y mucho más seguro que otros métodos.

Por otra parte, en los últimos años son múltiples los servicios online que han introducido un doble factor de autenticación. Generalmente se trata de una opción para los usuarios que desean una protección adicional para sus datos.

Tradicionalmente el doble factor de autenticación solía venir a través de un dispositivo generador de claves. Pero en la actualidad el método más empleado se basa en el uso del teléfono móvil. Al configurar esta opción de autenticación el usuario debe introducir su número de móvil; y cuando precisa autenticarse, tras introducir su contraseña habitual, se le envía por SMS una contraseña de uso único y temporal que le permitirá acceder al servicio. Básicamente es añadir un “lo que tengo” al “lo que se” (tengo un móvil, se una credencial).

Google, LinkedIn, Facebook, Twitter o Evernote ya ofrecen esta función que sin duda añade mayor seguridad a la cuenta del usuario. Algunos de estos servicios, prácticamente se vieron obligados a implementar esta medida tras diferentes ataques sufridos contra sus usuarios y que podrían haberse evitado con un doble factor de autenticación implementado.

Se puede consultar una lista de todos los servicios que ofrecen doble autenticación en twofactorauth.org/, incluyendo las opciones que ofrecen y agrupados por categorías.

Pero como siempre no solo basta que el método de obtención de contraseñas sea seguro, también debe estar correctamente implementado y de forma segura. Un error de desarrollo en la implementación, en cualquiera de los puntos (generación de nuevas contraseñas, al guardarlas en la base de datos, en la comprobación del hash, etc.) puede hacer que el resto de medidas de seguridad implementadas queden en nada. Y que cualquier atacante pueda saltarse el sistema y acceder a los datos de cualquier usuario.

El lado humano de las contraseñas

una-al-dia (27/02/2005) La pregunta secreta del caso “Paris Hilton”

una-al-dia (22/09/2008) Ataques “magistrales” de “hackers” mediáticos

una-al-dia (11/03/2006) Teoría y práctica en la seguridad de las contraseñas

http://www.hispasec.com/unaaldia/2695

una-al-dia (14/10/2011) El culo de Scarlett y el eslabón más débil (I) y (II)

una-al-dia (26/05/2015) Secretos, mentiras y recuperación de cuentas

                                                                                                  

Antonio Ropero

Twitter: @aropero