Doble seguridad de hashing

Question

Mi primera pregunta es, he escuchado que hash la cadena 2 veces (por ejemplo, sha1 (sha1 (contraseña))), porque el segundo hash tiene una longitud fija, ¿es cierto?

Mi segunda pregunta es, ¿cuál es más seguro? (var1 y var2 son 2 cadenas):

1. sha1 (var1 + sha1 (var2))
2. sha1 (var1 + var2)

Si es el primero, ¿vale la pena el costo de rendimiento?

Answer 1

Al trocear la cadena dos veces, aumenta el riesgo de colisiones, lo cual es malo para la seguridad.

En lugar de tener una cantidad infinita de entradas que conducen a 2 ¹²⁸ salidas posibles, tendrá 2 ¹²⁸ entradas posibles que conducen a quizás menos de 2 ¹²⁸ salidas.

El uso de sal y pimienta antes del picadillo al menos mantiene la entrada a infinitas posibilidades. Hashing aumenta dos veces el tiempo de ejecución de su script y aumenta el riesgo de colisiones, a menos que mantenga la fuente de entrada infinita.

Answer 2

• sha1 (var1 + sha1 (var2))
• sha1 (var1 + var2)

Ninguno de los dos es muy seguro. No reinventes la rueda. HMAC fue diseñado para esto; en particular, toma medidas (relleno, etc.) para evitar problemas con ciertas debilidades en ciertos algoritmos hash que interactúan mal con las implementaciones 'simples' anteriores.

Además, el doble hashing no es útil para mejorar la seguridad. Considere: en el mejor de los casos, asignará de un valor aleatorio a otro valor aleatorio. Sin embargo, si hay una colisión, dos valores resultantes del segundo hash son iguales, ha perdido la seguridad al terminar con una colisión. Es decir, nunca puede deshacerse de una colisión de esta manera, pero puede ganar una.

Dicho esto, los ataques de preimagen existentes podrían no funcionar contra el doble hashing ... ¡pero! Todavía podrían funcionar. No estoy calificado para decir qué, y si estás preguntando esto aquí, probablemente tampoco lo estés. Ciertamente, los ataques de colisión, que son todos prácticos con MD5 hoy en día, no se ven obstaculizados por el doble hashing.

Es mejor seguir con los algoritmos probados que han resistido décadas de análisis, porque con la criptografía, es muy fácil hacer algo que se vea seguro pero no lo sea.

Answer 3

Dudo que esto le agregue seguridad. Aumentaría el tiempo de ejecución de su script, pero no agregaría mucha seguridad al hash. Recuerde que cuando alguien intenta romper su hash, no necesita encontrar el valor exacto de var1 y var2, solo necesita encontrar uno que dé como resultado el mismo hash.

Answer 4

No soy un experto en criptografía, pero que yo sepa, no obtendrá seguridad al calcular el valor varias veces, además de ralentizar el proceso. Entonces, si hash 1000 veces, harás un ataque (por ejemplo, un ataque de diccionario) 1000 veces más lento, pero esto es bastante irrelevante en el caso de hash una o dos veces.

Answer 5

El uso de solo uno y sin sal permite que se resuelva fácilmente.

Hay muchas tablas grandes que contienen toneladas de estos hash, por lo que un solo hash sin sal se puede resolver casi sin nada.

Agregar un segundo hash tampoco ayudará mucho porque una vez más estas tablas ya existen con los valores guardados.

Una sal dinámica que se agrega a la contraseña ayudará mucho más que múltiples hashes. Los hashes múltiples realmente no le agregan mucho.

Answer 6

Mi sensación acerca de esto es que estás construyendo una pared de ladrillos con una puerta de acero, pero las otras paredes están hechas de madera contrachapada. En otras palabras, puede inyectar tanta seguridad como desee en las contraseñas de hash, pero aún habrá formas mucho más fáciles de descifrar su sistema. Creo que es mucho mejor adoptar un enfoque amplio de seguridad en lugar de preocuparse demasiado por cosas como esta.

Answer 7

¿Var1 + var2 será igual en una situación esperada? Quiero decir, la primera proposición debería estar bien en ese caso, ya que evitarías una colisión hash. Acerca de valer el costo, esa es una pregunta que debe responder. Vale la pena evitar una colisión.

Sobre el algoritmo sha, se supone que realmente codifica los resultados. Por lo tanto, aplicarlo muchas veces no debería tener mejores resultados, ni aplicarlo a un `` más aleatorio '' la entrada debería dar como resultado mejores resultados.

Answer 8

Hacer una cadena varias veces complicará la tarea del atacante en caso de un ataque de diccionario, lo que lo hará "mucho más largo". a la fuerza bruta Su primera pregunta no está clara, pero los hashes múltiples no son menos seguros porque el segundo hash tiene una longitud fija.

Pero más importante que un hash múltiple, el uso de una sal es esencial para una mejor seguridad.

Con respecto a su segunda pregunta, diría que no es muy sencillo decir cuál de los 2 es el más seguro, creo que ir con la opción 2 es realmente suficiente.