पासकी फॉलबैक और रिकवरी: आइडेंटिफायर-फर्स्ट एप्रोच

1. परिचय#

पासकी पारंपरिक ऑथेंटिकेशन विधियों का एक वास्तविक विकल्प बन गए हैं, जिसमें पासकी-रेडी डिवाइस लगभग 95% हैं। हालाँकि, सबसे उन्नत प्रणालियों को भी ऐसे परिदृश्यों को संबोधित करने के लिए प्रभावी फॉलबैक (Fallback) और रिकवरी (Recovery) रणनीतियों की आवश्यकता होती है जहाँ पासकी सुलभ नहीं हैं (फॉलबैक) या खो भी गए हैं (रिकवरी)। इस गाइड का उद्देश्य उन विभिन्न परिदृश्यों का पता लगाना है जहाँ फॉलबैक और रिकवरी आवश्यक हैं और चर्चा करना है कि संभावित समाधान कैसे दिखते हैं।

फॉलबैक और रिकवरी विधियों के बारे में सोचते समय, यह महत्वपूर्ण है कि उनकी मजबूती प्राथमिक ऑथेंटिकेशन विधि से मेल खाती हो। यह गाइड पासकी के विभिन्न उपयोगों के बीच अंतर करेगा, विशेष रूप से उन संदर्भों पर ध्यान केंद्रित करेगा जहाँ पासकी का उपयोग सेल्फ-कंटेन्ड MFA के रूप में किया जाता है, ताकि फॉलबैक और रिकवरी विधियों को उचित रूप से तैयार किया जा सके।

प्रमुख प्रश्न:

• कौन से फॉलबैक परिदृश्य मौजूद हैं? पासकी सिस्टम के साथ संभावित फॉलबैक परिदृश्य कौन से हो सकते हैं, और सुरक्षा बनाए रखने के लिए उन्हें कैसे संभाला जाना चाहिए?
• रिकवरी को कैसे संभाला जाना चाहिए? पासकी के उपयोग पैटर्न के आधार पर, विशेष रूप से MFA का उपयोग करने वाले वातावरण में, यह सुनिश्चित करने के लिए कि वे सुरक्षित हैं, रिकवरी प्रक्रियाओं को कैसे डिज़ाइन किया जाना चाहिए?

इन सवालों की खोज के माध्यम से, यह गाइड प्रोडक्ट मैनेजरों और डेवलपर्स को पासकी सिस्टम को प्रभावी ढंग से डिज़ाइन करने, लागू करने और प्रबंधित करने के लिए आवश्यक अंतर्दृष्टि प्रदान करेगा, यह सुनिश्चित करते हुए कि सुरक्षा उपयोगकर्ता अनुभव की कीमत पर नहीं आती है।

2. परिभाषाएँ: आइडेंटिफायर, सुरक्षा स्तर और फॉलबैक और रिकवरी#

फॉलबैक और रिकवरी रणनीतियों में गोता लगाने से पहले, हमारे द्वारा उपयोग किए जाने वाले कुछ मूलभूत शब्दों की स्पष्ट समझ स्थापित करना महत्वपूर्ण है।

2.1 आइडेंटिफायर: ईमेल, फोन नंबर और यूज़रनेम#

अधिकांश व्यावसायिक और उपभोक्ता प्रणालियों में, ऑथेंटिकेशन तीन प्राथमिक आइडेंटिफायर्स पर निर्भर करता है: ईमेल, फोन नंबर, और यूज़रनेम।

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

प्रारंभिक साइन-अप के दौरान, इन आइडेंटिफायर्स को आमतौर पर पुष्टिकरण लिंक / OTP (ईमेल के लिए) या OTP (फोन नंबर के लिए) के माध्यम से सत्यापित किया जाता है, यह सुनिश्चित करते हुए कि आइडेंटिफायर सही व्यक्ति का है। यदि एक्सेस खो जाता है, तो पहले सत्यापित ईमेल या फोन नंबर पर नियंत्रण साबित करना आमतौर पर अकाउंट एक्सेस को पुनर्स्थापित करने के लिए पर्याप्त होता है। चूँकि ये आइडेंटिफायर उपयोगकर्ताओं के साथ संचार के सबसे विश्वसनीय रूप हैं, फोन नंबर अक्सर MFA (मल्टी-फैक्टर ऑथेंटिकेशन) उद्देश्यों के लिए एकत्र किए जाते हैं, जिसमें SMS आमतौर पर उपयोग किया जाने वाला दूसरा फैक्टर होता है।

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

अन्य 2FA विकल्प, जैसे ऑथेंटिकेटर ऐप्स (जो TOTP कोड उत्पन्न करते हैं), किसी आइडेंटिफायर पर निर्भर नहीं करते हैं, लेकिन अक्सर एक औसत उपयोगकर्ता के लिए स्थापित करने के लिए अधिक जटिल होते हैं। पासकी ने बिना किसी आइडेंटिफायर के काम करने की संभावना भी पेश की है (यूज़रनेमलेस ऑथेंटिकेशन), एक ऐसी सुविधा जो क्रिप्टो स्पेस में तेजी से लोकप्रिय हो रही है। हालाँकि, उपभोक्ता और व्यावसायिक समाधानों दोनों के लिए, फॉलबैक या रिकवरी उद्देश्यों के लिए उपयोगकर्ताओं के साथ संवाद करने की आवश्यकता (अक्सर ईमेल के माध्यम से) यूज़रनेमलेस सिस्टम को कम व्यावहारिक बनाती है।

2.2 सुरक्षा स्तर: सिंगल-फैक्टर-ऑथेंटिकेशन (SFA) और मल्टी-फैक्टर-ऑथेंटिकेशन (MFA)#

