Criptografía

Ventajas de guardar las contraseñas con sal y pimienta

Almacenar las contraseñas en un sistema para validar usuarios es un punto realmente conflictivo. Obviamente es necesario conservar la información necesaria para validar que las credenciales introducidas son válidas, pero a ser posible, sin guardar la contraseña en sí. Para que así en el caso de que una atacante logre robar los datos almacenados con la información de los usuarios no la pueda emplear para acceder al sistema. Este es el motivo por el que es recomendable conservar únicamente el hash criptográfico de la contraseña en lugar de esta. Algo que permite validar la contraseña, simplemente calculando su hash, sin la necesidad de tener esta disponible. Dado que es una operación no reversible, el atacante solamente podrá recuperar la contraseña mediante un ataque de fuerza bruta, probando contraseñas hasta que una generé el hash correspondiente. Un método para complicar este tipo de ataque es guardar las contraseñas con sal y pimienta, lo que obliga a multiplicar el esfuerzo requerido para llevar a cabo un ataque de fuerza bruta.

Buscando las contraseñas en la tabla de usuarios

En el caso de que un atacante consiga acceder a la tabla con los usuarios el hash de la contraseña solamente podrá obtener las credenciales mediante un ataque de fuerza bruta. Algo que, en el caso de que se use un algoritmo considerando seguro requiere mucho esfuerzo computacional (como puede ser el caso de SHA-3, hoy en día ya no se considera seguros MD5 ni SHA-1). Será necesario probar millones de contraseñas hasta conseguir una que coincida alguna de las existentes (salvo que el sistema permita usar contraseñas triviales como 12345, ya que estas serán las primeras que se prueben, aunque esto es otro tema). Aunque, a medida que aumente el número de usuarios, será necesario probar con una cantidad menor de contraseñas antes de encontrar una coincidencia. Por lo que una manera de complicar las cosas sería usar algo similar a “un algoritmo de hash diferente para cada usuario”. Motivo por el que se introduce la sal.

Complicando el ataque mediante el uso de sal

La sal no es más que una cadena de texto aleatoria para cada uno de los usuarios que se concatena a su contraseña antes de generar el hash. Así, aunque dos usuarios empleen exactamente la misma contraseña, el hash que aparecerá en la tabla será diferente. Por lo que el atacante no podrá recurrir a una tabla de hash de contraseñas precalculada para su ataque, teniendo que generar una tabla diferente para cada usuario. Con el tiempo que esto conlleva.

Generalmente la sal que utiliza cada uno de los usuarios se suele almacenar junto al nombre de usuario y la contraseña. Al ser necesario para validar los datos del usuario. Por lo que es habitual que el atacante también obtenga esta información en el ataque. Algo que tampoco es un problema ya que aún conociendo el valor la complejidad del ataque un ataque para obtener las contraseñas es grande.

Pimienta para aumentar aún más la complejidad

Si el valor de la sal para cada uno de los usuarios fuese secreta, la complejidad del ataque aún sería mayor. Pero esto tiene problemas, ya que también complica el proceso de validación de los usuarios. Por eso es habitual recurrir a la pimienta (también conocida como sal secreta) para esto. Una cadena de texto, común para todos los usuarios, que también se agrega a la contraseña antes de obtener el hash. Pero en este caso es un valor que se almacena en una ubicación separada. Por lo que el atacante, además de probar la contraseña para cada usuario deberá probar con los valores de la sal.

Así, la combinación de ambas técnicas, una clave para cada usuario (sal) y una clave privada para todos (pimienta), hace que obtener las contraseñas por un ataque de fuerza bruta sea algo casi imposible.

Conclusiones

En esta ocasión se ha visto las ventajas que ofrecen guardar las contraseñas con sal y pimienta. Unas medidas sencillas con las que es posible hacer casi imposible un ataque de fuerza bruta para obtener las contraseñas de los usuarios. Aunque se conozca el valor del hash almacenado.

Imagen de congerdesign en Pixabay

¿Te ha parecido de utilidad el contenido?

Daniel Rodríguez

Share
Published by
Daniel Rodríguez

Recent Posts

BG/BB: el modelo de CLV para compras en períodos discretos

Los dos artículos anteriores de la serie cubrieron BG/NBD, el modelo para negocios donde el…

1 día ago

Por Qué las Contraseñas Largas son más Seguras que las Complejas

"Tu contraseña debe tener al menos 8 caracteres, una mayúscula, un número y un símbolo…

6 días ago

Gini, KS y AUC: Cómo Medir la Calidad de un Modelo de Credit Scoring

Cuando un analista de riesgo presenta un nuevo scorecard ante el comité de dirección, la…

1 semana ago

Curiosidad: De dónde vienen foo, bar y foobar

Si revisáis código o documentación de otros programadores, tarde o temprano os toparéis con dos…

2 semanas ago

BG/NBD + Gamma/Gamma: el modelo probabilístico para CLV en compras continuas

Los dos artículos anteriores cubrieron el CLV clásico —una fórmula útil pero que trata a…

2 semanas ago

Errores habituales al trabajar con DataFrames grandes en Pandas (y cómo evitarlos)

Hay un momento muy concreto en la vida de casi todo análisis: el código que…

3 semanas ago

This website uses cookies.