¿Está migrando la contraseña db fuera de MD5 encadenando MD5 y Bcrypt?

8

Actualmente tengo un sistema heredado que almacena contraseñas MD5 sin sal. Desafortunadamente, algunos otros controles no están implementados (como la capacidad de caducar contraseñas) y estoy tratando de actualizar mi algoritmo a algo más nuevo y evitar pedirle al usuario una nueva contraseña.

Me pregunto cuál será el impacto si solo uso algo como un bcrypt en el hash MD5 actual. En otras palabras:

  1. El usuario envía una contraseña de texto simple
  2. La contraseña está hash usando MD5
  3. El hash MD5 se hash utilizando bcrypt
  4. Hashes comparados con fines de autenticación

¿Esto va a "disminuir" la fuerza del hash bcrypt resultante de alguna manera?

    
pregunta BurgerMeister 06.04.2016 - 19:48
fuente

2 respuestas

8

Lo que esencialmente terminaría es con las contraseñas de los usuarios de MD5 antes de introducirlas en BCrypt.

Si bien MD5 es un algoritmo rápido y muy roto, no elimina ninguna entropía de las contraseñas (a menos que tengan más de 128 bits de entropía, pero la contraseña del usuario promedio tendrá mucho menos). Así que la entropía que introduces en BCrypt sigue siendo la misma.

Cuando un atacante roba su base de datos y quiere usar fuerza bruta, todavía necesita ejecutar BCrypt, solo que en lugar de ejecutarla con el millón de contraseñas más comunes, la ejecutaría en los hashes MD5 del millón más contraseñas comunes No tardará mucho más, pero tampoco durará más.

Por lo que veo, realmente no hay nada malo con su plan.

    
respondido por el Philipp 06.04.2016 - 22:02
fuente
4

Primero, consulte esta pregunta y mi respuesta, ya que creo que cubre la mayor parte de su pregunta.

Es bueno que desee actualizar su contraseña db fuera de MD5 sin sal. Como no tiene la capacidad de caducar las contraseñas de los usuarios, debe asegurarse de que no queden contraseñas en la base de datos como MD5 sin sal.

Básicamente tienes 3 opciones para hacer esto:

  1. Mueva a todos a Bcrypt inmediatamente ejecutando un script en la base de datos para duplicar su hash MD5 actual y almacenar Bcrypt(MD5($passwd)) en la base de datos. En su primer inicio de sesión, verá que su contraseña de texto simple tiene la opción de moverlos a Bcrypt($passwd) , o puede dejar el hashing doble para siempre.

  2. Deje la contraseña de todos como MD5 en la base de datos y actualícelas a Bcrypt en su próximo inicio de sesión .

  3. Haga 1. o 2. junto con una caducidad de la contraseña que eliminará su hash de la db y los obligará a realizar una recuperación si no han iniciado sesión después X tiempo .

Pros / Cons

  1. En la comunidad de seguridad generalmente se acepta que el "hash doble" está bien, no le dará más seguridad, pero tampoco debilitará su seguridad. Aquí hay dos preguntas sobre crypto.SE sobre ese tema: [más matemática] y icono más explicativo] . La ventaja aquí es que si su db de hashes de contraseña se roba mañana, todos los usuarios estarán protegidos por la tecnología más nueva, ya sea que hayan iniciado sesión o no recientemente. Esto es realmente bueno teniendo en cuenta que incluso si un usuario no ha iniciado sesión durante 5 años, puede que aún esté usando esa contraseña en otros sitios. Otra ventaja es que si elige ir con la opción Bcrypt(MD5($passwd)) , entonces realmente no necesita ningún cambio de esquema de db. Yo haría esta opción.

  2. Como se mencionó anteriormente, esta opción no ofrece protección a los usuarios que no vuelven a iniciar sesión y requiere cambios en el esquema de la base de datos para rastrear quién está en MD5 y quién está en Bcrypt. Además, si su contraseña db es robada dentro de un par de meses / años a partir de ahora, los piratas informáticos verán qué usuarios están en MD5 y descifrarán sus contraseñas primero, por lo que básicamente está desechando la seguridad para los usuarios que nunca vuelven a iniciar sesión. y como se mencionó anteriormente, esto es un problema porque los usuarios tienden a reutilizar las contraseñas entre sitios. En general, esta opción es más trabajo para una menor seguridad y creo que es irresponsable para los usuarios .

  3. Si está dispuesto a caducar las contraseñas, combinar esto con 1. le brinda opciones de mantenimiento, y realmente hace 2. una opción viable, ya que todos los hashes MD5 estarán fuera de su base de datos después de un tiempo determinado. Pero como dijo que el vencimiento no es una opción, no me detengo en esto.

Dos cosas adicionales en las que quieres pensar son:

  • Si alguna vez desea retirar MD5 de su código de inicio de sesión, o si está contento de hacer Bcrypt(MD5($passwd)) para siempre. No creo que haya ninguna razón de seguridad para eliminar el paso de MD5, pero si desea retirar MD5, entonces tendrá que hacer algo complicado en el primer inicio de sesión de un usuario, agregue una columna de db para realizar un seguimiento del método hash que utiliza. utilizando, etc.

  • Considera lo que vas a hacer en 5 años cuando descubramos algún defecto en bcrypt y todos se muden al nuevo SuperHash todopoderoso. Si estás almacenando Bcrypt(MD5($passwd)) , entonces puedes hacer el mismo truco y moverte a SuperHash(Bcrypt(MD5($passwd))) y todo estará bien. Si, sin embargo, optó por mover a los usuarios al limpiador Bcrypt($passwd) , entonces tiene que hacer algunas cosas más complicadas con las columnas de base de datos porque hay un buen cambio que tendrá usuarios que nunca han iniciado sesión para actualizarse al nuevo hash.

respondido por el Mike Ounsworth 06.04.2016 - 22:12
fuente

Lea otras preguntas en las etiquetas