¿Rehashing un hash débil con un algoritmo fuerte lo hace fuerte?

Sí, hash de nuevo con bcrypt es una buena idea. Sin embargo, tenga en cuenta que no le dará más entropía a su código de inicio de sesión, solo hará que se demore más tiempo en descifrar. Por lo tanto, para empezar, si se trata de una entropía muy baja, es posible que necesite un factor de costo muy alto para que no sea posible descifrarla.

En una nota al margen, en general, es mejor utilizar solo una función hash buena que jugar con muchas, como se explica en las respuestas a esta pregunta . Pero no tiene esa opción, por lo que los argumentos no son realmente válidos para su caso.

En cuanto al uso de un pimiento, recomendaría simplemente cifrar los hashes en su lugar. Da el mismo tipo de protección, pero ofrece más flexibilidad. Pero no es un reemplazo para la salazón.

This and this puede ser una lectura interesante para usted. Además, Roshan Bhumbra tiene un sugerencia interesante acerca de rehashing con una sola función después del primer inicio de sesión.

Cifrado en tránsito

En su sistema actual, parece que la contraseña de facto es el "hash SHA-1 de este código de registro", ya que la posesión de un hash coincidente es suficiente para crear un archivo válido, aunque no está claro si permite al atacante explotar algo directamente Sin embargo, en este sentido, no es menos seguro que simplemente enviar una contraseña de texto simple, lo cual es apropiado siempre y cuando "obtenga un archivo" a través de un canal seguro y cifrado, es decir, https / sftp / etc. adecuados.

Cifrado en almacenamiento

Un riesgo de este sistema es que si un atacante puede obtener una copia de ese archivo, puede obtener las contraseñas completas de los usuarios. SI necesita almacenar estos hash, entonces tiene razón en que sería razonable hacerlos con bcrypt para el almacenamiento, y el problema principal es que debe asegurarse de eliminar inmediatamente el SHA recibido. -1 hash y ninguna copia (p. Ej., Archivos temporales, copias de seguridad, cachés, etc.) permanecen en el almacenamiento.

Veo otra opción que no parece haber sido mencionada, aunque esto funcionaría mejor si el sistema que genera el hash pudiera usar un Bcrypt.

Solo necesita actualizar el hash cuando el usuario inicie sesión. Aunque esto significa que tendrá dos algoritmos de hashing diferentes en uso al mismo tiempo, soluciona el "problema" mencionado por @Anders con respecto al uso de dos algoritmos en un valor.

Puede almacenar un valor junto al hash para decirle a la aplicación de qué tipo es, y si es el hash SHA-1, puede hacer un hash de la contraseña que acaba de ingresar (siempre que sea correcta) y guardarla.

Si los hash originales no tienen sal, entonces simplemente puede aplicar cualquier algoritmo de hash con sal al hash sin sal original que haya recibido.

Sin embargo, es importante que esté claramente marcado en su base de datos que estos hash están usando el algoritmo de hash combinado. No es del todo improbable que en una fecha posterior tenga diferentes usuarios en su base de datos protegidos con diferentes algoritmos hash. En ese momento, es importante que conozca la función correcta que debe usar cada usuario en su base de datos.

Es posible actualizar los hash almacenados en su base de datos la próxima vez que el usuario inicie sesión. Aunque puede que no sea importante porque bcrypt es solo un poco más seguro que SHA1 seguido de bcrypt.

Si los hashes originales están salados, se vuelve más complicado. En ese caso, aún puede aplicar dos capas de hash, pero en ese caso es muy importante almacenar todas las sales y solo el último valor de hash.