¿Está bien envolver un hash criptográfico con MD5 para almacenamiento?

No pierdes nada al aplicar MD5.

Ya que usa md5(hash()) como su esquema de hashing combinado, es probable que el atacante no tenga la capacidad de enviar una entrada que solo sea evaluada por md5() ; Es evaluado por todo el esquema o nada en absoluto. Entonces, dado un hash h en su base de datos, el objetivo del atacante es encontrar m tal que md5(hash(m)) = h . ( m puede o no ser la contraseña original, ya que una contraseña de colisión es lo suficientemente buena como para permitir que inicien sesión de manera fraudulenta.)

Suponiendo que el atacante obtuvo h y pudo aprovechar una debilidad en MD5 y encontrar una imagen previa h' tal que MD5(h') = h , eso no les ayuda, ya que todavía tienen que encontrar la imagen previa de h' en hash . Si hash es lo suficientemente fuerte en sí mismo, esto no es más débil que usar hash por sí mismo.

Lo esencial de la idea aquí es que MD5 actúa como un mapa aleatorio de entradas a salidas. La asignación de MD5 está bien distribuida y las cadenas aleatorias no generan colisiones. Desde el punto de vista de seguridad, MD5 hace que sea demasiado fácil crear colisiones de manera inteligente, pero no nos importa que el atacante diseñe de manera inteligente la entrada a MD5 en este caso, solo nos importa que al agregar un mapeo a la salida de hash we no cree más colisiones con MD5(hash()) de lo esperado de hash por sí mismo. En otras palabras, no se está confiando en las propiedades criptográficas resistentes a la colisión del MD5 aquí. Puede agregar cualquier tipo de asignación aleatoria a la salida de una buena función hash y, siempre que esa asignación no sea propensa a colisiones accidentales, no debería perder nada.

Direccionamiento de la parte actualizada del OP: Puede usar SHA-512 y truncar la salida. El reciente norma FIPS-140-4 especifica el truncado SHA-512 para Un puñado de largos. Este es un método totalmente respaldado.

Es mejor truncar la salida de hash original.

Primero, tenga en cuenta el almacenamiento de sal: para verificar una contraseña, deberá volver a calcular el hash de la contraseña, utilizando el mismo número de sal y iteración. Algunas funciones de hash (a saber, bcrypt ) tradicionalmente codifican el recuento de sal y iteración en la salida. Si solo mantienes un hash de la salida bcrypt pero no el sal en alguna parte, no podrás volver a calcular el hash desde una contraseña determinada, rompiendo la funcionalidad.

Luego, el hashing de contraseña funciona en resistencia de preimagen . Si la función de hash que utiliza es buena, entonces su resistencia a las imágenes previas será del orden de 2ⁿ con una salida de n bits . Por lo tanto, puede truncar la salida (la salida real bits , sin contar la codificación de sal y el recuento de iteraciones, y sin tener en cuenta cualquier transformación de los bits en caracteres con hexadecimal o Base64 ) hasta, digamos, 80 bits. Si la función hash es buena, será lo suficientemente robusta. No hay necesidad de repetir con MD5 o cualquier otra función; Un simple truncado hará el truco. Y si la función de hash es no buena e introduce puntos débiles cuando se trunca así, entonces ... ¿por qué lo usarías en primer lugar?

(Las colisiones no tienen nada que ver con el problema. Las colisiones son irrelevantes para el hashing de contraseñas. La aplicación de MD5 en la salida no provocaría una debilidad significativa, a pesar de la no resistencia de MD5 a las colisiones, ya que el hashing de contraseñas se trata de preimágenes. el truncamiento es más sencillo, y "más simple" significa "bueno" en seguridad; también es más flexible, ya que puede elegir la longitud que crea conveniente).

El uso de MD5 en este caso está bien, pero no es necesario usar MD5 para reducir la longitud de la cadena de hash. Simplemente realice una operación simple en la cadena de hash para reducir su longitud. Por ejemplo, si su cadena de hash de longitud completa es:

  

e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Puede recortarlo a cualquier longitud que sea aceptable para su almacenamiento, como:

  

e3b0c44298fc1c149afbf4c8996fb9242

Creo que MD5 (hash (contraseña)) no tiene ninguna debilidad práctica conocida, si necesita truncar el hash a 16 bytes. Lea la respuesta de B-Con para obtener una explicación. Tenga en cuenta que esto depende de algunas propiedades de la función MD5, no solo de las propiedades. de la función hash. Por ejemplo, supongamos que se descubrió que el MD5 en realidad no es superyectivo (que yo sepa, esto no se conoce), y que solo hay N valores de resumen de MD5 diferentes. Luego, encontrar otro hash con el mismo MD5 sería cuestión de calcular el hash de N contraseñas diferentes, que podrían funcionar si N no es demasiado grande.

Sin embargo, si lo haces, serás culpable de lanzar tu propio cripto. No lance su propio criptográfico .

Afortunadamente, hay una mejor manera de obtener un valor de 16 bytes de una función hash que todavía es una función hash. Con una buena función de hash, cada bit es lo más independiente posible de los otros bits y no revela ninguna información sobre el hash. Por lo tanto, si toma 128 bits de un hash, obtiene un hash de 128 bits. Para la familia SHA, esto es aceptado oficialmente (FIPS 180-4 §7): si desea un hash de N bits, puede tomar una función de hash aprobada que produzca más de N bits y truncar a los primeros N bits . Las recomendaciones del NIST para usar hashes (§5.1) discuten la la fuerza que puede esperar de un truncamiento de N bits.

Si está haciendo esto porque tiene un campo de base de datos de tamaño fijo destinado a los resúmenes de MD5, tenga en cuenta que si bien es aceptable truncar el resumen, la sal no es negociable. Debe tener una sal única, y debe almacenarse en la base de datos de alguna manera. La sal de cada usuario debe ser distinta tanto de la sal de otro usuario como de la sal utilizada en cualquier otra base de datos. (Las colisiones de sal se pueden tolerar si son lo suficientemente infrecuentes, pero si dos usuarios tienen la misma contraseña y la misma sal, eso será obviamente visible). La sal se puede generar desde otros campos, pero no es una buena idea, porque es difícil lograr la unicidad; consulte ¿Clave principal como Salt? . Otros antecedentes sobre la sal: ¿Qué se debe usar como sal? ¿Cómo almacenar sal? ¿Por qué es más seguro usar sal?

Aunque no hay ningún ataque explícito que yo sepa, no lo recomiendo. MD5 está roto, y tiene muchas colisiones conocidas. Como tal, un atacante podría generar entradas de tal manera que la salida del KDF sea una colisión con otra contraseña.

En su lugar, ¿por qué no usar un KDF como PBKDF2 con un tamaño de salida que se pueda ajustar?

Sí, hay un problema.

El hash MD5 resultante es solo eso. Un hash MD5. Sería propenso a los ataques de colisión en su contra.

MD5 es una función hash con vulnerabilidades de colisión conocidas. Evita usarlo si es posible.