Todos
los días abrimos y cerramos la puerta de nuestra casa sin cuestionarnos el
funcionamiento de la cerradura. Lo mismo ocurre cuando nos autenticamos en
algún servicio online, introducimos nuestra contraseña sin preguntarnos qué
procesos ocurren para que el sistema nos deje acceder. Las contraseñas son las llaves del mundo digital, pero... ¿son seguras
las cerraduras digitales?
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?
¿Cómo se deben
almacenar las contraseñas de forma segura?
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).
[dato protegido] = [salt] + proteger ([function hash], [salt] +
[credencial]);
¡Oh, no! ¡He olvidado mi contraseña!
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?
 |
| En muchos sitios aún se recurre a las preguntas de seguridad |
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.
La doble autenticación
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.
 |
| Proceso de verificación en dos pasos de Google |
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.
Más información:
Password Storage Cheat Sheet
List of Rainbow Tables
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
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
