Toda guía de migración de identidad acaba llegando al mismo párrafo, y siempre suena un poco a disculpa: "los usuarios tendrán que restablecer su contraseña." Se trata como si fuera una ley de la naturaleza. No lo es. Es una decisión, casi siempre impuesta por una herramienta que no quiso hacer lo más difícil.
Lo más difícil es verificar en su sitio los hashes de contraseña existentes de tus usuarios, para que tras el cambio inicien sesión con exactamente las mismas credenciales que tenían antes y nunca noten que pasó nada. Que puedas hacerlo se reduce a una sola pregunta: ¿puedes obtener los hashes antiguos y puede el sistema nuevo verificarlos?
Los hashes de contraseña son más portables de lo que la gente cree
Un hash de contraseña no es un algoritmo secreto. bcrypt es bcrypt. Un hash bcrypt lleva su propio factor de coste y su sal dentro de la propia cadena, así que cualquier cosa que implemente bcrypt puede verificar un hash producido por cualquier otro sistema bcrypt. Lo mismo ocurre con el formato PBKDF2 que usa ASP.NET Identity: documentado, versionado, autodescriptivo. Si sabes qué tienes entre manos, puedes comprobar una contraseña contra él sin llegar a conocer nunca la contraseña.
Así que una migración que conserva los inicios de sesión no necesita el texto plano (nadie lo tiene) ni rehashear a todo el mundo de antemano. Necesita obtener los hashes almacenados y verificarlos al iniciar sesión, elevando cada uno a su propio formato en silencio la primera vez que el usuario entra. Esa última parte es la migración perezosa: te llevas el hash antiguo, lo verificas una vez y lo sustituyes de forma transparente. A lo largo de unas semanas de inicios de sesión normales, tu tabla de usuarios se rehashea sola y los formatos heredados van desapareciendo, con cero restablecimientos y cero tickets de soporte.
La parte de la doble vía
El matiz es que las distintas fuentes te entregan distintos formatos, y un buen importador verifica ambos:
Desde un Duende / ASP.NET Identity autoalojado: los hashes V3 PBKDF2 (y cualquier bcrypt heredado) se verifican de forma nativa y se rehashean en el primer inicio de sesión. Este es el caso fácil, porque es el mismo esquema que el destino ya usa. A la mayoría de los equipos les sorprende que sea tan limpio.
Desde Auth0: los hashes bcrypt se verifican al pie de la letra. El problema no es el formato, sino conseguirlos.
Cuándo de verdad no puedes
La Management API de Auth0 nunca devuelve hashes de contraseña. Es una política deliberada, no un hueco en las herramientas de nadie, y deberías desconfiar de cualquier "exportación de Auth0 con un clic" que afirme incluir contraseñas sin ella. La vía soportada es una exportación masiva asistida por soporte: un archivo NDJSON con el hash bcrypt de cada usuario. Consigue ese archivo y los hashes se importan al pie de la letra, con migración perezosa incluida, y el cambio queda invisible.
Si no puedes esperar a ello, la alternativa es la versión honesta del párrafo de disculpa: los usuarios fijan una contraseña nueva en el primer inicio de sesión. No se perdió nada, porque no había hash que llevarse. La diferencia es que lo elegiste a sabiendas, y no porque la herramienta no supiera hacer nada mejor.
Por qué esto importa más de lo que parece
Un restablecimiento forzoso es lo más visible y más alarmante que puedes hacerle a una base de usuarios en mitad de una migración. Genera carga de soporte, acostumbra a los usuarios a esperar un correo con forma de phishing del tipo "haz clic aquí para restablecer", y es el momento en que un cambio de infraestructura silencioso se convierte en el problema de todos. Evitarlo es buena parte de lo que hace que una migración se sienta como que no pasó nada, que es como debería sentirse una migración.
Así que antes de aceptar el "todos restablecen", haz las dos preguntas. Para la mayoría de los cambios la respuesta es sí en ambas, y el párrafo de disculpa nunca fue necesario.
Mira qué se llevaría una importación: la vista previa es de solo lectura y te muestra todo antes de que se escriba nada.
SOCIAL SHARE CARD GENERATOR