pasando de MD5 a SHA-512

10

Esta pregunta es más una política de seguridad que una pregunta de seguridad técnica.

Hace muchos años, desarrollé un sitio asp.net, implementé la autenticación de formularios y almacené las contraseñas de usuario como hashs MD5. De las siguientes noticias de seguridad básicas es bastante obvio que MD5 ya no es útil. Veo dos posibles planes para manejar a mis usuarios actuales.

  1. Copie la tabla de usuarios antiguos en un nuevo diseño y haga un hash del MD5 actual en SHA-512. Luego, cuando los usuarios inicien sesión, los enviaré primero como MD5 y luego como SHA-512. Kinda Rube Goldberg, pero no molesta a mis usuarios en absoluto
  2. Forzar a todos los usuarios a restablecer su contraseña, verificando la contraseña anterior con MD5, pero almacenando la nueva contraseña como SHA-512.

¿Algún pensamiento? ¿Una tercera opción me falta?

Una nota: me encanta OpenID pero no es una opción en este sitio

    
pregunta Justin C 24.06.2011 - 16:59
fuente

4 respuestas

13

He tenido que resolver este mismo problema dos veces antes:

  1. Mi primera aplicación web, en realidad sabía lo suficiente para las contraseñas de los usuarios de hash MD5; Sin embargo, no sabía nada sobre la sal, y trabajé en eso más adelante.
  2. En realidad, la misma aplicación web, unos años más tarde, cuando decidí "actualizar" a SHA-512 desde el MD5 existente.

En ambos casos, no utilicé ninguna de tus opciones, sino la opción 3: en el próximo inicio de sesión de un usuario, usa la contraseña para generar el nuevo hash y reemplazar el antiguo (después de verificar el anterior).

En el caso de agregar una sal, esto fue bastante trivial: todo lo que hice fue poner a todos por omisión a una sal de "" (cadena vacía), que podría ser concatenada y luego picada sin tener ningún efecto en el hash resultante; una vez autenticado, generé una nueva sal para el usuario y luego volví a aplicar la contraseña, guardando ese nuevo resultado.

La actualización de MD5 a SHA-512 fue un poco más complicada, pero simplemente mirando la longitud de la cadena de la tabla (no usé una nueva columna para el nuevo hash, simplemente amplié la existente para acomodar el hash más largo) Podría decir qué algoritmo usar y luego autenticar al usuario adecuadamente; una vez autenticados, si aún estuvieran en el hash viejo, calcularía uno nuevo (y también aprovecharía la oportunidad para generar una nueva sal) y lo almacenaría.

En ambos casos, por supuesto, finalmente me encontré con la situación en la que aún existían contraseñas de "estilo antiguo". Después de esperar un período de tiempo adecuado (por ejemplo, 6 meses), simplemente decida que aquellos que no han iniciado sesión desde que se adoptó el nuevo estilo están "inactivos": genere y almacene una nueva contraseña completamente aleatoria para ellos (usando el nuevo estilo de almacenamiento, por supuesto), y si alguna vez volvieran, tendrían que usar su mecanismo de restablecimiento de contraseña para recuperar el acceso. (De manera alternativa, déjelo tal como está, pero invalídelo simplemente al eliminar el código del estilo anterior). También podría (si corresponde) enviar un correo electrónico a estos usuarios, solicitándoles que inicien sesión para completar una actualización de seguridad en su cuenta, antes de invalidar su contraseña actual.

Este enfoque implica un código adicional en la rutina de autenticación, por supuesto, pero es solo temporal: una vez que todos han actualizado (ya sea al iniciar sesión o al "forzarse" como en el párrafo anterior), puede eliminar todos Código responsable de realizar la actualización. Actualización de seguridad completa, con la mayoría de sus usuarios (y todos sus usuarios regulares) sin haber notado nada.

    
respondido por el Kromey 24.06.2011 - 19:09
fuente
9

He usado la opción 2 antes en una compañía que necesita hacer lo mismo. No hay problemas con la opción 1, pero 2 parece más simple.

También use PBKDF2 , bcrypt en lugar de SHA-512 para contraseñas

Ok Open-ID está fuera, pero ¿puedes usar O-Auth y usar algo como Twitter o Facebook para conectar y eliminar el almacenamiento y la administración de nombres de usuario y contraseñas por completo?

    
respondido por el Rakkhi 24.06.2011 - 17:28
fuente
1

Esta no es una respuesta verdadera, ya que no aborda su pregunta específica, pero estoy de acuerdo con agregar otra opción para federar sus ID. Entonces, ya sea OpenID, Facebook, Google, quien sea ... la mejor opción para almacenar de forma segura las credenciales de los usuarios es simplemente no hacerlo.

TL; DR: autenticación federada si / donde sea posible.

    
respondido por el Daniel Miessler 24.06.2011 - 22:43
fuente
-1

No hagas la opción 1, pierdes todos los beneficios del mejor algoritmo de hash. Haciendo hashing con un algoritmo peor primero, luego con uno mejor:

  • Pierdes toda la resistencia a la colisión de sha512. Si md5(password1) == md5(password2) , entonces sha512(md5(password1)) == sha512(md5(password2)) . No soy un investigador de seguridad, pero dado que hash hashing varias veces, sospecho que en realidad aumentarías las posibilidades de colisión (probabilidad de chocar con md5 + probabilidad de cha + md5 con colisión).

  • Los bits adicionales (512 vs 128) no tienen valor por la misma razón. Hashing 128 bits de información nunca le dará más de 128 bits de entropía.

respondido por el Brendan Long 24.06.2011 - 21:18
fuente

Lea otras preguntas en las etiquetas