सिंगल-फैक्टर ऑथेंटिकेशन (SFA) सिस्टम वे हैं जो उपयोगकर्ता की पहचान सत्यापित करने के लिए ऑथेंटिकेशन के एक रूप पर निर्भर करते हैं। आमतौर पर, यह सिंगल फैक्टर एक पासवर्ड होता है, लेकिन यह सोशल लॉगिन, ईमेल OTP या कोई भी तरीका हो सकता है जिसके लिए केवल एक प्रकार के प्रमाण की आवश्यकता होती है। आज वेब पर अधिकांश सिस्टम SFA-सिस्टम हैं। हालाँकि, सुरक्षा के साथ एक प्रसिद्ध ट्रेड-ऑफ़ है। पासकी को एकीकृत करते समय, ये आम तौर पर पारंपरिक पासवर्ड के ऐड-ऑन या प्रतिस्थापन के रूप में काम करते हैं, जिससे सिस्टम की सुविधा बढ़ती है। इस तरह के सिस्टम के लिए ईमेल OTP या सोशल लॉगिन जैसे फॉलबैक विकल्पों की अनुमति देना आम बात है, जो पासवर्ड को कम करके उपयोगकर्ता अनुभव में सुधार करता है लेकिन सिस्टम की सुरक्षा को SFA से आगे नहीं बढ़ाता है।

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

2.3 फॉलबैक और रिकवरी#

फॉलबैक का उपयोग उन सभी प्रणालियों में किया जाता है जहाँ कई ऑथेंटिकेशन विधियाँ सह-अस्तित्व में होती हैं। उनका उपयोग तब किया जाता है जब प्राथमिक विधियाँ उपलब्ध नहीं होती हैं – अक्सर उपयोगकर्ता के पास शुरुआत में यह विकल्प होता है कि साइन अप कैसे करें (जैसे सोशल लॉगिन बनाम पासवर्ड)। एक फॉलबैक में वैकल्पिक ऑथेंटिकेशन रणनीतियाँ शामिल हो सकती हैं जैसे ईमेल के माध्यम से OTP, पासवर्ड, मेल खाने वाले ईमेल के साथ सोशल लॉगिन, नेटिव ऐप पुश, QR कोड, या सुरक्षा कुंजियाँ (security keys)। इनमें से प्रत्येक फॉलबैक विधि सुरक्षा गुणवत्ता में भिन्न होती है, और सुरक्षा आवश्यकताओं के साथ उपयोगकर्ता सुविधा को संतुलित करने में उपयुक्त फॉलबैक विकल्प का चयन करना महत्वपूर्ण है।

मल्टी-फैक्टर ऑथेंटिकेशन (MFA) सिस्टम के हिस्से के रूप में पासकी का उपयोग करने वाले वातावरण में, इन फॉलबैक विधियों पर सावधानीपूर्वक विचार किया जाना चाहिए ताकि यह सुनिश्चित हो सके कि वे पासकी के तुलनीय मल्टी-फैक्टर सुरक्षा प्रदान करते हैं। रिकवरी प्रक्रियाएँ तब महत्वपूर्ण हो जाती हैं जब उपयोगकर्ता स्थापित सभी ऑथेंटिकेशन उपायों तक पहुँच खो देते हैं जो आवश्यक सुरक्षा मानकों (SFA या MFA) को पूरा करते हैं। यह सिंगल-फैक्टर सिस्टम में कम महत्वपूर्ण है, जहाँ कई रिकवरी विकल्प उपलब्ध हो सकते हैं, जैसे कि ईमेल OTP के माध्यम से पासवर्ड रीसेट करना, जो प्रभावी रूप से संबंधित आइडेंटिफायर पर उपयोगकर्ता के नियंत्रण को मान्य करता है। हालाँकि, रिकवरी विशेष रूप से 2FA/MFA सिस्टम में चुनौतीपूर्ण है क्योंकि ये सिस्टम सत्यापन के लिए अंतर्निहित रूप से कई कारकों पर निर्भर करते हैं। ऐसे परिदृश्यों में जहाँ कोई उपयोगकर्ता मोबाइल ऑपरेटिंग सिस्टम बदलता है - उदा. iPhone से Android फोन - और संबंधित पासकी और फोन नंबर खो देता है - शेष कारक (जैसे, केवल एक पासवर्ड) 2FA आवश्यकताओं को पूरा नहीं कर सकते हैं। इन उदाहरणों में रिकवरी के लिए पहचान के नए प्रमाण बनाने की आवश्यकता हो सकती है, जिसमें मैन्युअल सहायता अनुरोध या अधिक नवीन समाधान शामिल हो सकते हैं जिन्हें हम बाद में कवर करेंगे।

3. पासकी लॉगिन फॉलबैक: मैन्युअल पासकी लॉगिन बनाम स्वचालित पासकी लॉगिन#

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

3.1 मैन्युअल पासकी लॉगिन: यूज़र-इनिशिएटेड एप्रोच#

3.1.1 यूज़र-इनिशिएटेड एप्रोच क्या है?#

छोटे प्लेटफ़ॉर्म या ऐसे प्लेटफ़ॉर्म जो उच्च पासकी लॉगिन दर पर ध्यान केंद्रित नहीं करते हैं, उनके लिए यूज़र-इनिशिएटेड एप्रोच में एक अलग "Sign in with passkey" (पासकी के साथ साइन इन करें) बटन शामिल होता है। इस दृष्टिकोण में, पासकी का उपयोग करने की जिम्मेदारी पूरी तरह से उपयोगकर्ता पर डाल दी जाती है। अपने अकाउंट में एक पासकी जोड़ने के बाद, उपयोगकर्ता को इसका उपयोग करके लॉग इन करने के लिए "Sign in with passkey" पर क्लिक करना याद रखना चाहिए।

स्क्रीनशॉट https://my.gov.au का पासकी कार्यान्वयन दिखाता है, जो मैन्युअल पासकी लॉगिन दृष्टिकोण का उपयोग करता है। जबकि इस दृष्टिकोण को लागू करना आसान है क्योंकि बैकएंड को यह निर्धारित करने की आवश्यकता नहीं है कि पासकी लॉगिन संभव है या नहीं, यह आम तौर पर बहुत कम पासकी लॉगिन दर की ओर ले जाता है। ऐसा इसलिए है क्योंकि यह उपयोगकर्ता की पहल पर बहुत अधिक निर्भर करता है, और उपभोक्ताओं को शायद याद न हो या यकीन न हो कि उनकी पासकी किस प्लेटफ़ॉर्म या क्लाउड स्टोरेज पर रहती है। यह दृष्टिकोण उपयोगकर्ता को सोचने पर मजबूर करता है। आइए अगले अनुभाग में देखें कि इस दृष्टिकोण के साथ कौन से संभावित फॉलबैक अवसर मौजूद हैं।

