Nutzer importieren ohne Passwort-Zurücksetzung

Jede Anleitung zur Identitätsmigration landet irgendwann beim selben Absatz, und er klingt immer ein wenig entschuldigend: "Die Nutzer müssen ihr Passwort zurücksetzen." Das wird behandelt wie ein Naturgesetz. Ist es aber nicht. Es ist eine Entscheidung, meist erzwungen durch ein Tool, das den schwierigeren Weg gescheut hat.

Der schwierigere Weg besteht darin, die bestehenden Passwort-Hashes Ihrer Nutzer direkt vor Ort zu verifizieren, sodass sie sich nach dem Umzug mit genau den Zugangsdaten anmelden, die sie vorher hatten, und nie etwas davon mitbekommen. Ob das gelingt, hängt an einer einzigen Frage: Kommen Sie an die alten Hashes heran, und kann das neue System sie verifizieren?

Passwort-Hashes sind portabler, als man denkt

Ein Passwort-Hash ist kein geheimer Algorithmus. bcrypt ist bcrypt. Ein bcrypt-Hash trägt seinen Kostenfaktor und sein Salt direkt in der Zeichenkette mit sich, also kann alles, was bcrypt implementiert, einen Hash verifizieren, den irgendein anderes bcrypt-System erzeugt hat. Dasselbe gilt für das PBKDF2-Format, das ASP.NET Identity verwendet: dokumentiert, versioniert, selbstbeschreibend. Wenn Sie wissen, was Sie in der Hand halten, können Sie ein Passwort dagegen prüfen, ohne das Passwort jemals zu kennen.

Eine Migration, die Logins erhält, braucht also weder den Klartext (den hat niemand) noch ein vollständiges Neu-Hashing im Voraus. Sie muss die gespeicherten Hashes beschaffen und bei der Anmeldung gegen sie prüfen, wobei jeder einzelne beim ersten Login eines Nutzers leise auf sein eigenes Format gehoben wird. Genau das ist Lazy Migration: den alten Hash mitnehmen, ihn einmal verifizieren, ihn transparent ersetzen. Über ein paar Wochen normaler Logins hinweg rehasht sich Ihre Nutzertabelle von selbst, die Altformate verschwinden mit der Zeit, ganz ohne Zurücksetzen und ganz ohne Support-Tickets.

Der Punkt mit dem doppelten Pfad

Der Haken ist, dass verschiedene Quellen Ihnen verschiedene Formate liefern, und ein guter Importer verifiziert beide:

• Aus selbst gehostetem Duende / ASP.NET Identity: Die V3-PBKDF2-Hashes (und etwaiges Alt-bcrypt) verifizieren nativ und werden beim ersten Login neu gehasht. Das ist der einfache Fall, weil es dasselbe Verfahren ist, das das Ziel ohnehin schon nutzt. Die meisten Teams sind überrascht, dass es so sauber läuft.
• Aus Auth0: bcrypt-Hashes verifizieren wortwörtlich. Der Haken ist nicht das Format, sondern das Beschaffen.

Wann es wirklich nicht geht

Die Management API von Auth0 gibt niemals Passwort-Hashes zurück. Das ist eine bewusste Richtlinie, keine Lücke im Werkzeugkasten irgendeines Anbieters, und Sie sollten jedem "Ein-Klick-Auth0-Export" misstrauen, der ohne sie behauptet, Passwörter einzuschließen. Der unterstützte Weg ist ein support-gestützter Massenexport: eine NDJSON-Datei mit dem bcrypt-Hash jedes Nutzers. Holen Sie sich diese Datei, und die Hashes werden wortwörtlich importiert, inklusive Lazy Migration, und der Umzug bleibt unsichtbar.

Wenn Sie nicht darauf warten können, ist der Ausweg die ehrliche Variante des entschuldigenden Absatzes: Die Nutzer legen beim ersten Login ein neues Passwort fest. Es ging nichts verloren, weil es keinen Hash zum Mitnehmen gab. Der Unterschied ist, dass Sie sich bewusst dafür entschieden haben und nicht, weil das Tool es nicht besser konnte.

Warum das mehr zählt, als es klingt

Ein erzwungenes Zurücksetzen ist das Sichtbarste und Beunruhigendste, was Sie einer Nutzerbasis mitten in einer Migration antun können. Es erzeugt Support-Last, es gewöhnt Nutzer daran, eine phishing-förmige "Hier klicken zum Zurücksetzen"-Mail zu erwarten, und es ist der Moment, in dem eine stille Infrastrukturänderung zum Problem aller wird. Das zu vermeiden ist der größte Teil dessen, was eine Migration so anfühlen lässt, als wäre nichts geschehen, und genau so sollte sich eine Migration anfühlen.

Bevor Sie also "alle setzen zurück" akzeptieren, stellen Sie die zwei Fragen. Für die meisten Umzüge lautet die Antwort auf beide Ja, und der entschuldigende Absatz war nie nötig.

Sehen Sie, was ein Import übernehmen würde: Die Vorschau ist schreibgeschützt und zeigt Ihnen alles, bevor irgendetwas geschrieben wird.