Es cierto que, dado que los buenos servidores nunca almacenan contraseñas, solo tokens de verificación de contraseñas (es decir, hash), no pueden cambiar la función hash sin la cooperación del usuario. Al solicitar a los usuarios que vuelvan a ingresar su contraseña, están diciendo que ya almacenaron las contraseñas de una manera adecuada (o, al menos, no de una manera terriblemente débil).

Sin embargo, pedir a los usuarios, por correo electrónico, que volver a ingresar sus contraseñas (siguiendo las instrucciones en un correo electrónico posterior) es una práctica muy deficiente. Los usuarios deben ser entrenados nunca para hacer tales cosas. Esta institución está deshaciendo años de pacientes esfuerzos educativos. Además, no debería haber "instrucciones especiales": el proceso de actualización de la función hash debería ser automático y transparente en el próximo inicio de sesión del usuario. Me parece bastante sospechoso que los usuarios deban hacer algo especial en ese momento, a menos que estén planeando hacer cumplir una de estas temidas "políticas de contraseñas" que rechazarán las contraseñas que no contengan letras de ambos casos, dígitos, signos de puntuación y dos palabras sánscritas de distintos sutras.

En mi opinión, la forma correcta de actualizar la función hash para el hash de contraseñas es hacerlo de forma transparente durante un período prolongado (varios meses) y simplemente "bloquear" las cuentas que no se hayan utilizado durante todo el período. Si es necesario que los usuarios se conecten realmente de manera inmediata, envíe un correo electrónico indicando que "su cuenta no se ha utilizado en 6 meses; por razones de seguridad, se desactivará si no se conecta en el próximo mes, y la reactivación tendrá que ser manejada a través del servicio de asistencia ".

@CodesInChaos sugiere" encadenar "hashes, es decir, usar el antiguo valor de hash como la" contraseña "para el nuevo valor de hash, al menos de forma transitoria. Esto funciona y proporciona los beneficios de seguridad del nuevo hash siempre que todo lo siguiente sea válido:

• el antiguo hash era "suficientemente decente" (por ejemplo, era un MD5 en la contraseña, no el antiguo hash de Unix basado en DES que trunca las contraseñas a ocho caracteres);
• tienes un lugar para almacenar los parámetros adicionales (sal, recuento de iteraciones ...) para el hash antiguo junto con los parámetros para el nuevo hash (o tienen el mismo formato y, por lo tanto, se pueden compartir);
• está listo para asumir el costo de la CPU de calcular ambas funciones hash al verificar la contraseña;
• si realiza la transición (es decir, desea que la cadena se haga hash solo hasta el siguiente inicio de sesión para este usuario), entonces hay una manera de marcar el hash almacenado como "transicional", para que el verificador sepa que debe calcular el hash antiguo luego el nuevo hash.

Entonces, depende de cuál era la función anterior, cuál es la nueva función y por qué la cambia. El encadenamiento de hashes es ciertamente una buena idea cuando el hash anterior es una invocación simple, sin sal y no iterada de MD5 o SHA-1.

Estoy de acuerdo con Thomas. No hay justificación en recrear repentinamente hashes con un nuevo algoritmo. Excepto si hubiera una fuga de la base de datos o una nueva vulnerabilidad que hiciera reversibles los hash.

En una nota diferente, si no hay más remedio que cambiar el algoritmo inmediatamente, probablemente así es como lo haría. Notifica a sus usuarios para que tengan tiempo de verificarlo con usted y comprobar que no es un intento de phishing. Luego, configura una plataforma segura para cambiar la contraseña para todos los usuarios. Seguro que alguien podría hacerse pasar por los administradores y enviar un correo electrónico de seguimiento con una dirección falsa, pero el primer correo electrónico parece tratar de educar a las personas, no caerán en la trampa. , el culpable se encuentra fácilmente y se pueden tomar contramedidas de manera efectiva, lo que hace que la suplantación de identidad no sea rentable.

Una buena política es obligar a los usuarios a cambiar sus contraseñas cada 3 meses aproximadamente. Es una molestia, pero se considera una buena práctica por una razón, la gente tiende a usar la misma contraseña en todas partes, o la escribe en papeles o en su teléfono. Con el tiempo suficiente, los riesgos de que estos apoyos se vean comprometidos se vuelven significativos. En mi empresa tenemos que cambiarla cada 3 meses, no podemos usar una contraseña anterior y la nueva debe ser lo suficientemente diferente de las anteriores (es decir, no solo agregue un carácter ..).

Sin embargo, es un dolor, las contraseñas suelen ser así. Soy un gran fanático de los inicios de sesión únicos (SSO) con tokens OTP. Fácil revocable, fácil para el usuario, solo un soporte, etc. Pero tal infraestructura tiene un costo, complicar un poco la vida de los empleados al cambiar las contraseñas regularmente es una buena solución comercial.