¿Contraseña aleatoria vs contraseña nula?

Importe los hashes de contraseñas existentes junto con el resto de los datos, agregue un indicador de "bit sucio" a la nueva base de datos y configúrelo en verdadero para estos usuarios importados.

Cuando el usuario inicie sesión, haga que valide utilizando el mecanismo de hash que se usó en la aplicación / código heredado, luego obligue al usuario a actualizar su contraseña usando el método actual, almacene el nuevo hash y desactive bandera.

Un poco más de trabajo en el back-end, pero si te tomas el tiempo de configurarlo correctamente, facilita los futuros cambios y hace que sea mucho más fácil para la transición del usuario final.

Editar: Además, evita el posible desorden (leído como seguro) que establece la contraseña de un usuario en NULL o en blanco. ¿Cómo se supone que alguien debe verificar que el usuario final es el usuario "real"?

La pregunta aquí es, cómo su lógica de inicio de sesión interpreta un valor indefinido en lugar del hash de la contraseña. Supongo que quiere decir NULL en el sentido SQL, como un valor indefinido.

Si el sistema compara el hash de la contraseña ingresada por el usuario con el hash almacenado, como debería, entonces un valor indefinido (o incluso una cadena vacía) nunca coincidirá. De manera similar, el hash almacenado se podría establecer en alguna otra cadena que nunca coincidirá como un hash de contraseña válida. En los sistemas Linux, puede ver las cuentas del sistema en /etc/shadow con un * en lugar del hash de contraseña, y el bloqueo de un usuario con usermod -L establece el hash en ! . Ninguno de estos es un hash de contraseña válido, por lo que iniciar sesión con una contraseña no tendrá éxito.

Sin embargo, si existe el riesgo de que el sistema de inicio de sesión interprete un valor indefinido (o vacío) que coincida con una contraseña vacía, querrá evitar su uso. Un valor indefinido también podría dar lugar a un error que, en lo más mínimo, puede que no se vea bien.

Necesitaría verificar que se sabe que el sistema funciona con contraseñas no definidas, o si existe alguna otra forma de marcar una cuenta como inutilizable o bloqueada. Generar un hash válido que coincida con una contraseña larga generada de forma aleatoria que no se almacene en ningún lugar sería seguro, ya que es probable que el sistema pueda manejar eso en cualquier caso.

¿Por qué no solo migra los hashes de contraseñas también si va a generar una contraseña aleatoria de todos modos? Luego, puede forzar a las personas a cambiar la contraseña en el primer inicio de sesión si mantiene el algoritmo hash anterior o si hace lo mismo incluso si planea hacer contraseñas aleatorias / nulas si no mantiene el mismo algoritmo hash.

A menos que sus contraseñas fueran de texto simple / con un hash extremadamente pobre antes, no veo por qué la tercera opción de solo migrar hashes sería un problema.

Personalmente, tendería a favorecer el enfoque de "contraseña aleatoria por usuario", ya que de lo contrario existe la posibilidad de que las cuentas sean "robadas" simplemente por ser la primera persona que intenta iniciar sesión con un nombre de usuario determinado.

Sin embargo, esto requeriría que los usuarios conozcan la migración, de modo que el correo electrónico con la nueva contraseña y la nueva URL (o lo que sea el caso) no salga de la nada.

Sin embargo, cuando dice que su contraseña actual está cifrada, ¿qué quiere decir exactamente?

Si están codificados en lugar de encriptados, entonces tenderé a pensar que valdría la pena averiguar cómo se procesan, y simplemente extraerlos con los otros datos.

Cuando un usuario inicia sesión por primera vez, puede:

• forzar un cambio de contraseña y hash la nueva contraseña con lo que sea que quieras usar en tu nueva aplicación
• o autentique a los usuarios con sus contraseñas 'normales', y si la verificación de la contraseña pasa, vuelva a codificar su contraseña y guárdela.

A menos que ambas aplicaciones estuvieran usando el mismo algoritmo de resumen de mensajes, una simple comprobación de la longitud de contraseña de hash almacenada podría decirle qué contraseñas no están usando su algoritmo de hashing deseado.

Si las contraseñas realmente están cifradas, también podría tener sentido ver si puede averiguar cómo están cifradas y elegir uno de los dos enfoques mencionados anteriormente para actualizar su propia base de datos.