¿Puede enviar hashes antiguos sin sal a una función PBKDF con sal para aumentar la seguridad?

Question

¿Puede enviar hashes antiguos sin sal a una función PBKDF con sal para aumentar la seguridad?

#1 de George Bailey (2 votos)
#2 de CBHacking (1 votos)

5

Supongamos que BigBusiness ™ Inc. Ltd. construyó un servicio web en 1995, almacenando sus contraseñas de usuario utilizando tecnología de vanguardia: hashes md5 sin sal. Ahora se dan cuenta de que esto probablemente sea una mala idea y quieren aumentar la seguridad de sus usuarios en caso de una violación sin forzar un restablecimiento de contraseña en todos. Así que deciden almacenar PBKDF2(old_hash, individual_salt) en su lugar.

¿Es esta una buena estrategia o tiene algún inconveniente?

passwords hash salt

pregunta Fritz 23.09.2016 - 18:23

fuente

2 respuestas

Lea otras preguntas en las etiquetas passwords hash salt

¿Formato de archivo del árbol de ataque? ¿Es seguro bcrypt con el ataque de cumpleaños de cifrado de bloque de 64 bits?

score 2 · Answer 1

Bueno, sugeriría BCrypt sobre PBKDF2.

Dicho esto, su solución debe ser doble.

Para asegurar el sistema inmediatamente, sí, su solución es buena. Trate el MD5 como la contraseña de entrada y tenga sal por usuario como usted sugiera.
Sugeriría migrar MD5 fuera de la imagen. (a menos que sea una aplicación estrictamente heredada)

La próxima vez que el usuario inicie sesión, su aplicación tendrá acceso a la contraseña no lavada y tendrá la capacidad de actualizar el hash con uno que omita el paso de MD5. Tendrá que tener algún indicador en la cuenta para saber si se ha completado.

También recomendaría Pepper en pendiente a la contraseña de entrada (o MD5) como una precaución de seguridad adicional.

BCrypt tiene una longitud máxima en contraseñas, por lo que es mejor colocar la contraseña de entrada combinada con Pepper en un hash SHA-256 primero. No estoy seguro si PBKDF2 tiene este límite. Eventualmente, algún día podrá usar un hash aún más reciente que tampoco tenga este límite.

Realmente, migrar fuera de MD5 probablemente no sea necesario, pero deshacerse de MD5 sería la solución ideal para la mejor resistencia a la colisión y parece un diseño más limpio.

score 1 · Answer 2

Como dice George, este sistema está bien por ahora (suponiendo que use buenas sales y un buen recuento de iteraciones para PBKDF2). Sin embargo, debe agregar flexibilidad al sistema para tener en cuenta las actualizaciones futuras del algoritmo de verificación de contraseña. Si bien su esquema actual tiene la ventaja de que puede actualizar la seguridad del verificador de contraseñas sin necesidad de la contraseña real, sigue siendo una buena idea tener un valor que le permita ver cuál es el algoritmo para un verificador en particular.

Veces que puede necesitar esto:

Si realiza alguna actualización del verificador que no se puede hacer solo en base al antiguo verificador, no podrá procesar cada contraseña hasta que el usuario inicie sesión, por lo que tendrá algunos verificadores de contraseña utilizando el nuevo algoritmo y algunos usando uno más viejo.
Si tiene que restaurar desde una copia de seguridad, es bueno si su código de autenticación puede reconocer y respaldar a los verificadores heredados. Le ahorra la necesidad de asegurarse de que está utilizando la versión correcta de su base de código para que coincida con el momento en que se realizó la copia de seguridad de la base de datos.