सामान्य साक्षात्कार: आप फ़िशिंग-प्रतिरोधी पासकी लॉगिन और रिकवरी फ़्लो कैसे डिज़ाइन करेंगे?

प्रॉम्प्ट और उपयुक्त संदर्भ

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

दायरा WebAuthn और सर्वर-सत्यापन सीमा है। पासकी स्वचालित रूप से सेशन प्रबंधन, अकाउंट रिकवरी, डिवाइस निरस्तीकरण या व्यावसायिक प्राधिकरण को हल नहीं करती हैं।

साक्षात्कारकर्ता क्या मूल्यांकन करता है

साक्षात्कारकर्ता जाँचता है कि क्या आप समझते हैं कि ब्राउज़र और ऑथेंटिकेटर प्राइवेट की रखते हैं जबकि सर्वर पब्लिक की संग्रहीत करता है; प्रत्येक सेरेमनी एकमुश्त रैंडम चैलेंज का उपयोग करती है; और सत्यापनकर्ता चैलेंज, RP ID, ओरिजिन, हस्ताक्षर और आवश्यक यूज़र-प्रेजेंस या यूज़र-वेरिफ़िकेशन फ़्लैग की जाँच करता है।

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

पहले पूछे जाने वाले स्पष्टीकरण

• किन कार्यों के लिए केवल साइन-इन की आवश्यकता होती है, और किसके लिए UV या डिवाइस-बाउंड क्रेडेंशियल की आवश्यकता होती है?
• क्या RP ID कई सबडोमेन को कवर करता है, और क्या WebAuthn क्रॉस-ओरिजिन iframe में चलेगा?
• क्या एंटरप्राइज सिंक करने योग्य क्रेडेंशियल्स को प्रतिबंधित कर सकता है या हार्डवेयर कुंजियों की आवश्यकता रख सकता है?
• रिकवरी के लिए कौन से मौजूदा फ़ैक्टर बने रहेंगे, और क्या कोई ऑपरेटर इसकी समीक्षा कर सकता है?
• पासवर्ड, TOTP और पासकी के लिए माइग्रेशन और निरस्तीकरण समयरेखा क्या है?

30-सेकंड का उत्तर ढाँचा

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

चरण-दर-चरण गहन उत्तर

चरण 1: रजिस्ट्रेशन और ऑथेंटिकेशन डेटा परिभाषित करें

रजिस्ट्रेशन से पहले, सर्वर एक अप्रत्याशित, अल्पकालिक, एकल-उपयोग चैलेंज बनाता है और इसे एक सेशन या वन-टाइम स्टोर में संग्रहीत करता है। क्लाइंट navigator.credentials.create() को कॉल करता है; ऑथेंटिकेटर एक की-पेयर बनाता है और एक पब्लिक-की क्रेडेंशियल लौटाता है।

क्रेडेंशियल ID, पब्लिक की, अकाउंट, RP ID, सिग्नेचर काउंटर, बैकअप पात्रता और बैकअप स्थिति को आवश्यकतानुसार संग्रहीत करें। प्राइवेट की ऑथेंटिकेटर या प्लेटफ़ॉर्म क्रेडेंशियल मैनेजर में रहती है।

चरण 2: सख्त ऑथेंटिकेशन जाँच करें

साइन-इन के लिए, सर्वर एक नया चैलेंज और publicKeyCredentialRequestOptions बनाता है; क्लाइंट navigator.credentials.get() को कॉल करता है। सत्यापित करें:

const valid = await verifyAuthenticationResponse({
  response,
  expectedChallenge: session.challenge,
  expectedOrigin: "https://app.example.com",
  expectedRPID: "app.example.com",
  requireUserVerification: true
});

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

चरण 3: RP IDs, ओरिजिन और क्रॉस-ओरिजिन जोखिम को समझें

RP ID क्रेडेंशियल के लिए रिलाइंग पार्टी की पहचान करता है; कोई क्रेडेंशियल किसी भिन्न RP ID पर प्रमाणित नहीं हो सकता है। सर्वर को केवल एक रजिस्ट्रेबल डोमेन की तुलना करने के बजाय कॉलिंग ओरिजिन की भी जाँच करनी चाहिए। क्रॉस-ओरिजिन iframe या Related Origin Request को इस बात की स्पष्ट समीक्षा की आवश्यकता होती है कि क्या यूज़र जानता है कि सेरेमनी का अनुरोध कौन कर रहा है और एक अलग अनुकूलता परीक्षण की आवश्यकता होती है।

कंपनी का लोगो ओरिजिन का प्रमाण नहीं है। ओरिजिन, RP ID, चैलेंज और हस्ताक्षर को ब्राउज़र/ऑथेंटिकेटर संदर्भ और सर्वर पर एक साथ सत्यापित किया जाना चाहिए।

चरण 4: जोखिम के अनुसार UP, UV और सिंक स्थिति का विश्लेषण करें

UP का अर्थ है कि यूज़र ने ऑथेंटिकेटर के साथ इंटरैक्ट किया; UV का अर्थ है कि ऑथेंटिकेटर ने यूज़र को स्थानीय रूप से सत्यापित किया। साधारण साइन-इन जोखिम के आधार पर एक नीति चुन सकता है, जबकि ट्रांसफ़र, कुंजी निर्यात और व्यवस्थापक कार्यों के लिए UV की आवश्यकता होनी चाहिए और सर्वर को लौटाए गए फ़्लैग का निरीक्षण करना चाहिए।

सिंक करने योग्य क्रेडेंशियल क्रॉस-डिवाइस उपलब्धता में सुधार करते हैं, लेकिन NIST नोट करता है कि सिंक करने में कुंजी निर्यातनीयता शामिल है। क्या वह किसी आश्वासन स्तर को पूरा करता है, यह परिनियोजन नीति पर निर्भर करता है। बैकअप पात्रता और स्थिति रिकॉर्ड करें; "सिंक करने योग्य" को "पहले से सिंक किया गया" या "डिवाइस-बाउंड" न कहें।

चरण 5: रिकवरी, माइग्रेशन और निरस्तीकरण डिज़ाइन करें

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

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

उच्च-गुणवत्ता वाला नमूना उत्तर

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

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

सामान्य गलतियाँ

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

फ़ॉलो-अप प्रश्न और उत्तर

फ़ॉलो-अप 1: पासकी फ़िशिंग-प्रतिरोधी क्यों हैं?

ऑथेंटिकेटर ओरिजिन और RP ID के आधार पर क्रेडेंशियल्स का चयन करता है और अपने संदर्भ के साथ सर्वर चैलेंज पर हस्ताक्षर करता है। एक फ़िशिंग साइट ऑथेंटिकेटर से वास्तविक सेवा के लिए वैध प्रमाण प्राप्त नहीं कर सकती है। सर्वर को फिर भी ओरिजिन, RP ID और चैलेंज को सत्यापित करना होगा।

फ़ॉलो-अप 2: चैलेंज को केवल क्लाइंट पर ही क्यों न रखें?

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

फ़ॉलो-अप 3: क्या सिंक करने योग्य क्रेडेंशियल स्वाभाविक रूप से असुरक्षित हैं?

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

फ़ॉलो-अप 4: क्या होगा यदि यूज़र सभी डिवाइस खो देता है?

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