Importer des utilisateurs sans réinitialisation de mot de passe

Tout guide de migration d'identité finit par buter sur le même paragraphe, et il est toujours un peu penaud : "les utilisateurs devront réinitialiser leur mot de passe." On le présente comme une loi de la nature. Ça n'en est pas une. C'est un choix, le plus souvent imposé par un outil qui n'a pas voulu faire le plus difficile.

Le plus difficile, c'est de vérifier les empreintes de mot de passe existantes de vos utilisateurs sur place, pour qu'après la bascule ils se connectent avec exactement les identifiants qu'ils avaient avant, sans jamais remarquer qu'il s'est passé quoi que ce soit. Que ce soit possible ou non tient à une seule question : pouvez-vous récupérer les anciennes empreintes, et le nouveau système sait-il les vérifier ?

Les empreintes de mot de passe sont plus portables qu'on ne le croit

Une empreinte de mot de passe n'est pas un algorithme secret. bcrypt, c'est bcrypt. Une empreinte bcrypt embarque son propre facteur de coût et son sel directement dans la chaîne, donc tout ce qui implémente bcrypt peut vérifier une empreinte produite par n'importe quel autre système bcrypt. Il en va de même pour le format PBKDF2 qu'utilise ASP.NET Identity : documenté, versionné, autodescriptif. Si vous savez ce que vous avez entre les mains, vous pouvez vérifier un mot de passe sans jamais le connaître.

Une migration qui préserve les connexions n'a donc besoin ni du texte en clair (personne ne l'a) ni de re-hacher tout le monde d'avance. Elle doit obtenir les empreintes stockées et les vérifier à la connexion, en élevant discrètement chacune à son propre format à la première connexion de l'utilisateur. C'est précisément ce qu'on appelle la migration paresseuse : reprendre l'ancienne empreinte, la vérifier une fois, la remplacer de façon transparente. Au fil de quelques semaines de connexions normales, votre table d'utilisateurs se re-hache d'elle-même et les anciens formats s'effacent peu à peu, sans aucune réinitialisation et sans aucun ticket de support.

Le point du double chemin

Le hic, c'est que des sources différentes vous livrent des formats différents, et qu'un bon importeur vérifie les deux :

• Depuis un Duende / ASP.NET Identity auto-hébergé : les empreintes V3 PBKDF2 (et tout ancien bcrypt) se vérifient nativement et sont re-hachées à la première connexion. C'est le cas facile, parce que c'est le même schéma que la destination utilise déjà. La plupart des équipes sont surprises que ce soit aussi net.
• Depuis Auth0 : les empreintes bcrypt se vérifient mot pour mot. L'obstacle n'est pas le format, c'est de les obtenir.

Quand c'est vraiment impossible

La Management API d'Auth0 ne renvoie jamais les empreintes de mot de passe. C'est une politique délibérée, pas une lacune dans l'outillage de qui que ce soit, et vous devriez vous méfier de tout "export Auth0 en un clic" qui prétend inclure les mots de passe sans cela. La voie prise en charge est un export groupé assisté par le support : un fichier NDJSON contenant l'empreinte bcrypt de chaque utilisateur. Récupérez ce fichier et les empreintes s'importent mot pour mot, migration paresseuse comprise, et la bascule reste invisible.

Si vous ne pouvez pas attendre, le repli est la version honnête du paragraphe penaud : les utilisateurs définissent un nouveau mot de passe à la première connexion. Rien n'a été perdu, parce qu'il n'y avait pas d'empreinte à reprendre. La différence, c'est que vous l'avez choisi en connaissance de cause, et non parce que l'outil ne savait pas faire mieux.

Pourquoi cela compte plus qu'il n'y paraît

Une réinitialisation forcée est la chose la plus visible et la plus inquiétante que vous puissiez infliger à une base d'utilisateurs en pleine migration. Elle génère de la charge de support, elle habitue les utilisateurs à attendre un e-mail en forme d'hameçonnage du type "cliquez ici pour réinitialiser", et c'est le moment où un changement d'infrastructure silencieux devient le problème de tout le monde. L'éviter, c'est l'essentiel de ce qui donne à une migration l'impression que rien ne s'est passé, et c'est exactement l'impression qu'une migration devrait laisser.

Alors avant d'accepter le "tout le monde réinitialise", posez les deux questions. Pour la plupart des bascules, la réponse est oui aux deux, et le paragraphe penaud n'a jamais été nécessaire.

Voyez ce qu'un import reprendrait : l'aperçu est en lecture seule et vous montre tout avant que quoi que ce soit ne soit écrit.