Hash de contraseña tanto en el cliente como en el servidor: ¿cuáles son los riesgos relacionados con la composición de hash (colisiones y reversión)?

0

Hay muchas preguntas que abordan el "cliente / servidor: ¿dónde hash?", pero no he encontrado nada sobre mi pregunta en particular: considerando un server_salted_hash (client_salted_hash (contraseña)), usando HTTPS, ¿cuáles son los riesgos relacionados colisiones de hachís, o hay otros riesgos aún más graves que ellos? (por supuesto, considerando

Como recuerdo en la escuela, y las lecturas sobre buenas prácticas de seguridad, una de las principales razones para no componer la función hash es que "paradójicamente" la debilita al aumentar potencialmente el número de colisiones o al revertirla.

Por lo tanto, me gustaría saber si hay fallas de seguridad introducidas por este sistema. (eso no sería si solo lo hago en el backend)

Suponiendo que use sal en ambos hash, ¿hay algunas combinaciones de hash que recomendaría o desaconsejaría?

    
pregunta hl037_ 22.11.2018 - 14:50
fuente

1 respuesta

1

Si utiliza las funciones hash correctas, las posibilidades de colisiones son despreciables. Esto sigue siendo el caso si hash repetidamente. La pregunta ¿Fuerza de múltiples iteraciones de hash? explica:

  

Hay un problema: aumentar n también aumenta ligeramente las probabilidades de que una contraseña aleatoria dé el mismo resultado que la contraseña correcta debido a las colisiones de hash, y por lo tanto es una contraseña falsa pero aceptada; sin embargo, esto sigue siendo muy improbable, en el orden de n · 2 −256 para los valores prácticos de n, y se puede ignorar por completo en la práctica.

Recomendaría utilizar una función de hashing de contraseña lenta y conocida, como PBKDF2, scrypt, bcrypt o Argon2.

    
respondido por el Sjoerd 22.11.2018 - 15:06
fuente

Lea otras preguntas en las etiquetas