Almacenar el hash de las contraseñas de los usuarios, por ejemplo, en una base de datos, es inseguro ya que las contraseñas humanas son vulnerables a los ataques de diccionario. Todo el mundo sugiere que esto se mitiga mediante el uso de sales, pero la sal se considera no sensible y no necesita ser protegida.
En el caso de que el atacante tenga la sal, ¿por qué el ataque de su diccionario se ha vuelto más difícil que antes? ¿No tener acceso a la sal, efectivamente, elimina su utilidad?
Salt no te protege contra un atacante solitario que solo tiene una contraseña. Un atacante que solo quiera romper una contraseña calculará hash(salt + guess) en lugar de hash(guess) (si el esquema de contraseña es hash(salt+password) ).
Salt ayuda si el atacante quiere romper muchas contraseñas. Este suele ser el caso. A veces, el atacante está atacando un sitio y quiere entrar en una cuenta en ese sitio, cualquier cuenta. Sin sal, la mayor parte del trabajo del atacante puede usarse para todas las cuentas, por lo que puede probar cada uno de sus intentos contra todas las cuentas a la vez. Con un sal correctamente elegido (es decir, si no hay dos cuentas tiene la misma sal), el atacante debe comenzar de nuevo con cada contraseña hash.
Además, en cierto sentido, todos los intentos de descifrado de contraseñas intentan descifrar todas las contraseñas de las cuentas a la vez. Eso es porque los hashes pueden ser precomputados; todo lo que necesita es que alguien genere una tabla de hashes, o más eficientemente, una tabla arco iris - y ese trabajo inicial se puede distribuir a varios atacantes que pueden usarlo en cualquier base de datos de cuentas que use el mismo algoritmo de hashing de contraseñas. Nuevamente, la sal hace inútiles estas precomputaciones.
Un ataque de contraseña de fuerza bruta se puede resumir así:
hash(guess[i]) = hashed_password[j] . En un enfoque ingenuo, el segundo paso requiere n × p cálculos hash para probar todas las conjeturas contra todas las cuentas. Sin embargo, si el primer paso ya calculó todos los hash posibles, entonces el segundo paso no requiere ningún cálculo de hash, solo comprobando si cada hashed_password está en la base de datos precomputada, por lo que el ataque solo requiere n búsquedas de tablas (esto puede incluso acelerarse, pero ya hemos pasado de n x p cómputos lentos¹ a n búsquedas de tablas).
Si cada contraseña tiene una sal diferente, para que sea útil, la precomputación tendría que incluir una entrada para cada valor de sal posible. Si la sal es lo suficientemente grande, la precomputación es infeasible. Si la precomputación no tiene en cuenta la sal, no será útil para acelerar el segundo paso, ya que cualquier función criptográfica de hash "mezcla" su entrada: conocer el hash de UIOQWHHXpassword no Ayuda a calcular el hash de NUIASZNApassword . Incluso para atacar a una sola cuenta, el atacante debe realizar cálculos hash de p para probar todas las conjeturas, ya una mejora en la búsqueda de una sola tabla que sería suficiente si el atacante tiene un diccionario precomputado.
¹ Una contraseña no debe almacenarse como un hash como SHA-1, pero usa una función de hash más lenta como bcrypt o scrypt o PBKDF2 .
Voy a explicar cada nivel de seguridad para la contraseña almacenada en la base de datos, tal vez esto ayude a aclarar la importancia de la sal.
Nivel 1 : contraseña almacenada sin cifrar en la base de datos.
Esto es solo estupidez pura . Pero a veces, las grandes empresas ponen en peligro su base de datos y, oh sorpresa, todas las contraseñas se almacenan de forma clara. ¡Qué vergüenza!
Nivel 2 : contraseña almacenada usando un algoritmo de hash.
Este es un paso hacia una mayor seguridad. Si un atacante obtiene la contraseña con hash, aún no puede iniciar sesión usando esta credencial para el servicio. Primero deberá "deshacer" la contraseña usando una Rainbow Table o por forzar en bruto esto . Eso significa que requiere un poco más de trabajo para el atacante, pero aún puede ser posible recuperar la contraseña original.
Nivel 3 : contraseña almacenada utilizando un algoritmo de hashing con un salt.
Esto comienza a ser interesante. Como vimos en Nivel 2 , un atacante que tiene acceso a la contraseña con hash puede forzarla o usar una tabla de arco iris. Agregar una sal a la contraseña original hace que la tabla arco iris sea totalmente inútil porque no tienen en cuenta la sal. Todavía es posible obtener la cadena original usando una tabla de arco iris, pero eso significaría que en la tabla de arco iris, existe la contraseña + sal. Como una sal es generalmente muy larga, es casi imposible tener un valor hash de una cadena (40+). La única solución que queda es la fuerza bruta.
Nivel 4 : contraseña almacenada usando un algoritmo de hashing con un salt y un peper.
Esto es muy interesante (es la razón por la que publico mi respuesta, ya que las reales ya son interesantes).
Le recomiendo que use un algoritmo de hash como BCrypt, SCrypt o PBKDF2, ya que no están rotos hasta el momento y son muy lentos para piratear, lo que aumenta el tiempo para romper uno, y luego una base de datos completa de contraseñas. / p>
La diferencia entre la sal y la pimienta es su ubicación. La sal generalmente se almacena en la base de datos, pero la pimienta se encuentra en el código. Esto puede parecer extraño, pero la idea original es que una base de datos puede verse comprometida, pero no el código, lo que deja al atacante una sal y una lista de contraseñas de hash inútiles. Además, agrega aún más complejidad a la contraseña con hash, haciendo que las tablas arco iris sean completamente inútiles (¡si suponemos que aún son un poco útiles con un salt!).
En el caso de que solo la base de datos esté comprometida, incluso la fuerza bruta será inútil , ya que el atacante no está buscando un valor (la contraseña original) sino dos valores (la contraseña original Y la pimienta).
Si sus hash no tienen sal, puedo generar un total de diccionarios de hashes y almacenarlos en una base de datos (un tipo especial llamado tabla de arco iris, es más eficiente para un gran número de hashes), entonces todo lo que tengo que hacer es mirarlos. arriba. Básicamente, una memoria gigante frente a la optimización del tiempo de CPU. Además, si veo dos usuarios con el mismo hash, sé que están usando la misma contraseña.
Un salt hace que el hash de cada contraseña de los usuarios sea único, y si lo haces bien, probablemente será único incluso si usan la misma contraseña en algún otro sitio (no es poco común), por lo que tendría que tomar la palabra, aplique sal y pique, repita para la siguiente entrada en el diccionario.
Los hash sin sal son vulnerables a los ataques de búsqueda. Existen bases de datos disponibles de forma gratuita que contienen millones de hashes de contraseña (principalmente MD5 y SHA1) que se pueden utilizar para buscar el texto plano de un hash. Estos pueden basarse en bases de datos relacionales estándar o en formatos de bases de datos especializados, como tablas de arco iris.
Por lo tanto, este es un ejemplo:
7c6a61c68ef8b9b6b061b28c348bc1ed7921cb53 (sin sal)
2d67062d67b4d0eaca31a768e901d04982de7352 (con el prefijo "RxB6aE")
Una búsqueda rápida en el primer hash revelará que el texto plano es "passw0rd". Sin embargo, este último no es muy probable que se encuentre. En el caso donde el atacante no conoce la sal, hace que los ataques de diccionario y fuerza bruta sean difíciles.
Si busca proteger contraseñas en una base de datos, debe usar algo como bcrypt. Utiliza una gran cantidad de iteraciones de un algoritmo hash para hacer que cada cálculo sea lento. Como tales, los ataques de fuerza bruta, los ataques de diccionario y la construcción de tablas de arco iris son altamente inviables.