¿Cómo actualizar el método de hashing de una base de datos en vivo sin comprometer la seguridad?

7

Estoy trabajando en un proyecto de Intranet que es accesible desde el exterior. La contraseña se almacena en una base de datos de Sql Server en el método Hash y salt normal. El problema radica en el algoritmo de hash.

Actualmente utiliza SHA512Cng y no podemos encontrar la decisión detrás de por qué se usó este algoritmo. Me gustaría actualizar este algoritmo de hash para usar bcrypt , así como para alargar la clave de acceso.

Por supuesto, ya que las contraseñas están ocultas, simplemente no podemos ejecutar un lote para actualizar la contraseña.

¿Cuál es la posible ruta disponible al actualizar un método de autenticación de uno menos seguro a uno más seguro de una base de datos en vivo?

Por supuesto, nos gustaría que la base de datos permanezca tan segura como el método SHA512Cng actualmente proporciona y no comprometa la base de datos durante el proceso de actualización.

    
pregunta Pierre-Alain Vigeant 16.07.2012 - 19:21
fuente

4 respuestas

7

Hash the hash, luego actualice a medida que los usuarios se autentiquen o actualicen con éxito sus contraseñas. De esta manera, tiene seguridad inmediata, que es el punto principal de su esfuerzo.

Implementación:

Hash y guardar en su lugar todos los hashes SHA en su db w / bcrypt, por lo que solo tiene hash bcrypt. Cuando los usuarios se autentican, usted verifica la equivalencia con bcrypt (contraseña). Si eso falla, entonces compara con bcrypt (sha512 (contraseña)). A medida que los usuarios se autentican exitosamente y / o actualizan sus contraseñas, usted tiene la contraseña w / bcrypt.

La principal desventaja es que debes mantener un par de líneas de código adicionales (la comparación de hash secundaria). Pero esto es mucho mejor que mantener una segunda columna de contraseñas mientras se mantienen alrededor de contraseñas mal escritas.

EDITAR: Argh! Publicado antes de darse cuenta de que Ramhound respondió con la misma idea en un comentario a la pregunta. Estoy de acuerdo con él.

    
respondido por el Trieu 17.07.2012 - 03:53
fuente
10

Recomiendo cambiar gradualmente a cada usuario al nuevo método de hashing de contraseña en su próximo inicio de sesión. En ese momento, usted conoce su contraseña de texto simple, por lo que puede volver a codificarla con bcrypt y cambiarla a bcrypt. Esto evita la necesidad de un "día de bandera" o ponerse en contacto con todos sus usuarios. De hecho, es invisible para los usuarios: sus usuarios nunca necesitan saber que está haciendo la transición a un nuevo algoritmo hash de contraseña.

En más detalle:

  • Agregue otro campo a la base de datos para indicar qué tipo de algoritmo de hash se usó para calcular el hash de la contraseña. En otras palabras, hay dos campos asociados con cada usuario: uno para el hash de contraseña, y para indicar el algoritmo de hash (SHA512Cng o bcrypt). Inicialmente, el algoritmo de hash de contraseña para cada usuario se inicializa en SHA512Cng.

  • Cuando un usuario intenta iniciar sesión, busque el algoritmo hash de contraseña para su cuenta, haga clic en la contraseña que proporcionó utilizando ese algoritmo y compárelo con el hash almacenado. Si no coincide, el inicio de sesión se rechaza. Si coinciden, se acepta el inicio de sesión.

  • Además, si se aceptó el inicio de sesión y el algoritmo en la base de datos es SHA512Cng, luego vuelva a codificar la contraseña usando bcrypt, sobrescriba el hash de la contraseña con el nuevo hash bcrypt y cambie el algoritmo en la base de datos para bcrypt.

Esto te permite pasar gradualmente al nuevo algoritmo hash de contraseña, a medida que las personas inician sesión en tu servicio.

Opcionalmente, después de algunos meses, si hay usuarios que no han iniciado sesión (y aún así tienen sus contraseñas con SHA512Cng), puede restablecer su contraseña o enviarlas por correo electrónico y solicitar que vuelvan a iniciar sesión. o algo. Sin embargo, en muchos casos esto puede no ser necesario.

P.S. O bien, podría utilizar la elegante solución de Ramhound simplemente de cifrar el hash de contraseña. ¡Listo!

    
respondido por el D.W. 16.07.2012 - 20:04
fuente
1

El método habitual es ponerse en contacto con los usuarios para informarles que tendrán que iniciar sesión, por ejemplo, dentro del próximo mes, y cuando lo hagan, actualicen los hashes en ese momento.

De esta manera, no tendrá que hacer nada más que confirmar el hash de la contraseña anterior del usuario cuando inicie sesión y almacenar el hash de la nueva contraseña.

Todo lo que necesitas es hacer un seguimiento de los usuarios que han actualizado y eliminar los hashes antiguos.

    
respondido por el Rory Alsop 16.07.2012 - 19:27
fuente
0

El método genérico es usar un período transitorio durante el cual se usan métodos hash antiguos y nuevos; esto requiere poder distinguir los hashes de ambos tipos en la base de datos. El método hash se puede actualizar del antiguo al nuevo en el próximo inicio de sesión del usuario. Posiblemente puede empujar suavemente a los usuarios para que inicien sesión en los próximos meses; alternativamente, puede desactivar las cuentas de las personas que no hayan iniciado sesión durante seis meses. Consulte esta pregunta para algunos detalles.

Aún durante el período de transición, puede hashes de cadena : use el valor de hash antiguo como la "contraseña" para la nueva. Si la función anterior es un hash simple y sin sal de la contraseña, esto será fácil. Si la función antigua usaba una sal, entonces debes mantenerla junto con las nuevas sales para la nueva función.

Idealmente, habría usado una función de hash que estaba salada e iterada, y que se pueden agregar iteraciones adicionales sin necesidad de la contraseña original. Que yo sepa, no existe una función de hashing de contraseñas generalizada que admita eso, aunque no veo una imposibilidad inmediata (los criptógrafos todavía tienen trabajo que hacer).

    
respondido por el Thomas Pornin 24.02.2013 - 20:36
fuente

Lea otras preguntas en las etiquetas