3.1.2 फॉलबैक#

किसी भी ऐसी प्रणाली में फॉलबैक आवश्यक हैं जहाँ पासकी एक्सेस विफल होने की संभावनाएँ हों। मैन्युअल पासकी लॉगिन दृष्टिकोण में, संवादों और फॉलबैक को व्यक्तिगत रूप से प्रबंधित नहीं किया जा सकता है क्योंकि सभी लॉगिन विकल्प एक ही समय में प्रदर्शित होते हैं और पासकी उपयोगकर्ता के विवेक पर चुने जाते हैं। यह कई चुनौतियों की ओर जाता है:

• भ्रामक त्रुटियाँ (Unintuitive Errors): पासकी के अनुपलब्ध होने या गलत तरीके से सेट अप होने पर उपयोगकर्ताओं को जो त्रुटि संदेश मिलते हैं, वे अक्सर स्पष्ट नहीं होते हैं और भ्रम पैदा कर सकते हैं। उपयोगकर्ता शायद समझ न पाएँ कि वे पासकी का उपयोग करने में असमर्थ क्यों हैं या क्या गलत हुआ, जिससे निराशा होती है।
• डेड एंड्स (Dead Ends): उपयोगकर्ता खुद को ऐसे डेड एंड्स पर पा सकते हैं जहाँ वे आगे नहीं बढ़ सकते। यदि पासकी गायब हैं या दुर्गम हैं, तो उपयोगकर्ताओं को आगे बढ़ने या एक्सेस पुनः प्राप्त करने के तरीके के बारे में कोई स्पष्ट मार्गदर्शन नहीं दिया जा सकता है, जिससे वे लॉगिन प्रक्रिया को छोड़ देते हैं।
• मार्गदर्शन न करना (Not Guiding): इन स्थितियों में, सिस्टम उपयोगकर्ताओं को वैकल्पिक ऑथेंटिकेशन विधि की ओर मार्गदर्शन करने के लिए उपयोगी निर्देश प्रदान नहीं कर सकता है। समस्या को कैसे हल किया जाए, यह पता लगाने के लिए उपयोगकर्ताओं को अपने दम पर छोड़ दिया जाता है, जो उपयोगकर्ता अनुभव को कम करता है।

उपरोक्त उदाहरण दिखाता है कि विंडोज 11 के त्रुटि संदेश कितने भ्रामक होते हैं, जब पासकी प्लेटफॉर्म ऑथेंटिकेटर पर नहीं मिलती हैं। सिस्टम यह मान सकता है कि पासकी किसी सुरक्षा कुंजी (security key) या किसी अन्य डिवाइस पर रहती है। यह प्रक्रिया उन उपयोगकर्ताओं के लिए भ्रामक हो सकती है जो इस तरह के ऑथेंटिकेशन फ़्लो से अपरिचित हैं, खासकर अगर उन्होंने पहले कभी किसी सुरक्षा कुंजी का उपयोग नहीं किया है या कभी कोई पासकी नहीं बनाई है।

यदि प्लेटफॉर्म ऑथेंटिकेटर पर कोई पासकी नहीं मिलती है, तो ऑपरेटिंग सिस्टम और ब्राउज़र मानते हैं कि उन्हें कहीं और मौजूद होना चाहिए, जिससे और भ्रम पैदा होता है यदि उपयोगकर्ता ने अभी तक कोई पासकी नहीं बनाई है। कंडीशनल यूआई (Conditional UI) मौजूदा पासकी को प्रदर्शित करके मदद कर सकता है, लेकिन यह केवल तभी मदद करता है जब पासकी वास्तव में मौजूद हों। सर्वोत्तम पासकी अनुभव के लिए, बैकएंड को यह तय करना चाहिए कि उपयोगकर्ता द्वारा अपना प्राथमिक आइडेंटिफायर प्रदान करने के बाद पासकी लॉगिन ट्रिगर किया जाना चाहिए या नहीं।

3.2 स्वचालित पासकी लॉगिन: आइडेंटिफायर-फर्स्ट एप्रोच#

3.2.1 आइडेंटिफायर-फर्स्ट एप्रोच क्या है?#

आइडेंटिफायर-फर्स्ट दृष्टिकोण में, उपयोगकर्ताओं को सिस्टम द्वारा पासकी लॉगिन संभव होने का निर्धारण करने से पहले अपना प्राथमिक आइडेंटिफायर, जैसे ईमेल या फोन नंबर प्रदान करने के लिए प्रेरित किया जाता है। आइडेंटिफायर सत्यापित होने के बाद, सिस्टम स्वचालित रूप से सबसे उपयुक्त लॉगिन विधि सुझाता है, जिसमें पासकी भी शामिल हैं यदि वे उपलब्ध और सुलभ हैं। यह दृष्टिकोण अधिक उपयोगकर्ता के अनुकूल है क्योंकि यह उपयोगकर्ताओं को "Sign in with passkey" विकल्प चुनने के लिए याद रखने की आवश्यकता को समाप्त करता है और प्रक्रिया को सुव्यवस्थित करके अपनाने की दर को बढ़ाता है।

Google आइडेंटिफायर-फर्स्ट साइन-इन

Google पासकी साइन-इन

उपरोक्त स्क्रीनशॉट उस अकाउंट के लिए Google लॉगिन के व्यवहार को दिखाते हैं जहाँ macOS डिवाइस पर पासकी संबद्ध है। Google भी आइडेंटिफायर-फर्स्ट दृष्टिकोण का अनुसरण करता है और यह निर्धारित करता है कि पासकी लॉगिन बहुत संभव होगा:

1. पासकी प्लेटफ़ॉर्म समर्थन: अंतर्निहित प्लेटफ़ॉर्म एक प्लेटफ़ॉर्म ऑथेंटिकेटर का समर्थन करता है इसलिए लॉगिन संभव हो सकता है।
2. पासकी सुलभ है: पासकी इस क्लाइंट (macOS) पर बहुत संभवतः सुलभ होगी क्योंकि इसे macOS सिस्टम पर बनाया गया था।

