¿Cómo proceder si se introduce un nuevo algoritmo hash para las contraseñas?

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

Sin embargo, pedir a los usuarios, por correo electrónico, que vuelvan a ingresar sus contraseñas (siguiendo las instrucciones en un correo electrónico posterior) es una práctica muy mala. Los usuarios deben ser entrenados nunca para hacer tales cosas. Esta institución está deshaciendo años de esfuerzos educativos del paciente. Además, no debe haber "instrucciones especiales": el proceso de actualización de la función hash debe 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 planeen imponer una de estas temibles "políticas de contraseña" 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 sūtras.

En mi opinión, la forma correcta de actualizar la función hash para el hashing 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 realmente se conecten de manera inmediata, envíe un correo electrónico que indique 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 deberá manejarse a través del servicio de asistencia ".

@CodesInChaos sugiere hashes de "encadenamiento", es decir, utiliza el valor de hash antiguo como la "contraseña" para el nuevo valor de hash, al menos de manera transitoria. Esto funciona y proporciona los beneficios de seguridad del nuevo hash siempre que se cumpla todo lo siguiente:

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

Por lo tanto, depende de lo que fue la función antigua, de lo que es la función nueva y de por qué la cambias. Encadenar hashes es ciertamente una buena idea cuando el hash anterior es una invocación simple, sin sal, sin iteración de MD5 o SHA-1.

Estoy de acuerdo con Thomas. No hay justificación para volver a crear hashes con un nuevo algoritmo. Excepto si hubo una fuga en la base de datos o una nueva vulnerabilidad que haga que los hashes sean reversibles.

En una nota diferente, si no hay más remedio que cambiar el algoritmo de inmediato, es probable que así sea como lo haría. Notifica a sus usuarios para que tengan tiempo de verificarlo con usted y verifique que no sea un intento de phishing. A continuación, 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 la gente, no caerá en la trampa, el culpable es fácil de encontrar y las medidas pueden tomarse con eficacia por lo tanto, la suplantación no es rentable.

Una buena política es también forzar a los usuarios a cambiar sus contraseñas cada 3 meses aproximadamente. Es un dolor, pero se considera una buena práctica por una razón, las personas tienden a usar la misma contraseña en todas partes, o la escriben en un pedazo de papel o en su teléfono. Con suficiente tiempo, 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 más antigua y la nueva debería ser lo suficientemente diferente de las antiguas (es decir, no agregue un carácter ...).

Sin embargo, es un dolor, las contraseñas suelen ser así. Soy un gran fan de los sellos de inicio de sesión único (SSO) con tokens OTP. Fácil revocable, fácil para el usuario, solo un soporte, etc. Pero tal infraestructura tiene un costo, y complica un poco más la vida de los empleados al cambiar las contraseñas regularmente.