पासवर्ड रीसेट के बिना यूज़र इम्पोर्ट करना

हर आइडेंटिटी माइग्रेशन गाइड आख़िरकार उसी पैराग्राफ़ तक पहुँचती है, और वह हमेशा थोड़ा माफ़ी-भरा होता है: "यूज़र को अपने पासवर्ड रीसेट करने होंगे।" इसे प्रकृति के एक नियम की तरह समझा जाता है। यह वह नहीं है। यह एक चुनाव है, आम तौर पर एक ऐसे टूल द्वारा थोपा गया जो कठिन काम नहीं करना चाहता था।

कठिन काम यह है कि आपके यूज़र के मौजूदा पासवर्ड हैश को जगह पर ही सत्यापित किया जाए, ताकि वे मूव के बाद ठीक उन्हीं क्रेडेंशियल से साइन इन करें जो उनके पास पहले थे और कभी ध्यान न दें कि कुछ हुआ भी। क्या आप यह कर सकते हैं, यह एक सवाल पर आकर टिकता है: क्या आप पुराने हैश हासिल कर सकते हैं, और क्या नया सिस्टम उन्हें सत्यापित कर सकता है?

पासवर्ड हैश लोगों के सोचने से ज़्यादा पोर्टेबल होते हैं

एक पासवर्ड हैश कोई गुप्त एल्गोरिदम नहीं है। bcrypt bcrypt ही है। एक bcrypt हैश अपना कॉस्ट फ़ैक्टर और सॉल्ट स्ट्रिंग के भीतर ही रखता है, इसलिए जो भी bcrypt को इम्प्लीमेंट करता है वह किसी भी दूसरे bcrypt सिस्टम द्वारा बनाए गए हैश को सत्यापित कर सकता है। ASP.NET Identity जिस PBKDF2 फ़ॉर्मैट का इस्तेमाल करती है उसके बारे में भी यही सच है: प्रलेखित, वर्ज़न्ड, स्व-वर्णनात्मक। अगर आप जानते हैं कि आपके हाथ में क्या है, तो आप किसी पासवर्ड को उसके विरुद्ध जाँच सकते हैं बिना कभी पासवर्ड जाने।

तो एक माइग्रेशन जो लॉगिन को संरक्षित रखता है उसे प्लेनटेक्स्ट की ज़रूरत नहीं (किसी के पास वह है ही नहीं) और उसे हर किसी को पहले से दोबारा हैश करने की ज़रूरत नहीं। उसे स्टोर किए गए हैश हासिल करने हैं और साइन-इन पर उनके विरुद्ध सत्यापित करना है, हर एक को पहली बार यूज़र के लॉग इन करते ही चुपचाप उसके अपने फ़ॉर्मैट में अपग्रेड करते हुए। वह आख़िरी हिस्सा लेज़ी माइग्रेशन है: पुराना हैश साथ ले जाएँ, उसे एक बार सत्यापित करें, उसे पारदर्शी रूप से बदल दें। कुछ हफ़्तों के सामान्य लॉगिन में आपका यूज़र टेबल खुद को दोबारा हैश कर लेता है और लीगेसी फ़ॉर्मैट चलन से बाहर हो जाते हैं, शून्य रीसेट और शून्य सपोर्ट टिकट के साथ।

ड्यूल-पाथ वाला हिस्सा

पेच यह है कि अलग-अलग स्रोत आपको अलग-अलग फ़ॉर्मैट थमाते हैं, और एक अच्छा इम्पोर्टर दोनों को सत्यापित करता है:

• सेल्फ़-होस्टेड Duende / ASP.NET Identity से: V3 PBKDF2 हैश (और कोई भी लीगेसी bcrypt) मूल रूप से सत्यापित होते हैं और पहले साइन-इन पर दोबारा हैश हो जाते हैं। यह आसान मामला है, क्योंकि यह वही स्कीम है जो डेस्टिनेशन पहले से इस्तेमाल करता है। ज़्यादातर टीमें हैरान होती हैं कि यह इतना साफ़-सुथरा है।
• Auth0 से: bcrypt हैश हू-ब-हू सत्यापित होते हैं। पेच फ़ॉर्मैट में नहीं है, बल्कि उन्हें हासिल करने में है।

जब आप सचमुच नहीं कर सकते

Auth0 का Management API पासवर्ड हैश कभी नहीं लौटाता। यह एक जान-बूझकर बनाई गई नीति है, किसी की टूलिंग में कोई कमी नहीं, और आपको किसी भी ऐसे "वन-क्लिक Auth0 एक्सपोर्ट" पर शक करना चाहिए जो उसके बिना पासवर्ड शामिल करने का दावा करता हो। समर्थित रास्ता एक सपोर्ट-सहायता-प्राप्त बल्क एक्सपोर्ट है: एक NDJSON फ़ाइल जिसमें हर यूज़र का bcrypt हैश हो। वह फ़ाइल हासिल करें और हैश हू-ब-हू इम्पोर्ट हो जाते हैं, लेज़ी माइग्रेशन सब कुछ के साथ, और मूव अदृश्य रहता है।

अगर आप उसका इंतज़ार नहीं कर सकते, तो फ़ॉलबैक उस माफ़ी-भरे पैराग्राफ़ का ईमानदार रूप है: यूज़र पहले साइन-इन पर एक नया पासवर्ड सेट करते हैं। कुछ खोया नहीं गया, क्योंकि साथ ले जाने को कोई हैश था ही नहीं। फ़र्क़ यह है कि आपने इसे जानते-बूझते चुना, न कि इसलिए कि टूल इससे बेहतर नहीं कर सका।

यह जितना सुनाई देता है उससे ज़्यादा क्यों मायने रखता है

एक थोपा गया रीसेट वह अकेली सबसे दृश्यमान, सबसे चिंताजनक चीज़ है जो आप माइग्रेशन के बीच अपने यूज़र-बेस के साथ कर सकते हैं। यह सपोर्ट लोड पैदा करता है, यह यूज़र को एक फ़िशिंग-नुमा "रीसेट करने के लिए यहाँ क्लिक करें" ईमेल की अपेक्षा करना सिखाता है, और यह वह पल है जब एक चुपचाप होने वाला इन्फ़्रास्ट्रक्चर बदलाव हर किसी की समस्या बन जाता है। इससे बचना ही ज़्यादातर वह चीज़ है जो एक माइग्रेशन को ऐसा महसूस कराती है मानो कुछ हुआ ही न हो, और एक माइग्रेशन ऐसा ही महसूस होना चाहिए।

तो "हर कोई रीसेट करता है" स्वीकार करने से पहले, वे दो सवाल पूछें। ज़्यादातर मूव के लिए दोनों का जवाब हाँ होता है, और वह माफ़ी-भरा पैराग्राफ़ कभी ज़रूरी था ही नहीं।

देखें कि एक इम्पोर्ट क्या-क्या साथ ले जाएगा — प्रीव्यू रीड-ओनली है और कुछ भी लिखे जाने से पहले आपको सब कुछ दिखाता है।