Proteger tus contraseñas: más allá del hash y las buenas intenciones

Hace muchos años (en 2012 para ser exactos), en una red social muy conocida ocurrió una tragedia. 6.5 millones de contraseñas fueron filtradas debido a un SQL Injection.

Esta empresa era conocedora de la normativa y tenía todas las contraseñas encriptadas con SHA-1 para que en el peor de los casos la desgracia no fuera a más.

Sin embargo, los usuarios no podían acceder a sus cuentas. ¿Qué estaba pasando? Los hackers estaban entrando a sus cuentas.

Todas las contraseñas que estaban supuestamente encriptadas estaban siendo crackeadas con facilidad. El algoritmo SHA-1 no era suficiente para parar a los cibercriminales.

Más tarde, en 2016, se invalidaron todas las contraseñas que no habían sido cambiadas desde este incidente y todo volvió a la normalidad. Eso sí, una normalidad en la cual habían sido robados millones de datos de usuarios y seguramente, vendidos en la dark web.

Pues esta empresa no es ni más ni menos que LinkedIny aunque puedes estar pensando que ha sido un ataque de hace 12 años, es algo que ocurre continuamente. Día tras día se roban datos y se venden en el mercado negro.

En este post explicaré cómo proteger correctamente las contraseñas dentro de una base de datos para que en el caso (dios quiera que no) de que roben los datos de la tuya, no sea aún peor de lo que ya es.

Dejo por aquí links de referencias a los datos:

• Wikipedia
• cecy.dev

Índice Link to Índice

• Índice
• El problema
• La solución
• Conclusiones

El problema Link to El problema

Como muchos sabréis, es obligatorio por ley almacenar de forma segura las contraseñas de los usuarios en la base de datos. Segura en el sentido de que sea “encriptada” con una función unidireccional, es decir, un algoritmo que pase la palabra password a algo como 5f4dcc3b5aa765d61d8327deb882cf99 y que de ninguna forma se pueda revertir, siendo imposible obtener la palabra original.

Estas funciones se llaman funciones hash o funciones resúmenes. Al final no son más que cálculos que usan todos los bits de un texto o palabra para dar como resultado el hash, que siempre es de la misma longitud. Si se cambiase cualquier carácter de la palabra a hashear, cambiará radicalmente el resultado.

Ejemplo:

MD5:

1
2

password -> 5f4dcc3b5aa765d61d8327deb882cf99
p4ssword -> 93863810133ebebe6e4c6bbc2a6ce1e7

Estas funciones hash, son de cálculo rápido y un cibercriminal podría usar la fuerza bruta para romper estas contraseñas. En estos casos, la seguridad recae en cómo de compleja sea la contraseña y por tanto en el usuario. También hay técnicas más avanzadas como encontrar colisiones en MD5, dejo un link por si quieres entrar más en detalle: Implementación de colisiones MD5.

Por lo tanto podemos concluir que si sólo usamos una función hash para las contraseñas de nuestros usuarios, no podemos garantizar la seguridad de sus datos. ¿Qué deberíamos de hacer entonces?

La solución Link to La solución

Para ayudar a las funciones hash a que sean más seguras, podemos optar por varias soluciones que se pueden usar de forma conjunta.

Para empezar, podemos añadir un valor aleatorio, de aproximadamente unos 16 o 32 bytes, al inicio de la contraseña sin hashear. Esto se llama salt, y dificultará los ataques de Rainbow tablesy aumentará la complejidad ante descifrados masivos.

Por otro lado, podemos hashear la palabra múltiples veces. Esto se llama Key Stretching, y su función es complicarle el trabajo al cibercriminal a la hora de romper el hash por fuerza bruta.

Si no has quedado convencido de implementar por tu cuenta el salt o el Key Stretching, no te preocupes porque existen algoritmos que ya lo hacen por ti. Estos algoritmos son: bcrypt, scrypt, Argon2 y PBKDF2.

El uso de estos algoritmos no son perfectos. Cada uno tiene sus normas para su correcto uso. El 30 de octubre de 2024, Okta tuvo una falla de seguridad debido al mal uso de bycript, te dejo un video por si te interesa: Así fue el ERROR de SEGURIDAD de OKTA - Midudev.

Conclusiones Link to Conclusiones

Como hemos visto, hashear las contraseñas con una simple función hash no funciona. Hay que esforzarse algo más e implementar salt y Key Stretching o incluso directamente un algoritmo que ya lo haga por ti. Como he dicho en la introducción, cada día sale una nueva noticia de una empresa que ha sido víctima de un filtrado de datos, y aunque esperemos que nunca sea el caso de nuestra base de datos, tenemos que estar preparados para cualquier escenario.

Espero que te haya servido de algo el post y recuerda recomendar el post de LinkedInsi vienes de allí o si no es así, hazlo igualmente que es gratis 🤑.