¿Almacenar múltiples hash para evitar colisiones, riesgo de seguridad?

En resumen: mejor no lo hagas. Una mejor solución sería usar algo como BCrypt . Puede usar un número mayor de rondas para asegurarse de que atacar a que es computacionalmente inviable.

En cuanto a la seguridad agregada o disminuida: depende de si los hash se filtran. En ambos casos, la diferencia en la seguridad no es tan grande, por lo que todo lo que está sucediendo es que estás quemando ciclos de CPU que podrían haberse utilizado para bcrypt.

Si los hash no se filtran al atacante, entonces su sistema está desatendiblemente más seguro, porque incluso si por casualidad se encontró una colisión de hash, es improbable en el extremo que la colisión Se extendería a los hashes alternativos. Así que esta solución defiende contra las colisiones. Pero como la posibilidad de una colisión es muy pequeña en primer lugar, hacer que sea aún más pequeño tiene una relación de ventajas sobre costos que es prácticamente cero.

Si los hashes do se filtran al atacante, entonces él tiene muchos más hashes para atacar. El sistema se vuelve proporcionalmente menos seguro, si descubrir la fuente de un hash variante da pistas sobre cuál podría ser la contraseña real . Por esa razón, el hash variante debería ser en sí mismo un hash (y, por si acaso, un hash binario , y se obtiene mediante un algoritmo diferente). Entonces el atacante no tiene forma de saber lo que ha encontrado. La seguridad del sistema sigue siendo la misma, y acabamos de grabar algunos ciclos de CPU.

  

ACTUALIZACIÓN : asumamos que el algoritmo de hash utilizado es algo   ridículo (y rápido) como MD5, y que el atacante ha ganado   acceso a la base de datos > por cualquier medio.

Bueno, en ese caso, nuestro hipotético atacante puede intentar montar un ataque de preimagen o ataque de colisión, o podría google todos ellos. Y encuentra, digamos, f7eedbcbee1453935bc9b36870810f58 en Google.

La probabilidad de encontrar un hash en Google es débil (ya que estamos lidiando con modificaciones triviales, pero no obstante las modificaciones) proporcional al número de hashes a atacar.

Por supuesto, f7eedbcbee1453935bc9b36870810f58 es no el hash de la contraseña "real". Sin embargo, en ese momento, la contraseña real (para la cual tiene un hash para confirmar que se haya encontrado) está a solo milisegundos de distancia.

La aplicación de sal y / o la manipulación de los hash cambia poco. Lo que hace es aumentar la seguridad X-fold. Pero tener cuatro hashes en lugar de uno es más o menos, por ejemplo, hasta cuatro veces menos seguro. Salting solo lo hace así que, en lugar de tener un cuarto de un número pequeño, tienes un cuarto de un número enorme . Al utilizar no hashes adicionales, aún aumentaría la seguridad general.

Esto no es una buena idea.

La primera razón es que las colisiones no son un problema . Para el hashing de contraseñas, no confía en la resistencia a las colisiones, sino en la resistencia a preimágenes . No es necesario que la función de hashing de contraseñas admita colisiones fáciles de compilar, pero si lo hace, esto tampoco es un problema. Por ejemplo, las colisiones se pueden construir con PBKDF2. Y no nos importa.

La segunda razón es que la intención del atacante de encontrar una contraseña que coincida con un hash dado no tiene necesidad de calcular varios hashes. El atacante intenta una larga lista de contraseñas potenciales, pero esa lista es mucho más pequeña que el rango de salida de la función hash. La consecuencia es que cuando el atacante encuentra una contraseña coincidente, es la , y esto es así incluso cuando el atacante trabaja con una sola función hash. Por lo tanto, aunque usted gasta la CPU para calcular varios hash, el atacante está perfectamente contento de trabajar con uno solo. En otras palabras, los diversos hashes desperdician su CPU . Esto es importante porque normalmente desea utilizar un hash lento (con un número configurable de iteraciones) para que los ataques sean más lentos. Al hacer el trabajo varias veces, te obligas a reducir el número de iteraciones, lo que le da una ventaja automática al atacante.

La tercera razón es una generalización de la anterior: el atacante solo necesita trabajar en un valor de hash. Si proporciona varios , esto solo puede ayudar al atacante: él elegirá el que le facilite las cosas.

Resumen: su idea de "varios hashes" no resuelve un problema real, pero puede ayudar al atacante. Así que no lo hagas. Como lo explica @Iserni, usa bcrypt. Para un tratamiento más detallado sobre cómo se debe realizar el hashing de contraseñas, lea this .