¿En qué medida la adición de sal ralentiza el ataque de una mesa de arco iris?

Question

¿En qué medida la adición de sal ralentiza el ataque de una mesa de arco iris?

#1 de Stephane (3 votos)
#2 de Sjoerd (2 votos)
#3 de niilzon (1 votos)

1

Entiendo que la adición de una sal proporciona algo de protección, porque el atacante ya no puede simplemente buscar el valor de hash en una tabla de arco iris. Sin embargo, todavía es posible escribir un programa de craqueo que busque el hash y luego le aplique la sal, ya que la sal en sí no está necesariamente encriptada. Por lo tanto, una contraseña con sal es aún crackeable, aunque el proceso de craqueo tardará más. Mi pregunta es cuánto tiempo más tardará. ¿La sal aumenta la complejidad del tiempo de agrietamiento en un orden de magnitud significativo? ¿Cuáles son las complejidades de tiempo respectivas de agrietar un hash sin sal y agrietar un hash salado usando la misma tabla de búsqueda?

Otra pregunta un tanto relacionada: leí en Practical Unix and Internet Security que la función Crypt modular que se usa en algunos sistemas Unix no XOR la sal con el hash, y solo la encaja en el comenzando. ¿Esto no anula el propósito de tener una sal, ya que el hash sin sal se puede extraer de la cadena de la contraseña y atacar como si la sal no estuviera allí en primer lugar?

salt password-cracking rainbow-table

pregunta Legend of Overfiend 22.02.2017 - 15:04

fuente

3 respuestas

3

Si desea crear una tabla de arco iris para una lista de contraseñas con sal, debe hacerlo para cada valor de sal posible. Si la longitud de la sal es suficiente y si las sales se recogen correctamente (es decir, nunca se reutilizan), entonces las tablas del arco iris son prácticamente inútiles.

Básicamente, si tiene n bytes de sales, aumenta las operaciones y el almacenamiento necesarios para crear un conjunto de tablas de arco iris en 2 ^ n

respondido por el Stephane 22.02.2017 - 15:16

fuente

2

Tener hashes salados también tiene sentido para ataques de fuerza bruta y diccionario. Si los hashes de contraseña no tienen sal, el software de descifrado de contraseñas puede hash de una contraseña potencial y compararla con todos los hashes. Si los hashes están salados, el atacante debe calcular el hash para cada usuario. Así que esto aumenta el trabajo para el atacante por el número de usuarios.

no hace XOR la sal con el hash, y simplemente lo agrega al principio. ¿Esto no anula el propósito de tener una sal, ya que el hash sin sal se puede extraer de la cadena de la contraseña y atacar como si la sal no estuviera allí en primer lugar?

Realmente no entiendo esta parte de la pregunta. Es típico y seguro concatenar la contraseña y el salt, hacer un hash y luego almacenar el hash y el salt. Así que almacenas (salt, hash(salt | password)) . Debido a que la función hash es una forma en la que no se puede obtener fácilmente hash(password) . Para resolver esto, tendrías que calcular diferentes valores para password mientras usas el mismo salt .

respondido por el Sjoerd 22.02.2017 - 16:52

fuente

Lea otras preguntas en las etiquetas salt password-cracking rainbow-table

aplicaciones web disponibles para pruebas? ¿HTTP POST es más seguro que HTTP GET para AJAX?

score 1 · Accepted Answer

Para cada intento de una sola cadena, se debe realizar el algoritmo de hash.

Entonces, esto realmente depende de qué algoritmo de hash se use.

Si se utilizó MD5 (mala idea para las contraseñas), la diferencia es pequeña. Si se utilizó BCrypt, la diferencia es enorme.

Con respecto a su segunda pregunta: la salazón es valiosa ya que no puede usar una tabla Rainbow (la sal forma parte de la cadena antes de que ocurra el hashing). Lo que está buscando generalmente se llama "pimienta", que es similar a el "salt" pero no se almacena junto al hash (generalmente en un sistema separado o un archivo en ese sistema).