प्रॉम्प्ट और संदर्भ
आपकी टीम पासकी लॉन्च कर रही है। सुरक्षा टीम एक डिवाइस या हार्डवेयर कुंजी से बंधे क्रेडेंशियल्स को प्राथमिकता देती है; प्रोडक्ट टीम को चिंता है कि डिवाइस बदलने के बाद उपयोगकर्ता पहुंच खो देंगे और वह सिंक किए गए पासकी चाहती है। थ्रेट मॉडल, रिकवरी, एश्योरेंस, एंटरप्राइज कंट्रोल और रिलाइंग पार्टी (relying party) क्या देख सकती है, इसकी व्याख्या करें।
"पासकी" को केवल एक एश्योरेंस स्तर के रूप में न मानें। इस बात को अलग-अलग करके देखें कि क्या कोई क्रेडेंशियल बैकअप-योग्य है, कई डिवाइसों पर उपयोग करने योग्य है, किसी एंटरप्राइज द्वारा शासित है, और डिवाइस खो जाने के बाद पुनर्प्राप्त करने योग्य (recoverable) है।
साक्षात्कारकर्ता क्या जांचता है
साक्षात्कारकर्ता यह उम्मीद करता है कि पासकी को WebAuthn पब्लिक-की क्रेडेंशियल्स के रूप में समझा जाए जिनके बैकअप और सिंक गुण अलग-अलग होते हैं। FIDO सिंक किए गए पासकी को पासकी प्रदाता के माध्यम से एक नए डिवाइस पर उपयोग करने योग्य बताता है, जबकि डिवाइस-बाउंड पासकी एक डिवाइस या सुरक्षा कुंजी पर ही रहते हैं। WebAuthn Level 3 बैकअप पात्रता (backup eligibility) और बैकअप स्थिति (backup state) को परिभाषित करता है; NIST सिंक करने योग्य ऑथेंटिकेटर के लिए मार्गदर्शन प्रदान करता है।
मजबूत उत्तर यूजर एक्सपीरियंस, अकाउंट रिकवरी, एंटरप्राइज लाइफसाइकिल, प्रदाता ट्रस्ट और उच्च-एश्योरेंस क्रियाओं को अलग-अलग करते हैं। वे सिंक को "असुरक्षित" या डिवाइस बाइंडिंग को "रिकवरी की आवश्यकता नहीं" के बराबर नहीं मानते हैं।
30-सेकंड का उत्तर
"दोनों फ़िशिंग-प्रतिरोधी पब्लिक-की ऑथेंटिकेशन प्रदान कर सकते हैं, लेकिन सिंक किए गए क्रेडेंशियल मल्टी-डिवाइस रिकवरी में सुधार करते हैं जबकि डिवाइस-बाउंड क्रेडेंशियल उन नीतियों के अनुकूल होते हैं जिनके लिए नॉन-कॉपीबिलिटी और केंद्रीकृत हार्डवेयर नियंत्रण की आवश्यकता होती है। मैं नीति को स्तरों (tier) में विभाजित करूँगा: सामान्य साइन-इन के लिए सिंक किए गए पासकी, और प्रशासकों तथा उच्च-मूल्य वाली क्रियाओं के लिए डिवाइस-बाउंड या अतिरिक्त हार्डवेयर क्रेडेंशियल। सर्वर क्रेडेंशियल ID, पब्लिक की, बैकअप गुण और स्थिति संग्रहीत करता है, लेकिन उन गुणों को पूर्ण प्रमाण के बजाय नीतिगत संकेतों के रूप में मानता है। एकाधिक क्रेडेंशियल, रिवोकेशन और ऑडिटेड रिकवरी आवश्यक हैं।"
चरण-दर-चरण विश्लेषण
चरण 1: दो क्रेडेंशियल प्रकारों को परिभाषित करें
सिंक किए गए पासकी को किसी प्लेटफ़ॉर्म या प्रदाता द्वारा एन्क्रिप्ट किया जा सकता है और उपयोगकर्ता के पंजीकृत डिवाइसों में सिंक्रनाइज़ किया जा सकता है। डिवाइस-बाउंड पासकी प्राइवेट की को एक डिवाइस या हार्डवेयर सुरक्षा कुंजी पर रखते हैं। वास्तविक एश्योरेंस प्लेटफ़ॉर्म, यूजर वेरिफिकेशन और नीति पर निर्भर करता है; केवल लेबल पर्याप्त नहीं है।
चरण 2: खतरे और एश्योरेंस के अनुसार स्तरित करें
उपभोक्ता साइन-इन अक्सर रिकवरी और कई डिवाइसों को महत्व देता है। प्रशासक, वित्तीय अनुमोदन, कुंजी प्रबंधन और उच्च-मूल्य वाले लेनदेन नॉन-कॉपीबिलिटी, डिवाइस प्रबंधन और ऑफबोर्डिंग को प्राथमिकता देते हैं। सामान्य ऑथेंटिकेशन को सिंक किए गए क्रेडेंशियल्स का उपयोग करने दें, जबकि संवेदनशील क्रियाओं के लिए डिवाइस-बाउंड क्रेडेंशियल या स्टेप-अप वेरिफिकेशन की आवश्यकता होनी चाहिए।
चरण 3: सर्वर-साइड फ़ील्ड को समझें
WebAuthn रिकॉर्ड में क्रेडेंशियल ID, पब्लिक की, हस्ताक्षर से संबंधित जानकारी, और बैकअप पात्रता तथा स्थिति गुण शामिल होते हैं। सर्वर नीति और ऑडिट के लिए इनका उपयोग कर सकते हैं, लेकिन बैकअप स्थिति को उपयोगकर्ता के भौतिक उपकरणों की पूर्ण सूची (inventory) के रूप में नहीं मान सकते हैं। मुख्य सत्यापन अभी भी challenge, origin, RP ID, signature और user verification की जांच करता है।
चरण 4: नामांकन और एकाधिक क्रेडेंशियल्स डिज़ाइन करें
एकाधिक क्रेडेंशियल्स की अनुमति दें और निर्माण समय, डिवाइस लेबल और हालिया उपयोग दिखाएं। उच्च-जोखिम वाली भूमिकाओं को एक प्राथमिक और एक नियंत्रित बैकअप क्रेडेंशियल पंजीकृत करना चाहिए। एक नया क्रेडेंशियल पंजीकृत करने के लिए मौजूदा उच्च-एश्योरेंस ऑथेंटिकेशन की आवश्यकता होनी चाहिए ताकि चोरी हुआ सत्र चुपके से किसी हमलावर के डिवाइस को बाइंड न कर सके।
चरण 5: रिकवरी और रिवोकेशन का निर्माण करें
डिवाइस-बाउंड क्रेडेंशियल खोने से पहुंच समाप्त हो सकती है, इसलिए दूसरा क्रेडेंशियल या अधिक मजबूत मैन्युअल रिकवरी आवश्यक है। सिंक किए गए क्रेडेंशियल डिवाइस-स्विच के घर्षण को कम करते हैं लेकिन रिकवरी और सिंक का कुछ भरोसा प्रदाता पर डालते हैं। रिकवरी से नोटिस, कूलिंग अवधि या अनुमोदन उत्पन्न होने चाहिए और पुराने क्रेडेंशियल्स को रद्द (revoke) करने का समर्थन होना चाहिए।
चरण 6: एंटरप्राइज गवर्नेंस को संभालें
संगठनों को यह जानना आवश्यक है कि कौन सी भूमिकाएं किस क्रेडेंशियल प्रकार का उपयोग करती हैं, क्या व्यक्तिगत सिंक खातों की अनुमति है, और ऑफबोर्डिंग पहुंच को कैसे रद्द करती है। डिवाइस प्रबंधन, पहचान-प्रदाता (identity-provider) नीति और WebAuthn RP कॉन्फ़िगरेशन को एक साथ काम करना चाहिए; केवल एक फ्रंटएंड बटन गवर्नेंस नहीं है।
चरण 7: धीरे-धीरे माइग्रेट करें और अनुकूलता बनाए रखें
प्रारंभ में दोनों प्रकारों की अनुमति दें और नामांकन, सफलता, रिकवरी और समर्थन को मापें। उच्च-जोखिम वाली भूमिकाओं के लिए समय सीमा निर्धारित करें और सामान्य उपयोगकर्ताओं का मार्गदर्शन करें। जब तक वास्तविक वातावरण में रिकवरी और विसंगति का पता लगाना (anomaly detection) स्थिर न हो जाए, तब तक पासवर्ड या लीगेसी MFA को न हटाएं।
चरण 8: सुरक्षा और अनुभव के परिणामों को सत्यापित करें
सुरक्षा परिणामों में फ़िशिंग टेकओवर, असामान्य क्रेडेंशियल बाइंडिंग, रिकवरी का दुरुपयोग और रिवोकेशन विलंबता शामिल हैं। अनुभव परिणामों में साइन-इन सफलता, क्रॉस-डिवाइस सफलता, नामांकन पूर्णता, खोए हुए डिवाइस की रिकवरी का समय और समर्थन टिकट शामिल हैं। भूमिका, प्लेटफ़ॉर्म और क्षेत्र के अनुसार खंडित करें।
ट्रेड-ऑफ़, सीमाएं और सूचना लाभ
सिंक किए गए क्रेडेंशियल नुकसान और डिवाइस-स्विच लागत को कम करते हैं लेकिन प्रदाता, खाता रिकवरी और एंटरप्राइज नीति पर निर्भरता बढ़ाते हैं। डिवाइस-बाउंड क्रेडेंशियल नॉन-कॉपीबिलिटी को बढ़ाते हैं लेकिन उनके लिए बैकअप डिवाइस, जारी करने, इन्वेंट्री और रिकवरी संचालन की आवश्यकता होती है। उच्च एश्योरेंस का मतलब यह नहीं है कि हर उपयोगकर्ता को उपयोगिता का त्याग करना चाहिए।
बैकअप पात्रता या स्थिति नीतिगत निर्णयों में मदद करती है लेकिन यह पूरी तरह से सत्यापन योग्य भौतिक तथ्य नहीं है। सिंक का मतलब यह नहीं है कि प्राइवेट की को प्लेनटेक्स्ट में भेजा जाता है; कार्यान्वयन गारंटी को उत्पाद के थ्रेट मॉडल से अलग करें।
मॉडल उच्च-गुणवत्ता वाला उत्तर
"मैं पासकी को जोखिम के आधार पर सिंक किए गए और डिवाइस-बाउंड प्रकारों में विभाजित करूँगा। दोनों WebAuthn पब्लिक-की ऑथेंटिकेशन का उपयोग करते हैं और सामान्य फ़िशिंग का विरोध कर सकते हैं, जबकि सिंक किए गए क्रेडेंशियल सामान्य मल्टी-डिवाइस रिकवरी के लिए उपयुक्त हैं और डिवाइस-बाउंड क्रेडेंशियल प्रशासकों, कुंजी प्रबंधन और उच्च-मूल्य वाली क्रियाओं के लिए उपयुक्त हैं।
सर्वर क्रेडेंशियल ID, पब्लिक की, बैकअप गुण और स्थिति संग्रहीत करता है, और challenge, origin, RP ID और यूजर वेरिफिकेशन को सत्यापित करता है। बैकअप गुण नीति और ऑडिट को सूचित करते हैं लेकिन वे डिवाइस की पूरी इन्वेंट्री नहीं हैं। एकाधिक क्रेडेंशियल्स का समर्थन करें और उच्च-जोखिम वाले उपयोगकर्ताओं के लिए नियंत्रित बैकअप की आवश्यकता रखें। रिकवरी, नामांकन और रिवोकेशन के लिए नोटिस, अनुमोदन या कूलिंग अवधि की आवश्यकता होती है। पहले समानांतर में माइग्रेट करें, फिर प्रवर्तन बढ़ाने के लिए टेकओवर, रिकवरी, साइन-इन और समर्थन मेट्रिक्स का उपयोग करें।"
सामान्य गलतियाँ
- सिंक किए गए पासकी को असुरक्षित कहना। प्रदाता सिंक, रिकवरी और एंटरप्राइज थ्रेट मॉडल पर चर्चा करें।
- यह कहना कि डिवाइस-बाउंड क्रेडेंशियल्स को रिकवरी की आवश्यकता नहीं है। एकमात्र क्रेडेंशियल खोने पर उपयोगकर्ता लॉक आउट हो जाता है।
- एक बैकअप फ़ील्ड को डिवाइस इन्वेंट्री के रूप में मानना। सर्वर प्रत्येक भौतिक प्रतिलिपि का अनुमान नहीं लगा सकता है।
- मौजूदा ऑथेंटिकेशन के बिना नए क्रेडेंशियल्स नामांकित करना। चोरी हुआ सत्र किसी हमलावर के डिवाइस को बाइंड कर सकता है।
- हर भूमिका के लिए एक ही नीति का उपयोग करना। प्रशासकों और सामान्य उपयोगकर्ताओं की एश्योरेंस ज़रूरतें अलग-अलग होती हैं।
- पासवर्ड और लीगेसी MFA को तुरंत हटाना। एक अप्रयुक्त या बिना परीक्षण वाला रिकवरी पथ सामूहिक लॉकआउट का कारण बनता है।
- ऑफबोर्डिंग और व्यक्तिगत सिंक खातों की अनदेखी करना। रिवोकेशन और अनुपालन को लागू करना असंभव हो जाता है।
- केवल साइन-इन सफलता को मापना। रिकवरी, रिवोकेशन और असामान्य बाइंडिंग सुरक्षा परिणाम हैं।
अनुवर्ती प्रश्न और उत्तर
क्या सिंक किए गए पासकी अभी भी फ़िशिंग-प्रतिरोधी हैं?
सही ढंग से कार्यान्वित WebAuthn प्रवाह में, हस्ताक्षर origin और RP ID से बंधे रहते हैं। सिंक पोर्टेबिलिटी और रिकवरी विश्वास को बदलता है; यह ओरिजिन बाइंडिंग को नहीं हटाता है।
आपको डिवाइस-बाउंड पासकी का उपयोग कब करना चाहिए?
जब नीति के अनुसार नॉन-कॉपीबिलिटी की आवश्यकता होती है, एंटरप्राइज हार्डवेयर का प्रबंधन कर सकता है, और यह जारी करने तथा रिकवरी लागत को स्वीकार करता है, जैसे कि सुपर-एडमिन, कुंजी प्रबंधन, या उच्च-मूल्य अनुमोदन के लिए। एक दूसरा क्रेडेंशियल अवश्य रखें।
सर्वर को कैसे पता चलता है कि उपयोगकर्ता ने डिवाइस बदल दिया है?
क्रेडेंशियल रिकॉर्ड, बैकअप गुण और ऑथेंटिकेशन घटनाएं संकेत प्रदान करती हैं, लेकिन डिवाइस की पूरी इन्वेंट्री नहीं। डिवाइस प्रबंधन और पहचान-प्रदाता लॉग अतिरिक्त साक्ष्य जोड़ सकते हैं।
एक खाते में कितने क्रेडेंशियल होने चाहिए?
जोखिम और समर्थन क्षमता के आधार पर एक सीमा निर्धारित करें, साथ ही यह सुनिश्चित करें कि उच्च-जोखिम वाली भूमिकाओं में प्राथमिक और बैकअप क्रेडेंशियल हों। प्रत्येक जोड़ने, हटाने और रिकवरी क्रिया के लिए नोटिस और ऑडिट की आवश्यकता होती है।
क्या साइन-इन के लिए सिंक किए गए क्रेडेंशियल और संवेदनशील क्रियाओं के लिए डिवाइस-बाउंड क्रेडेंशियल का उपयोग किया जा सकता है?
हाँ। यह एक सामान्य टियर्ड (tier) नीति है। संवेदनशील क्रियाओं को उसी सत्र में फिर से उपयुक्त क्रेडेंशियल का अनुरोध करना चाहिए और उनका एक स्पष्ट रिकवरी पथ होना चाहिए।