नतीजतन, एक पासकी लॉगिन स्वचालित रूप से शुरू हो जाता है, जो उपयोगकर्ता को सर्वोत्तम संभव अनुभव के लिए मार्गदर्शन करता है। यह "मुझे सोचने पर मजबूर न करें" (don't make me think) रणनीति का पालन करता है।

3.2.2 पासकी प्लेटफ़ॉर्म समर्थन या पासकी एक्सेसिबिलिटी का अभाव#

सिस्टम निर्धारित करता है कि पासकी लॉगिन संभव है या नहीं। यदि:

• कोई पासकी मौजूद नहीं है: उपयोगकर्ता ने अभी तक अपने खाते के लिए पासकी नहीं बनाई है
• पासकी सुलभ नहीं हैं: उपयोगकर्ता द्वारा बनाई गई पासकी इस क्लाइंट पर बहुत संभवतः उपलब्ध नहीं हैं (उदाहरण के लिए उपयोगकर्ता के पास केवल एक MacOS पासकी है और अब वह Windows से लॉग इन करता है)।
• पासकी ऑथेंटिकेशन समर्थित नहीं है: वर्तमान क्लाइंट प्लेटफ़ॉर्म ऑथेंटिकेटर का समर्थन नहीं करता है और QR कोड के माध्यम से क्रॉस-डिवाइस-ऑथेंटिकेशन का समर्थन करने की भी बहुत कम संभावना है

निर्णय यह होगा कि एक सफल पासकी लॉगिन की संभावना नहीं है और इसलिए पासकी लॉगिन को ट्रिगर किए बिना फॉलबैक विकल्प स्वचालित रूप से प्रदान किए जाएंगे। यह दृष्टिकोण बहुत अधिक उपयोगकर्ता के अनुकूल है क्योंकि यह उपयोगकर्ताओं को "Sign in with passkey" विकल्प चुनने के लिए याद रखने की आवश्यकता को समाप्त करता है, प्रक्रिया को सुव्यवस्थित करके अपनाने की दर को बढ़ाता है, और सबसे खराब स्थिति से बचाता है जहां एक भ्रामक डेड एंड उपयोगकर्ता को दिखाया जाता है।

उपरोक्त उदाहरण में, लॉगिन पासवर्ड पर वापस आ जाता है और फिर खाते की स्थिति और सुरक्षा के आधार पर आगे ऑथेंटिकेशन कारकों के लिए पूछना जारी रखेगा, क्योंकि क्लाइंट विंडोज 11 डिवाइस है, जिसके macOS पासकी तक पहुंच होने की संभावना नहीं है। आपकी ऑथेंटिकेशन प्रणाली की सुरक्षा आवश्यकताओं के आधार पर, ऐसे मामले में कौन सी ऑथेंटिकेशन विधि को ट्रिगर करना है (जैसे, अंतिम सफल गैर-पासकी ऑथेंटिकेशन विकल्प), इस पर आपका पूरा नियंत्रण होता है।

3.2.3 पासकी सेरेमनी एबॉर्ट्स#

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

पहली एबॉर्ट स्क्रीन को स्पष्ट रूप से समझाना चाहिए कि शांत और आश्वस्त करने वाले तरीके से क्या हो रहा है, यह अनुशंसा करते हुए कि उपयोगकर्ता प्रक्रिया को फिर से आज़माए (उपरोक्त Google उदाहरण देखें)। इस स्क्रीन को चिंता कम करने के लिए डिज़ाइन किया जाना चाहिए, एबॉर्ट को उपयोगकर्ता अनुभव के नियमित, अपेक्षित हिस्से के रूप में मानना चाहिए। कई उपयोगकर्ता केवल इसलिए निरस्त कर सकते हैं क्योंकि उन्होंने ऑथेंटिकेशन स्क्रीन को नहीं पहचाना या प्रक्रिया से अपरिचित थे। इसलिए, एक पुनः प्रयास (retry) डिफ़ॉल्ट सुझाव होना चाहिए।

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

दूसरी एबॉर्ट स्क्रीन को उपयोगकर्ता को वैकल्पिक ऑथेंटिकेशन विधि पर स्विच करने के लिए प्रोत्साहित करना चाहिए। इसे यह सुनिश्चित करना चाहिए कि उपयोगकर्ता बिना किसी और निराशा के सफलतापूर्वक लॉग इन कर सके। जैसा कि हम ऊपर स्क्रीन पर देख सकते हैं, Google अभी भी "Try again" का सुझाव देता है लेकिन साथ ही उपयोगकर्ता को यह भी दिखाता है कि शायद कुछ गलत हो गया है।

3.3 पासकी कार्यान्वयन दृष्टिकोणों की तुलना#

निम्नलिखित तालिका सबसे महत्वपूर्ण विशेषताओं को सारांशित करके विभिन्न दृष्टिकोणों की तुलना करने में मदद करती है:

डू-इट-योरसेल्फ (Do-it-yourself) दृष्टिकोण आमतौर पर मैन्युअल पासकी लॉगिन दृष्टिकोण का पालन करते हैं और कंडीशनल यूआई (Conditional UI) और उपयोगकर्ता को पासकी में ऑप्ट-इन करने पर निर्भर करते हैं, जिसके परिणामस्वरूप बहुत कम पासकी लॉगिन दरें और निराश उपयोगकर्ता होते हैं। आइडेंटिफायर-फर्स्ट दृष्टिकोण को कंडीशनल यूआई के शीर्ष पर अच्छी तरह से सोची-समझी डिवाइस लॉजिक स्थापित करने की आवश्यकता होती है, जो कि वह जगह है जहाँ Corbado आपकी मदद कर सकता है। अपना खुद का डिवाइस लॉजिक और पासकी इंटेलिजेंस (passkey intelligence) बनाना अनुशंसित नहीं है, क्योंकि इस नियम सेट को नए उपकरणों, नई WebAuthn और क्लाउड सिंक कार्यक्षमता (जैसे GPM पासकी) में निरंतर बदलाव और समायोजन की आवश्यकता होती है।

4. पासकी रिकवरी#

जब उपयोगकर्ता अपने पासकी तक पहुंच खो देते हैं, तो पासकी रिकवरी सुरक्षा और उपयोगकर्ता अनुभव को बनाए रखने का एक महत्वपूर्ण पहलू है। यह उन प्रणालियों में विशेष रूप से महत्वपूर्ण है जो MFA पर निर्भर हैं। MFA मामलों में, रिकवरी प्रक्रियाओं को यह सुनिश्चित करना चाहिए कि सुरक्षा सुरक्षित है जबकि उपयोगकर्ताओं को अपने खातों तक पहुंच प्राप्त करने की अनुमति मिलती है। रिकवरी दृष्टिकोण को सिस्टम में उपयोग किए गए ऑथेंटिकेशन के स्तर के आधार पर तैयार किया जाना चाहिए।

4.1 सिंगल-फैक्टर रिकवरी और मल्टी-फैक्टर रिकवरी#

SFA प्रणालियों में सुरक्षा बनाए रखने के लिए, रिकवरी में आम तौर पर एक आइडेंटिफायर जैसे ईमेल पते या मोबाइल फोन नंबर पर नियंत्रण साबित करना शामिल होता है।

• ईमेल OTP: उपयोगकर्ता के पंजीकृत ईमेल पते पर एक OTP भेजा जाता है। एक बार सत्यापित होने के बाद, यह उपयोगकर्ता को एक्सेस पुनः प्राप्त करने और एक नई पासकी बनाने की अनुमति देता है।
• SMS OTP: ईमेल रिकवरी के समान, पंजीकृत मोबाइल फोन नंबर पर एक OTP भेजा जाता है। उपयोगकर्ता अपने खाते तक पहुँच प्राप्त करने के लिए इस OTP का उपयोग कर सकता है।

हालांकि ये विधियाँ सीधी हैं, वे उपयोगकर्ता की संपर्क जानकारी को अद्यतित रखने पर निर्भर करती हैं। इसलिए, नियमित लॉगिन के दौरान उपयोगकर्ताओं को अपने ईमेल और फोन नंबर को सत्यापित करने के लिए नियमित रूप से प्रेरित करना आवश्यक है।

मल्टी-फैक्टर ऑथेंटिकेशन सिस्टम में, रिकवरी अधिक जटिल हो जाती है। चूँकि MFA कई स्वतंत्र कारकों (जैसे, पासकी, सोशल लॉगिन, और OTP) पर निर्भर करता है, उपयोगकर्ताओं को केवल इसलिए एक्सेस नहीं खोना चाहिए क्योंकि एक कारक (जैसे पासकी) अनुपलब्ध है।

• वैकल्पिक कारकों का उपयोग करना: यदि पासकी खो जाती है, तो उपयोगकर्ता दो अन्य कारकों का उपयोग करके प्रमाणित कर सकता है, जैसे कि पासवर्ड + SMS OTP या एक ऑथेंटिकेटर ऐप। एक बार प्रमाणित होने के बाद, वे एक नई पासकी बना सकते हैं।
• अन्य पासकी का उपयोग करना: यदि उपयोगकर्ता के पास पासकी वाले अन्य डिवाइस हैं, तो वे उचित संकेतों के साथ एक्सेस प्राप्त करने के लिए उनका उपयोग कर सकते हैं (जैसे iPhone से पासकी के उपयोग का अनुरोध करना)।
• नई पासकी बनाएँ: रिकवरी विधि के साथ प्रमाणित करने के बाद, उपयोगकर्ता को यह सुनिश्चित करने के लिए एक नई पासकी बनाने के लिए निर्देशित किया जाना चाहिए कि MFA सेटअप बरकरार रहे।

SFA और MFA दोनों प्रणालियों के लिए, कुंजी यह सुनिश्चित कर रही है कि उपयोगकर्ता के लिए घर्षण को कम करते हुए रिकवरी प्रक्रियाएं मजबूत और सुरक्षित हों।

4.2 स्मार्ट MFA रिकवरी: MFA रिकवरी लागतों को डिजिटल बनाना#

संवेदनशील व्यक्तिगत डेटा, विनियमित उद्योगों, या सरकारी (government) सेवाओं को संभालने वाले सिस्टम में, रिकवरी के लिए मानक ईमेल OTP और मोबाइल नंबर OTP हमेशा पर्याप्त या उपलब्ध नहीं हो सकते हैं। ऐसे मामलों में, स्मार्ट MFA रिकवरी तंत्र खाता रिकवरी के लिए उन्नत तरीके प्रदान करते हैं जो उपयोगकर्ताओं को एक सहज अनुभव प्रदान करते हुए उच्च सुरक्षा मानकों को बनाए रखते हैं।

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

यह विधि विशेष रूप से तब उपयोगी हो सकती है जब पारंपरिक रिकवरी विधियाँ जैसे ईमेल या SMS OTP अनुपलब्ध या पुरानी हो। उदाहरण के लिए, यहाँ एक सेल्फी लेने का एक उदाहरण दिया गया है जिसके बाद onfido से लाइवनेस चेक किया जाता है:

उदाहरण: onfido से लाइवनेस चेक के साथ सेल्फी आईडेंट (Selfie Ident)

• सरकारी सिस्टम, विनियमित उद्योग या बड़ी व्यावसायिक सेवाओं के पास व्यक्तिगत डेटा उपलब्ध होता है जिसका उपयोग ID पर उपलब्ध जानकारी को सत्यापित करने के लिए किया जा सकता है। मामले में उदा. जन्मतिथि उपलब्ध नहीं है, ID के माध्यम से एकत्र की गई जानकारी का उपयोग मैन्युअल रिकवरी प्रक्रिया में एक कारक के रूप में किया जा सकता है।

इसके अतिरिक्त, अन्य स्मार्ट रिकवरी विधियों में शामिल हो सकते हैं:

• क्रॉस-डिवाइस रिकवरी: यदि किसी उपयोगकर्ता के पास एक विश्वसनीय द्वितीयक डिवाइस है, तो वे QR कोड को स्कैन करके अपना खाता पुनर्प्राप्त कर सकते हैं।
• ज्ञात वातावरण (Known environments): जिन उपयोगकर्ताओं के पास अभी भी उसी डिवाइस की पहुंच है जिसका उन्होंने अतीत में सफलतापूर्वक उपयोग किया था, वे इस डिवाइस का उपयोग करके अतिरिक्त सुनिश्चित करने वाले कारक प्रदान कर सकते हैं और इसलिए प्रमाण प्रदान कर सकते हैं कि वे मैन्युअल रिकवरी प्रक्रिया में मदद करने के लिए उसी डिवाइस, प्रदाता और स्थान से कार्य कर रहे हैं। Google द्वारा Gmail Account Recovery के लिए उपयोग किया जाने वाला एक दृष्टिकोण।
• डिजिटल क्रेडेंशियल्स API: ID वॉलेट के बढ़ते उपयोग के साथ, इस API के माध्यम से प्रत्यक्ष सत्यापन सुरक्षित और उपयोगकर्ता के अनुकूल खाता रिकवरी में बढ़ती भूमिका निभाने की उम्मीद है।

स्मार्ट MFA रिकवरी विधियों का उद्देश्य उपयोगकर्ताओं को अपने खातों तक पहुंच प्राप्त करने के लिए सुरक्षित, सहज तरीके प्रदान करना है, खासकर जब अत्यधिक संवेदनशील या विनियमित जानकारी से निपटते हैं। ये दृष्टिकोण यह सुनिश्चित करते हैं कि उन मामलों में भी जहां पारंपरिक तरीके जैसे ईमेल या फोन रिकवरी उपलब्ध नहीं हैं, उपयोगकर्ता अभी भी अपने एक्सेस को सुरक्षित और कुशलता से पुनर्स्थापित कर सकते हैं। स्मार्ट रिकवरी MFA रिकवरी की लागत को कम करने में मदद करती है।

4.3 MFA रिकवरी आवृत्तियाँ: फोन नंबर बनाम पासकी#

यह ध्यान रखना महत्वपूर्ण है कि क्योंकि पासकी क्लाउड में सिंक्रनाइज़ किए जाते हैं, 36 महीने की अवधि में MFA रिकवरी लागत बहुत कम होती है, क्योंकि मोबाइल फोन नंबर बदलना Apple से Android या इसके विपरीत स्विच करने की तुलना में बहुत अधिक बार होता है। फोन या फोन अनुबंध परिवर्तन की स्थिति में पासकी बहाल कर दिए जाएंगे।

इसलिए, सिंक्ड पासकी तक पहुंच खोना मोबाइल नंबर तक पहुंच खोने की तुलना में कम बार होगा, जो पारंपरिक उपभोक्ता-उन्मुख MFA प्रणालियों के लिए अधिकांश रिकवरी दर्द का कारण बनता है।

फिर भी बढ़ते उपयोगकर्ता आधार के साथ ऐसे मामले अभी भी महत्वपूर्ण मैन्युअल समर्थन लागत का कारण बनते हैं और उन्हें एक डिजिटल समाधान के साथ संभाला जाना चाहिए, जिसे हम अगले भाग में देखेंगे।

5. प्रोडक्ट मैनेजर्स और डेवलपर्स के लिए सिफ़ारिशें#

पासकी को अपने ऑथेंटिकेशन सिस्टम में एकीकृत करते समय, एक सहज उपयोगकर्ता अनुभव सुनिश्चित करते हुए उच्च स्तर की सुरक्षा बनाए रखने के लिए फॉलबैक विकल्पों और रिकवरी रणनीतियों दोनों की सावधानीपूर्वक योजना बनाना महत्वपूर्ण है। पासकी लॉगिन की लॉगिन दर को अधिकतम करने के लिए, निम्नलिखित सिफारिशों पर विचार करें:

• आइडेंटिफायर-फर्स्ट एप्रोच चुनें: यह दृष्टिकोण अधिक उपयोगकर्ता के अनुकूल है और लॉगिन प्रक्रिया में घर्षण को कम करता है। उपयोगकर्ताओं को पहले अपना प्राथमिक आइडेंटिफायर (उदा., ईमेल या फोन नंबर) इनपुट करने के लिए कहकर, सिस्टम स्वचालित रूप से यह निर्धारित कर सकता है कि पासकी लॉगिन संभव है या नहीं। यह उपयोगकर्ता को मैन्युअल रूप से पासकी विकल्प चुनने पर निर्भर किए बिना एक सहज, सहज लॉगिन अनुभव सुनिश्चित करता है।
• बेहतर उपयोगकर्ता अनुभव के लिए व्याख्यात्मक एबॉर्ट स्क्रीन (explatory Abort Screens) का उपयोग करें: हालांकि सुरक्षा सर्वोच्च प्राथमिकता होनी चाहिए, एक ऐसी प्रक्रिया को डिज़ाइन करना आवश्यक है जो उपयोगकर्ता को पासकी अपनाने में मदद करे। सुनिश्चित करें कि पहली बार सेरेमनी एबॉर्ट्स को सामान्य माना जाता है, और पुनः प्रयास करने के लिए स्पष्ट मार्गदर्शन दें।
• फॉलबैक और रिकवरी विकल्पों को सुरक्षित रखें: सुनिश्चित करें कि फॉलबैक विधियाँ (जैसे ईमेल OTP और/या SMS OTP) प्राथमिक ऑथेंटिकेशन विधि के सुरक्षा स्तर से मेल खाती हैं। उदाहरण के लिए, एक MFA सिस्टम में जो पासकी का उपयोग करता है, फॉलबैक को भी समान सुरक्षा मानक बनाए रखने के लिए कई कारकों की आवश्यकता होनी चाहिए।
• नियमित रिकवरी प्रॉम्प्ट्स को स्वचालित करें: नियमित रूप से उपयोगकर्ताओं को लॉगिन के दौरान अपनी संपर्क जानकारी (ईमेल पता या फोन नंबर) सत्यापित करने के लिए प्रेरित करें ताकि यह सुनिश्चित हो सके कि जब वे पासकी का उपयोग करते हैं तो रिकवरी विकल्प अद्यतित रहते हैं। यह पुराने रिकवरी तरीकों के कारण उपयोगकर्ताओं को उनके खातों से लॉक किए जाने की संभावना को कम करता है।
• बढ़ी हुई सुरक्षा और कम समर्थन रिकवरी लागतों के लिए स्मार्ट रिकवरी विधियों पर विचार करें: विनियमित उद्योगों या ऑनलाइन पहचान के खिलाफ जांच करने के लिए व्यक्तिगत डेटा तक पहुंच वाले सिस्टम के लिए, लाइवनेस चेक के साथ सेल्फी पहचान जैसे उन्नत रिकवरी विधियों पर विचार करें। यह विधि आपकी सुरक्षा आवश्यकताओं के आधार पर रिकवरी प्रक्रिया को सहज और उपयोगकर्ता के अनुकूल रखते हुए सुरक्षा की अतिरिक्त परतें प्रदान कर सकती है।

पासकी लॉगिन दर को अधिकतम करना इस बात पर निर्भर करता है कि आप इन तत्वों को कितनी अच्छी तरह लागू करते हैं। सुचारू फॉलबैक और रिकवरी विकल्प सुनिश्चित करने से उपयोगकर्ताओं को अपनी प्राथमिक ऑथेंटिकेशन विधि के रूप में पासकी का उपयोग करने का विश्वास मिलेगा।

6. Corbado आपके लिए क्या कर सकता है: UI कंपोनेंट्स और पासकी इंटेलिजेंस#

Corbado ग्रीनफील्ड परियोजनाओं (greenfield projects) के लिए आइडेंटिफायर-फर्स्ट दृष्टिकोण को लागू करने के लिए आवश्यक सब कुछ प्रदान करता है जिन्हें पूरी तरह से नए ऑथेंटिकेशन सिस्टम की आवश्यकता होती है और मौजूदा परियोजनाओं के लिए जिन्हें मौजूदा ऑथेंटिकेशन सिस्टम में पासकी जोड़ने की आवश्यकता होती है।

6.1 विभिन्न उपयोग-मामलों के लिए UI कंपोनेंट्स#

दोनों उत्पाद UI कंपोनेंट्स प्रदान करते हैं जिन्हें आपकी आवश्यकताओं के अनुरूप बनाया जा सकता है:

1. Corbado Complete: पासकी-फर्स्ट ऑथेंटिकेशन के साथ अपनी परियोजना शुरू करें
   यह हमारा संपूर्ण ऑथेंटिकेशन सिस्टम है, जिसमें लॉगिन प्रक्रिया को सुव्यवस्थित करने के लिए एक सहज आइडेंटिफायर-फर्स्ट दृष्टिकोण शामिल है। Corbado Complete उपयोगकर्ता द्वारा अपना आइडेंटिफायर प्रदान करने के बाद यह स्वचालित रूप से निर्धारित करके एक सुरक्षित और उपयोगकर्ता के अनुकूल अनुभव सक्षम बनाता है कि पासकी लॉगिन संभव है या नहीं। यह घर्षण को कम करता है और एक सहज लॉगिन अनुभव सुनिश्चित करता है, जो पासकी को अपनाने को अधिकतम करने के लिए महत्वपूर्ण है।
2. Corbado Connect: किसी भी ऐप में बिना माइग्रेशन के पासकी जोड़ें
   उन व्यवसायों के लिए जिन्होंने पहले से ही ऑथेंटिकेशन प्रक्रियाएं स्थापित कर ली हैं और एक एन्हांसमेंट के रूप में पासकी जोड़ना चाहते हैं, Corbado Connect सिंगल-फैक्टर और मल्टी-फैक्टर-रणनीतियों के लिए एक ऐड-ऑन समाधान प्रदान करता है। यह दृष्टिकोण एक सुरक्षित और सुविधाजनक विकल्प के रूप में पासकी को मूल रूप से एकीकृत करके आपके मौजूदा बुनियादी ढांचे का पूरक है, जिससे उपयोगकर्ता आपके वर्तमान सिस्टम को ओवरहाल किए बिना पासकी के माध्यम से प्रमाणित कर सकते हैं। उदाहरण के लिए, Corbado Connect को Amazon Cognito में सहजता से एम्बेड किया जा सकता है।

हम विशेष रूप से उपभोक्ता-उन्मुख कंपनियों के लिए तैयार किए गए Google और बड़े तकनीकी क्षेत्र के अन्य प्रमुख खिलाड़ियों जैसे उद्योग के नेताओं के साथ अपने तरीकों को कड़ाई से संरेखित करते हैं।

6.2 पासकी इंटेलिजेंस (Passkey Intelligence) आइडेंटिफायर-फर्स्ट दृष्टिकोण को सक्षम बनाता है#

हमारा लक्ष्य केवल पासकी अपनाने (यानी, पासकी का निर्माण) को अधिकतम करना नहीं है, बल्कि यह भी सुनिश्चित करना है कि उच्च लॉगिन दरों को चलाने (और इसलिए सुरक्षा बढ़ाने और SMS OTP लागत कम करने) के लिए इन पासकी का सक्रिय रूप से उपयोग किया जाए। हमारे UI कंपोनेंट्स आइडेंटिफायर-फर्स्ट दृष्टिकोण को ध्यान में रखकर बनाए गए हैं और सीधे हमारी Passkey Intelligence से जुड़े हैं, जो क्लाइंट वातावरण और मौजूदा पासकी के आधार पर पासकी की उपलब्धता और पहुंच के बारे में निर्णय लेता है। वे सभी चर्चा किए गए फॉलबैक और रिकवरी कार्यक्षमताओं का समर्थन करते हैं। निम्नलिखित स्क्रीन हमारी एबॉर्ट और रिट्राई (retry) लॉजिक दिखाते हैं:

पहला पासकी एबॉर्ट

दूसरा पासकी एबॉर्ट

पासकी अपनाने और पासकी उपयोग दोनों पर ध्यान केंद्रित करके, हम आपको सुरक्षा और उपयोगकर्ता अनुभव के बीच संतुलन हासिल करने में मदद करते हैं, यह सुनिश्चित करते हुए कि उपयोगकर्ता घर्षण रहित तरीके से पासकी के साथ जुड़ना जारी रखें।

7. निष्कर्ष#

इस गाइड में, हमने ऑथेंटिकेशन सिस्टम में पासकी के एकीकरण के बाद विभिन्न फॉलबैक और रिकवरी रणनीतियों का पता लगाया है। परिचय में उठाए गए प्रमुख प्रश्नों को भर में संबोधित किया गया:

• कौन से फॉलबैक परिदृश्य मौजूद हैं? कई फॉलबैक परिदृश्य हो सकते हैं, जैसे कि पासकी समर्थन का अभाव या पासकी का किसी विशेष डिवाइस पर सुलभ न होना। सुरक्षा बनाए रखने और एक सुचारू UX प्रदान करने के लिए, जब पासकी लॉगिन संभव न हो तो ईमेल या SMS OTP जैसे फॉलबैक विकल्प उपलब्ध होने चाहिए।
• रिकवरी को कैसे संभाला जाना चाहिए? रिकवरी प्रक्रियाओं को ऑथेंटिकेशन सिस्टम के सुरक्षा स्तर से मेल खाने के लिए डिज़ाइन किया जाना चाहिए। SFA सिस्टम में, ईमेल या SMS OTP पर्याप्त हो सकता है, जबकि MFA सिस्टम में, एक्सेस प्राप्त करने और एक नई पासकी बनाने के लिए वैकल्पिक कारकों का उपयोग किया जाना चाहिए। अत्यधिक विनियमित या संवेदनशील वातावरण में, लाइवनेस चेक के साथ सेल्फी पहचान जैसे स्मार्ट रिकवरी विधियाँ अतिरिक्त सुरक्षा प्रदान करती हैं।

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

Corbado के बारे में

Corbado बड़े पैमाने पर consumer authentication चलाने वाली CIAM टीमों के लिए Passkey Intelligence Platform है। हम आपको वह दिखाते हैं जो IDP logs और सामान्य analytics tools नहीं दिखा सकते: कौन-से devices, OS versions, browsers और credential managers passkeys को support करते हैं, क्यों enrollments login में नहीं बदलते, WebAuthn flow कहाँ fail होता है, और कब कोई OS या browser update चुपचाप login को तोड़ देता है — और यह सब Okta, Auth0, Ping, Cognito या आपके in-house IDP को बदले बिना। दो products: Corbado Observe जोड़ता है passkeys और किसी भी अन्य login method के लिए observability। Corbado Connect देता है analytics के साथ built-in managed passkeys (आपके IDP के साथ-साथ)। VicRoads, Corbado के साथ 5M+ users के लिए passkeys चला रहा है (+80% passkey activation)। Passkey विशेषज्ञ से बात करें →

अक्सर पूछे जाने वाले प्रश्न#

जब वर्तमान डिवाइस पर पासकी सुलभ नहीं होती है तो आइडेंटिफायर-फर्स्ट दृष्टिकोण पासकी लॉगिन को कैसे संभालता है?#

जब पासकी के दुर्गम होने की संभावना होती है (उदा. विंडोज डिवाइस से एक्सेस की गई macOS पासकी), तो सिस्टम स्वचालित रूप से पासकी प्रॉम्प्ट को छोड़ देता है और इसके बजाय पासवर्ड या OTP जैसे फॉलबैक विकल्प प्रस्तुत करता है। यह 'डोंट मेक मी थिंक' रणनीति का पालन करते हुए केवल तब पासकी लॉगिन ट्रिगर करके भ्रामक डेड एंड से बचाता है जब सफलता की संभावना होती है।

जब कोई उपयोगकर्ता पासकी ऑथेंटिकेशन सेरेमनी को बीच में ही रद्द (abort) कर देता है तो क्या होना चाहिए?#

पहले निरस्तीकरण (abort) को एक सामान्य घटना के रूप में माना जाना चाहिए, जिसमें एक शांत स्क्रीन उपयोगकर्ता को पुनः प्रयास करने के लिए प्रोत्साहित करती है, क्योंकि कई उपयोगकर्ता केवल इसलिए निरस्त कर देते हैं क्योंकि वे ऑथेंटिकेशन स्क्रीन से अपरिचित होते हैं। यदि दूसरा एबॉर्ट होता है, तो सिस्टम को फॉलबैक ऑथेंटिकेशन विकल्प सामने लाने चाहिए, क्योंकि यह प्लेटफॉर्म ऑथेंटिकेटर या पासकी उपलब्धता के साथ वास्तविक समस्या का संकेत दे सकता है।

जब कोई उपयोगकर्ता अपने पासकी तक पहुंच खो देता है तो MFA सिस्टम के लिए कौन से रिकवरी विकल्प मौजूद हैं?#

MFA सिस्टम में, उपयोगकर्ता पासवर्ड प्लस SMS OTP जैसे दो वैकल्पिक कारकों के साथ प्रमाणित करके या किसी अन्य विश्वसनीय डिवाइस से पासकी का उपयोग करके, फिर एक नई पासकी बनाकर रिकवर कर सकते हैं। विनियमित उद्योगों के लिए जहां पारंपरिक रिकवरी विधियां अनुपलब्ध हैं, लाइवनेस चेक के साथ सेल्फी पहचान जैसे स्मार्ट तरीके एक अतिरिक्त सुरक्षित रिकवरी मार्ग प्रदान करते हैं।

मैन्युअल 'Sign in with passkey' बटन दृष्टिकोण के परिणामस्वरूप आइडेंटिफायर-फर्स्ट दृष्टिकोण की तुलना में कम अपनाए जाने का क्या कारण है?#

मैन्युअल दृष्टिकोण उपयोगकर्ताओं पर पासकी विकल्प को याद रखने और चुनने की पूरी जिम्मेदारी डालता है, जिसके परिणामस्वरूप आमतौर पर पासकी लॉगिन दर बहुत कम होती है। जब प्लेटफॉर्म ऑथेंटिकेटर पर पासकी नहीं मिलती है तो उपयोगकर्ताओं को स्पष्ट त्रुटि संदेश भी मिल सकते हैं, जिससे निराशा होती है और लॉगिन प्रयास छोड़ दिए जाते हैं।