Gebruikers invoer sonder 'n wagwoordterugstelling

Elke gids vir identiteitsmigrasie bereik uiteindelik dieselfde paragraaf, en dit is altyd 'n bietjie verskonend: "gebruikers sal hul wagwoorde moet terugstel." Dit word soos 'n natuurwet behandel. Dit is nie waar nie. Dit is 'n keuse, gewoonlik afgedwing deur 'n hulpmiddel wat nie die moeiliker ding wou doen nie.

Die moeiliker ding is om jou gebruikers se bestaande wagwoord-hutswaardes ter plaatse te verifieer, sodat hulle ná die skuif aanmeld met presies dieselfde geloofsbriewe as voorheen en nooit agterkom dat iets gebeur het nie. Of jy dit kan doen, kom neer op een vraag: kan jy die ou hutswaardes kry, en kan die nuwe stelsel hulle verifieer?

Wagwoord-hutswaardes is meer oordraagbaar as wat mense dink

'n Wagwoord-hutswaarde is nie 'n geheime algoritme nie. bcrypt is bcrypt. 'n bcrypt-hutswaarde dra sy eie kostefaktor en sout binne-in die string, so enigiets wat bcrypt implementeer, kan 'n hutswaarde verifieer wat enige ander bcrypt-stelsel geproduseer het. Dieselfde geld vir die PBKDF2-formaat wat ASP.NET Identity gebruik: gedokumenteer, weergawe-gemerk, selfbeskrywend. As jy weet wat jy vashou, kan jy 'n wagwoord daarteen nagaan sonder om ooit die wagwoord te ken.

So 'n migrasie wat aanmeldings behou, het nie die platte teks nodig nie (niemand het dit nie) en hoef nie almal vooraf weer te huts nie. Dit moet die gestoorde hutswaardes bekom en daarteen verifieer met aanmelding, en elkeen stil-stil na sy eie formaat opgradeer die eerste keer wat 'n gebruiker aanmeld. Daardie laaste deel is lui migrasie: dra die ou hutswaarde, verifieer dit een keer, vervang dit deursigtig. Oor 'n paar weke van normale aanmeldings huts jou gebruikertabel sigself weer en die nalatenskapformate verdwyn mettertyd, met nul terugstellings en nul ondersteuningskaartjies.

Die dubbelpad-deel

Die haakplek is dat verskillende bronne jou verskillende formate gee, en 'n goeie invoerder verifieer albei:

• Vanaf self-gehuisveste Duende / ASP.NET Identity: die V3 PBKDF2-hutswaardes (en enige nalatenskap-bcrypt) verifieer inheems en huts weer met die eerste aanmelding. Dit is die maklike geval, want dit is dieselfde skema wat die bestemming reeds gebruik. Die meeste spanne is verras dat dit so skoon is.
• Vanaf Auth0: bcrypt-hutswaardes verifieer woordeliks. Die haakplek is nie die formaat nie, dit is om hulle te kry.

Wanneer jy regtig nie kan nie

Auth0 se Management API gee nooit wagwoord-hutswaardes terug nie. Dit is 'n doelbewuste beleid, nie 'n gaping in enigiemand se gereedskap nie, en jy behoort agterdogtig te wees oor enige "een-klik Auth0-uitvoer" wat beweer dat dit wagwoorde insluit sonder dit. Die ondersteunde pad is 'n grootmaat-uitvoer wat deur ondersteuning bygestaan word: 'n NDJSON-lêer met elke gebruiker se bcrypt-hutswaarde. Kry daardie lêer en die hutswaardes voer woordeliks in, lui migrasie en alles, en die skuif is onsigbaar.

As jy nie daarop kan wag nie, is die terugval die eerlike weergawe van die verskonende paragraaf: gebruikers stel 'n nuwe wagwoord met die eerste aanmelding. Niks is verloor nie, want daar was geen hutswaarde om oor te dra nie. Die verskil is dat jy dit bewustelik gekies het, eerder as omdat die hulpmiddel nie beter kon doen nie.

Waarom dit meer saak maak as wat dit klink

'n Gedwonge terugstelling is die enkele mees sigbare, mees onrusbarende ding wat jy aan 'n gebruikersbasis kan doen tydens 'n migrasie. Dit genereer ondersteuningslading, dit leer gebruikers om 'n phishing-agtige "klik hier om terug te stel"-e-pos te verwag, en dit is die oomblik waarop 'n stille infrastruktuurverandering almal se probleem word. Om dit te vermy, is grootliks wat 'n migrasie laat voel asof niks gebeur het nie, en dít is hoe 'n migrasie behoort te voel.

So voordat jy "almal stel terug" aanvaar, vra die twee vrae. Vir die meeste skuiwe is die antwoord ja op albei, en die verskonende paragraaf was nooit nodig nie.

Sien wat 'n invoer sou oordra — die voorskou is slegs-lees en wys jou alles voordat enigiets geskryf word.