Aumente la seguridad de un hash de contraseña ya almacenado

8

En este momento estamos usando PBKDF2 de 1024 bytes con iteraciones de sal y variables específicas de usuario de 256 bytes. Sin embargo, preferiría poder, tal vez una vez cada año o dos, poder aumentar las rondas utilizadas en el algoritmo. Ni BCrypt ni PBKDF2 lo permiten, así que ...

¿Debería olvidarlo o implementar nuestra propia versión de la función recursiva que usa SHA512 / 256? La idea aquí es tomar la contraseña, agregar sal, hash, tomar el hash, agregar sal, hash, tomar ESE hash, agregar sal, hash ... repetir ad nauseum.

... ¿O deberíamos simplemente hacer que el sistema vuelva a romper la contraseña con una nueva cantidad de rondas una vez al año cuando el usuario inicia sesión?

    
pregunta NeroS 10.03.2013 - 13:10
fuente

3 respuestas

11

Crear tu propio algoritmo es nunca una buena idea. Incluso los criptógrafos entrenados, es decir, las personas que trabajaron durante años en los oscuros túneles de la academia y los campos de batalla del congreso científico, recurrirán a tal inventiva solo cuando todo lo demás haya fallado; e incluso entonces, prefieren sugerir esquemas para ser validados por sus feroces compañeros, y ciertamente no se implementan en la producción de inmediato. La mayor parte de la capacitación académica consiste en adquirir un conocimiento intuitivo de los peligros del campo de uno.

Diseñar tu algoritmo es como bailar en un campo minado.

Sin embargo, la imposibilidad de simplemente extender el número de iteraciones de un hash almacenado, comenzando con el valor de hash mismo, es un defecto conocido de los candidatos habituales (PBKDF2, bcrypt y scrypt). Si tiene que vivir con él, puede probar el esquema descrito allí , pero explícitamente niego que la seguridad se aumentaría de esa manera. Mi entrenamiento y mis años de experiencia en el campo me permiten afirmar con cierta confianza que las rondas de hash adicionales que sugiero no reducirían la seguridad .

En el futuro, las cosas mejorarán porque se ha desarrollado una nueva competencia abierta para algoritmos de hashing de contraseñas Lanzado, utilizando el modelo de las competiciones AES, eSTREAM y SHA-3 anteriores. Las presentaciones deben presentarse a fines de enero de 2014. Se obtendrá una cartera de "buenos algoritmos" a mediados de 2015, según el cronograma provisional. La convocatoria para envíos incluye explícitamente la siguiente funcionalidad deseada:

  

Capacidad para transformar un hash existente en una configuración de costo diferente sin el conocimiento de la contraseña.

Por lo tanto, podemos esperar una solución a su problema en poco más de dos años. Solo dos años, eso es muy rápido según los estándares de diseño criptográfico.

Mientras tanto, tendrá que recurrir a la disposición habitual de esperar a que los usuarios inicien sesión para que su contraseña pueda volver a aparecer con más iteraciones. La mayoría de los usuarios que no han iniciado sesión durante más de un año probablemente hayan olvidado su contraseña de todos modos.

    
respondido por el Thomas Pornin 10.03.2013 - 14:33
fuente
5

La solución clásica es la que se escribe al final: "vuelva a borrar la contraseña [..] cuando el usuario inicie sesión". En otras palabras:

  1. El usuario inicia sesión, presentando su contraseña en texto sin formato.
  2. El sistema hace un hash de la contraseña utilizando el hash anterior y lo compara con el valor almacenado.
  3. Si coinciden, hash la contraseña de texto sin formato con el nuevo algoritmo de hash más fuerte y escribe el resultado en la base de datos.
  4. Para las cuentas que no inician sesión en un tiempo determinado, envíeles un correo electrónico cortés solicitando que vuelvan a visitar el sitio, o se eliminará su cuenta.

Dicho esto, ten en cuenta que no debes exagerar con el hash de contraseña. El objetivo principal del hashing de contraseñas es retrasar al atacante que explota las contraseñas después de una infracción exitosa, lo que permite a los usuarios finales cambiar su contraseña. En cierto punto, el hashing de la contraseña se vuelve "suficientemente bueno" en comparación con los otros componentes del sistema.

Obviamente, lo mejor es evitar que el atacante rompa el sistema en primer lugar, así que mantenga suficiente energía para la rutina en curso de la construcción y el mantenimiento de sistemas seguros. (Al igual que las auditorías de seguridad de código en curso, el mantenimiento de conjuntos de reglas de Web Application Firewall, la supervisión y configuración del sistema de detección de intrusos, la protección de los medios de respaldo, etc.)

    
respondido por el Jesper Mortensen 10.03.2013 - 14:20
fuente
1

Tenía el mismo requisito y lo resolví de esta manera:

  • Hash la sal y la contraseña de la manera habitual con PBKDF2 y un factor de trabajo que actualmente es 16 (es decir, 2 ^ 16 iteraciones). Almacene la sal, el hash, el factor de trabajo, etc. como una fila en una tabla de base de datos.
  • Asincrónicamente (es decir, no afecta al usuario final), haga esto 3 veces más, aumentando el factor de trabajo en 1 cada vez. Así que ahora tengo 4 filas de bases de datos para ese usuario, con factores de trabajo de 16, 17, 18 y 19 respectivamente.
  • Siempre uso la fila con el factor de trabajo más bajo para verificar la contraseña, pero cada 2 años borro la fila con el factor de trabajo más bajo.
respondido por el RoadWarrior 08.04.2013 - 03:17
fuente

Lea otras preguntas en las etiquetas