¿Todos los hashes de contraseña sin sal son inherentemente inseguros?

No todas las contraseñas. Cuando la contraseña es lo suficientemente larga y aleatoria para no aparecer en una tabla de arco iris de tamaño razonable, la salada es innecesaria.

El propósito de un salt es aumentar la longitud de la contraseña a un nivel en el que las tablas de arco iris no sean factibles. Cuando la contraseña ya tiene suficiente entropía, la sal se vuelve redundante.

Cuando sus sales son de 32 bits, equivalentes a otros 5 caracteres de mayúsculas y minúsculas, las letras y los caracteres especiales sin relación con una palabra del diccionario serían equivalentes.

Sin embargo, las contraseñas utilizadas por el usuario promedio no tienen suficiente entropía para ser resistentes a las tablas del arco iris. Entonces, a menos que tenga la capacidad y la autoridad para imponer una política de contraseña estricta y los usuarios que entienden que no deben tratar de encontrar lagunas legales (¡hey, Password123! es un caso mixto de 12 caracteres con letras y caracteres especiales! ), todavía debe utilizar salazón.

Sí, aunque algunos hash sin sal, como el hash de Windows LM , son aún peores debido a deficiencias criptográficas.

Preguntar sobre el uso de sal o no significa que el que pregunta está interesado en almacenar y asegurar contraseñas, no en asegurar su propia cuenta. Incluso con contraseñas completamente aleatorias de 128 caracteres, un administrador con acceso a dos sitios podrá ver si esa contraseña de 128 caracteres fue reutilizada, a menos que haya un salt. Entonces, sí, todos los hash sin sal tienen una inseguridad inherente, incluso si una contraseña dada está a salvo de un ataque de tabla arco iris.

Otro problema con los hashes sin sal es que dos usuarios con la misma contraseña tendrán la misma contraseña hash. Esto significa que si los hashes de contraseña son accesibles, ya sea por compromiso o información confidencial maliciosa, las contraseñas duplicadas son obvias. Incluso si no pueden romper el hash, un ataque de ingeniería social en uno otorga acceso a todos. (O uno de los usuarios ve que puede acceder a los demás)

La aplicación de sal es extremadamente barata y no hay razón para implementar un sistema de almacenamiento de contraseñas sin él.

Mejor aún, pregúntese si realmente necesita almacenar contraseñas

Si se refiere a algoritmos de hash de contraseña "comunes" como SHA1 y MD5 que se usan sin sal, ni siquiera necesita una tabla de arco iris, una base de datos de búsqueda de hash inversa es suficiente para la mayoría de las contraseñas de usuarios finales mal elegidas. Es decir: md5("password") siempre dará como resultado 5f4dcc3b5aa765d61d8327deb882cf99 , de modo que cuando encuentre el hash 5f4dcc3b5aa765d61d8327deb882cf99 , sabrá que será la contraseña. Intenta buscar en Google 5f4dcc3b5aa765d61d8327deb882cf99 o cualquier otro hash que tengas.

Como siempre, primero lea La respuesta de Thomas Pornin a ¿Cómo hacer hash de forma segura las contraseñas?

El resumen de salazón, suponiendo que tiene más de una contraseña en su base de datos, y esa base de datos está filtrada (vea Sony, Adobe, Forbes, y otros), por lo tanto un atacante (cracker, criminal, investigador de seguridad, escuela secundaria aburrida estudiante, equipo de craqueo de competición, etc.)

• Con una sal única por usuario y un buen hash
  • el atacante debe codificar cada contraseña candidata una vez por usuario y luego compararla con el hash, porque hay un resultado diferente para cada sal.
  • Cuantos más usuarios tengas con contraseñas aún sin rastrear, más tardarás en probar a cada candidato.
  • Tampoco hay forma de saber qué usuarios tienen la misma contraseña.

• Con una única sal para todos los usuarios, generalmente se denomina "error épico"

  • El atacante ya sabe qué usuarios tienen la misma contraseña que otro usuario, lo cual es información útil
  • El atacante debe cifrar cada contraseña candidata una vez en total, y luego comparar ese único resultado con cada hash de contraseña.
    • Por lo tanto, esto es N veces peor que las sales únicas por usuario, donde N es el número de registros de usuario
  • Si el atacante obtiene su sal, entonces el atacante también puede comenzar a calcular los hashes de contraseña candidatos ANTES de obtener sus contraseñas; un gran ahorro de tiempo.

• Sin sal en absoluto, o una única sal que haya sido utilizada anteriormente por ese atacante (como "sal")

  • El atacante ya sabe qué usuarios tienen la misma contraseña que otro usuario, lo cual es información útil
  • El atacante debe cifrar cada contraseña candidata una vez en total, y luego comparar ese único resultado con cada hash de contraseña.
    • Por lo tanto, esto es N veces peor que las sales únicas por usuario, donde N es el número de registros de usuario
  • Si usó algún algoritmo de hash común, el atacante puede simplemente extraer los registros de hashes anteriores que computaron en el pasado y compararlos con su base de datos
  • El atacante también puede comenzar a calcular los hashes de contraseña candidatos ANTES de obtener sus contraseñas; un gran ahorro de tiempo.

Una sal son básicamente valores aleatorios que se agregan a una contraseña antes de que se copien y almacenen. El resultado es que la contraseña de una persona de "potato" se verá diferente a la contraseña de otra persona de "potato".

Las tablas de Ranbow son una lista masiva de hashes para una larga lista de diferentes términos y frases, más comúnmente para el uso de contraseñas. Si la contraseña de tu papa está en una mesa de arco iris, una sal evitará que se rompa. Si la contraseña de su papa no está salada Y existe en la tabla del arco iris, entonces probablemente no tenga suerte.

El grado de ahorro principal que tienes contra una contraseña sin sal es la esperanza de que no esté contenida en la tabla del arco iris que te ataca. Por ejemplo, las personas pueden crear tablas de arco iris para todas las palabras en el diccionario, pero si su contraseña no está en el diccionario y no tiene sal, esa tabla de arco iris no le dará acceso.