FIDO2 समझाया गया: वेबऑथन, पासकी और सुरक्षा (HI)

FIDO2 में दो सार्वजनिक-कुंजी प्रमाणीकरण मानक शामिल हैं: वर्ल्ड वाइड वेब कंसोर्टियम का वेब प्रमाणीकरण एपीआई (WebAuthn) और FIDO एलायंस क्लाइंट टू ऑथेंटिकेटर प्रोटोकॉल (CTAP)। साथ में वे रिलाइंग पार्टी को पासवर्ड जैसे पुन: प्रयोज्य साझा रहस्य को संग्रहीत किए बिना एक क्रिप्टोग्राफ़िक क्रेडेंशियल को पंजीकृत करने और उपयोग करने की अनुमति देते हैं।

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

मुख्य बातें

• FIDO2 WebAuthn और CTAP है। WebAuthn एक वेबसाइट या एप्लिकेशन को क्लाइंट से जोड़ता है; CTAP क्लाइंट प्लेटफॉर्म को एक रोमिंग ऑथेंटिकेटर से जोड़ता है।
• निजी कुंजी ऑथेंटिकेटर के पास रहती है। रिलाइंग पार्टी एक सार्वजनिक कुंजी संग्रहीत करती है और नए चुनौतियों और स्कोप्ड संदर्भ पर हस्ताक्षरों को सत्यापित करती है।
• डोमेन बाइंडिंग फ़िशिंग प्रतिरोध पैदा करता है। एक रिलाइंग-पार्टी पहचानकर्ता के लिए पंजीकृत क्रेडेंशियल को हमलावर के असंबंधित डोमेन पर आसानी से दोबारा नहीं चलाया जा सकता है।
• पासकी FIDO क्रेडेंशियल हैं। वे डिवाइस-बाउंड या प्रदाता के डिवाइसों में सिंक्रनाइज़ किए जा सकते हैं, जिससे विभिन्न आश्वासन, रिकवरी और पोर्टेबिलिटी ट्रेड-ऑफ बनते हैं।
• रिकवरी सुरक्षा मॉडल का हिस्सा है। एक मजबूत FIDO2 लॉगिन को बाईपास किया जा सकता है यदि ईमेल, समर्थन, या पहचान-पुनर्प्राप्ति पथ कमजोर साक्ष्य के साथ क्रेडेंशियल को बदल सकते हैं।

FIDO2 क्या है?

FIDO एलायंस स्पेसिफिकेशंस ओवरव्यू FIDO2 को W3C WebAuthn स्पेसिफिकेशन और FIDO क्लाइंट टू ऑथेंटिकेटर प्रोटोकॉल के संयोजन के रूप में परिभाषित करता है। मानक प्रणाली को सहयोगी भूमिकाओं में विभाजित करते हैं:

• रिलाइंग पार्टी: वेबसाइट या सेवा जो क्रेडेंशियल पंजीकृत करती है और प्रमाणीकरण दावों को सत्यापित करती है।
• क्लाइंट: आमतौर पर ब्राउज़र या ऑपरेटिंग-सिस्टम घटक जो WebAuthn को लागू करता है और समारोह की मध्यस्थता करता है।
• ऑथेंटिकेटर: एक प्लेटफॉर्म घटक या बाहरी डिवाइस जो क्रेडेंशियल कुंजी बनाता और उपयोग करता है।
• उपयोगकर्ता: वह व्यक्ति जो पंजीकरण या प्रमाणीकरण के लिए सहमति देता है और PIN, पासवर्ड, या बायोमेट्रिक के साथ स्थानीय रूप से सत्यापित कर सकता है।

W3C WebAuthn लेवल 3 स्पेसिफिकेशन एक रिलाइंग पार्टी के लिए स्कोप्ड सार्वजनिक-कुंजी क्रेडेंशियल बनाने और उपयोग करने के लिए एक वेब एपीआई को परिभाषित करता है। स्क्रिप्ट को कभी भी निजी क्रेडेंशियल कुंजी प्राप्त नहीं होती है। उन्हें ऑथेंटिकेटर और क्लाइंट के माध्यम से उत्पादित संरचित डेटा और क्रिप्टोग्राफिक प्रमाण प्राप्त होते हैं।

FIDO2, WebAuthn, CTAP, U2F, और पासकी की तुलना

अवधि	व्यावहारिक अर्थ	मुख्य सीमा
FIDO2	WebAuthn और CTAP मानकों का एक साथ उपयोग किया जाता है	पूर्ण मानक परिवार, एक एपीआई कॉल नहीं
WebAuthn	सार्वजनिक-कुंजी क्रेडेंशियल के लिए ब्राउज़र या क्लाइंट एपीआई और रिलाइंग-पार्टी डेटा मॉडल	रिलाइंग पार्टी को क्लाइंट से जोड़ता है
CTAP2	क्लाइंट प्लेटफॉर्म और रोमिंग ऑथेंटिकेटर के बीच प्रोटोकॉल	USB, NFC, और BLE जैसे ट्रांसपोर्ट पर बाहरी-ऑथेंटिकेटर संचार वहन करता है
U2F / CTAP1	पहले का FIDO प्रोटोकॉल आमतौर पर द्वितीय-कारक सुरक्षा कुंजियों से जुड़ा होता है	आधुनिक FIDO2 क्षमताओं की तुलना में अधिक सीमित
पासकी	पासवर्ड रहित साइन-इन के लिए डिज़ाइन किया गया एक खोज योग्य FIDO क्रेडेंशियल	सिंक्रनाइज़ या डिवाइस-बाउंड हो सकता है
सुरक्षा कुंजी	USB, NFC, या अन्य समर्थित ट्रांसपोर्ट द्वारा जुड़ा एक रोमिंग हार्डवेयर ऑथेंटिकेटर	एक संभावित ऑथेंटिकेटर फॉर्म
प्लेटफॉर्म ऑथेंटिकेटर	एक डिवाइस या ऑपरेटिंग सिस्टम में निर्मित ऑथेंटिकेटर	अक्सर स्थानीय पिन या बायोमेट्रिक के साथ सक्रिय होता है

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

FIDO2 पंजीकरण कैसे काम करता है

पंजीकरण, जिसे क्रेडेंशियल निर्माण भी कहा जाता है, एक नए सार्वजनिक-कुंजी क्रेडेंशियल को रिलाइंग पार्टी में एक खाते से जोड़ता है।

1. सर्वर पंजीकरण विकल्प बनाता है

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

चुनौतियाँ एकल-उपयोग, अल्पकालिक, सही सत्र और उपयोगकर्ता से बंधी होनी चाहिए, और सर्वर द्वारा संग्रहीत या सत्यापन योग्य होनी चाहिए। केवल ब्राउज़र में उत्पन्न चुनौती सर्वर समारोह की रक्षा नहीं कर सकती है।

2. क्लाइंट WebAuthn को इनवोक करता है

एप्लिकेशन सार्वजनिक-कुंजी विकल्पों के साथ navigator.credentials.create() को कॉल करता है। ब्राउज़र मूल और सुरक्षा संदर्भ की जाँच करता है, फिर एक उपलब्ध ऑथेंटिकेटर को क्रेडेंशियल बनाने के लिए कहता है।

3. ऑथेंटिकेटर उपयोगकर्ता की सहमति प्राप्त करता है

ऑथेंटिकेटर को उपयोगकर्ता की उपस्थिति और, यदि अनुरोध किया गया और समर्थित है, तो उपयोगकर्ता सत्यापन की आवश्यकता होती है। उपयोगकर्ता की उपस्थिति एक स्पर्श या स्पष्ट कार्रवाई हो सकती है। उपयोगकर्ता सत्यापन का अर्थ है कि ऑथेंटिकेटर स्थानीय रूप से उपयोगकर्ता को एक PIN, डिवाइस रहस्य, बायोमेट्रिक, या अन्य समर्थित विधि के माध्यम से सत्यापित करता है।

एक स्थानीय बायोमेट्रिक आमतौर पर क्रेडेंशियल के उपयोग को अनलॉक करता है; बायोमेट्रिक टेम्पलेट को प्रमाणीकरण रहस्य के रूप में वेबसाइट पर नहीं भेजा जाता है।

4. ऑथेंटिकेटर एक कुंजी जोड़ी बनाता है

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

5. सर्वर क्रेडेंशियल को मान्य और संग्रहीत करता है

रिलाइंग पार्टी कुछ भी संग्रहीत करने से पहले समारोह को मान्य करती है। जाँच में शामिल हैं:

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

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

FIDO2 प्रमाणीकरण कैसे काम करता है

प्रमाणीकरण पहले से पंजीकृत क्रेडेंशियल के नियंत्रण को साबित करता है।

1. सर्वर अनुरोध विकल्प बनाता है

रिलाइंग पार्टी एक नई चुनौती उत्पन्न करती है और अभिकथन विकल्प भेजती है। इसमें क्रेडेंशियल पहचानकर्ताओं की एक अनुमति-सूची शामिल हो सकती है या खोज योग्य क्रेडेंशियल का उपयोग कर सकती है ताकि ऑथेंटिकेटर खाते की पहचान कर सके।

2. क्लाइंट एक अभिकथन का अनुरोध करता है

एप्लिकेशन navigator.credentials.get() को कॉल करता है। ब्राउज़र और ऑथेंटिकेटर एक उपयुक्त क्रेडेंशियल का चयन करते हैं और आवश्यक उपयोगकर्ता उपस्थिति या स्थानीय उपयोगकर्ता सत्यापन प्राप्त करते हैं।

3. ऑथेंटिकेटर समारोह डेटा पर हस्ताक्षर करता है

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

4. सर्वर अभिकथन को सत्यापित करता है

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

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

FIDO2 फ़िशिंग-प्रतिरोधी क्यों है

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

NIST SP 800-63B-4 ऑथेंटिकेटर आवश्यकताएँ वेबऑथन को सत्यापनकर्ता-नाम बाइंडिंग के माध्यम से फ़िशिंग-प्रतिरोधी के रूप में वर्णित करती हैं। ऑथेंटिकेटर आउटपुट को प्रमाणित डोमेन नाम से बांधा जाता है, न कि उपयोगकर्ता द्वारा एक भ्रामक पृष्ठ को नोटिस करने पर निर्भर करता है।

फ़िशिंग प्रतिरोध की सीमाएँ हैं:

• यह मैलवेयर या एक हमलावर को नहीं रोकता है जो पहले से ही एक प्रमाणित सत्र को नियंत्रित करता है।
• यह उपयोगकर्ता को वास्तविक सेवा के भीतर एक दुर्भावनापूर्ण लेनदेन को अनुमोदित करने से नहीं रोकता है।
• यह एक खाता-पुनर्प्राप्ति पथ को सुरक्षित नहीं करता है जो क्रेडेंशियल को बदल सकता है।
• यह साबित नहीं करता है कि ऑथेंटिकेटर को नियंत्रित करने वाला व्यक्ति वह वास्तविक दुनिया का व्यक्ति है जिसे एक संगठन नामांकित करना चाहता था।

रीप्ले प्रतिरोध और चुनौती हैंडलिंग

एक रिकॉर्ड किया गया अभिकथन बाद के समारोह में काम नहीं करना चाहिए क्योंकि प्रत्येक अनुरोध एक नई चुनौती का उपयोग करता है। NIST क्रिप्टोग्राफिक ऑथेंटिकेटर का वर्णन करता है जो नॉनसेस या चुनौतियों को रीप्ले-प्रतिरोधी के रूप में शामिल करते हैं।

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

सर्वर को चुनौती को परमाणु रूप से उपभोग के रूप में चिह्नित करना चाहिए। यदि समानांतर अनुरोध दौड़ते हैं, तो केवल एक सफल समारोह उस चुनौती का उपयोग करने में सक्षम होना चाहिए।

उपयोगकर्ता की उपस्थिति और उपयोगकर्ता सत्यापन

WebAuthn अंतर करता है:

• उपयोगकर्ता की उपस्थिति (UP): उपयोगकर्ता ने भागीदारी का संकेत देने वाली एक बातचीत की।
• उपयोगकर्ता सत्यापन (UV): ऑथेंटिकेटर ने स्थानीय रूप से उपयोगकर्ता को एक सक्रियण कारक जैसे PIN या बायोमेट्रिक के माध्यम से सत्यापित किया।

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

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

प्लेटफॉर्म, रोमिंग और क्रॉस-डिवाइस ऑथेंटिकेटर

प्लेटफॉर्म ऑथेंटिकेटर

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

रोमिंग ऑथेंटिकेटर

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

क्रॉस-डिवाइस प्रमाणीकरण

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

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

डिवाइस-बाउंड और सिंक की गई पासकी

एक पासकी एक FIDO क्रेडेंशियल है जिसे पासवर्ड के बिना साइन-इन के लिए डिज़ाइन किया गया है। पासकी हो सकती हैं:

• डिवाइस-बाउंड: क्रेडेंशियल निजी कुंजी एक ऑथेंटिकेटर या प्रबंधित डिवाइस से बंधी रहती है।
• सिंक की गई: क्रेडेंशियल सामग्री को प्रदाता के फैब्रिक के माध्यम से एन्क्रिप्ट और सिंक्रनाइज़ किया जाता है ताकि योग्य डिवाइसों में उपयोग किया जा सके।

सिंक की गई पासकी उपलब्धता और रिकवरी में सुधार करती हैं, जबकि डिवाइस-बाउंड क्रेडेंशियल मजबूत गैर-निर्यात योग्यता प्रदान कर सकते हैं। NIST SP 800-63B-4 सिंक करने योग्य-ऑथेंटिकेटर मार्गदर्शन सिंक करने योग्य ऑथेंटिकेटर को प्रमाणीकरण आश्वासन स्तर 2 तक के संदर्भों में अनुमति देता है जब इसकी आवश्यकताओं को पूरा किया जाता है, लेकिन सिंक्रनाइज़िंग स्तर 3 पर आवश्यक गैर-निर्यात योग्यता के साथ संघर्ष करता है।

“पासकी” शब्द से आश्वासन का अनुमान न लगाएं। मूल्यांकन करें कि क्या क्रेडेंशियल का बैकअप लिया गया है, बैकअप के लिए योग्य हैं, साझा किए गए हैं, प्रबंधित किए गए हैं, डिवाइस-बाउंड हैं, सत्यापित हैं, और रिलाइंग पार्टी की नीति के अनुसार उपयोगकर्ता सत्यापन के साथ सक्रिय किए गए हैं।

सत्यापन और ऑथेंटिकेटर विश्वास

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

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

यदि सत्यापन का उपयोग किया जाता है:

• स्वीकृत प्रारूपों और विश्वास एंकरों को परिभाषित करें;
• प्रमाणपत्र पथों और कथनों को सही ढंग से मान्य करें;
• मेटाडेटा अपडेट और निरसन हैंडलिंग निर्दिष्ट करें;
• कोई विश्वसनीय सत्यापन के साथ ऑथेंटिकेटर के लिए योजना बनाएं;
• गोपनीयता और प्रतिधारण परिणामों का दस्तावेजीकरण करें;
• जब एक स्वीकृत मॉडल स्थिति बदलता है तो प्रतिस्थापन का परीक्षण करें।

FIDO2 पहचान प्रमाणन को प्रतिस्थापित नहीं करता है

FIDO2 एक रिलाइंग पार्टी के लिए पंजीकृत क्रेडेंशियल के नियंत्रण को साबित करता है। यह नामांकित व्यक्ति का कानूनी नाम, आयु, पता, नियामक स्थिति, या वास्तविक दुनिया की विशिष्टता स्थापित नहीं करता है।

यह अंतर तीन सामान्य पैटर्न बनाता है:

1. छद्म नाम नामांकन: सेवा को एक सुरक्षित खाते की आवश्यकता होती है लेकिन एक सत्यापित वास्तविक दुनिया की पहचान की नहीं।
2. पहचान-बाउंड नामांकन: पहले पहचान प्रमाणन होता है, फिर एक FIDO क्रेडेंशियल सत्यापित खाते से बंधा होता है।
3. स्टेप-अप या रिकवरी: सेवा एक खोए हुए ऑथेंटिकेटर को बदलने की अनुमति देने से पहले पहचान को फिर से सत्यापित करती है या अन्य मजबूत साक्ष्य का उपयोग करती है।

बाइंडिंग स्पष्ट होनी चाहिए। रिकॉर्ड करें कि क्रेडेंशियल जोड़े जाने पर कौन सा खाता और प्रमाणन स्थिति मौजूद थी, किस सत्र ने इसे अधिकृत किया, और क्या बाद के जोखिम को पुन: प्रमाणीकरण या पहचान ताज़ा करना चाहिए।

खाता रिकवरी और क्रेडेंशियल जीवनचक्र

रिकवरी वह जगह है जहाँ कई फ़िशिंग-प्रतिरोधी परिनियोजन कमजोर होते हैं। यदि कोई उपयोगकर्ता ईमेल किए गए लिंक या कमजोर समर्थन प्रश्नों का उपयोग करके हर FIDO क्रेडेंशियल को बदल सकता है, तो एक हमलावर इसके बजाय उस पथ को लक्षित करेगा।

एक पूर्ण जीवनचक्र में शामिल हैं:

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

रिकवरी आश्वासन को ऑथेंटिकेटर को बदलने के परिणाम से मेल खाना चाहिए। एक कम-जोखिम वाले समुदाय खाते और एक प्रशासक जो धन को स्थानांतरित कर सकता है, को एक ही पथ की आवश्यकता नहीं होती है।

FIDO2 परिनियोजन का मूल्यांकन कैसे करें

प्रोटोकॉल सत्यापन

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

ऑथेंटिकेटर कवरेज

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

खाता और सत्र सुरक्षा

समीक्षा करें कि कौन एक क्रेडेंशियल जोड़ सकता है, क्या हाल ही में प्रमाणीकरण की आवश्यकता है, सत्र कैसे बढ़ाए जाते हैं, पुन: प्रमाणीकरण कब होता है, और क्रेडेंशियल परिवर्तन मौजूदा सत्रों को कैसे प्रभावित करते हैं।

रिकवरी और समर्थन

लाल-टीम का नुकसान, चोरी हुए डिवाइस, समझौता किया गया ईमेल, सिम परिवर्तन, समर्थन प्रतिरूपण, और दुर्भावनापूर्ण घरेलू या कार्यस्थल पहुंच। हमलावर प्रतिरोध और वास्तविक-उपयोगकर्ता पूर्णता दोनों को मापें।

गोपनीयता और अवलोकन क्षमता

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

सामान्य FIDO2 कार्यान्वयन गलतियाँ

हस्ताक्षर की जाँच करना लेकिन संदर्भ की नहीं

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

हर पासकी को बहु-कारक कहना

सर्वर को सत्यापित करना चाहिए कि क्या उपयोगकर्ता सत्यापन हुआ है और क्या क्रेडेंशियल विशेषताएँ नीति को पूरा करती हैं। केवल उपयोगकर्ता की उपस्थिति स्थानीय उपयोगकर्ता सत्यापन के समान नहीं है।

मौन क्रेडेंशियल जोड़ की अनुमति देना

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

केवल एक क्रेडेंशियल का समर्थन करना

एक-क्रेडेंशियल खाते भंगुर रिकवरी बनाते हैं और कमजोर फॉलबैक को प्रोत्साहित करते हैं। स्पष्ट प्रबंधन और निरसन के साथ कई ऑथेंटिकेटर की अनुमति दें।

पासवर्ड को एक समान फॉलबैक के रूप में छोड़ना

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

सर्वर सत्रों को अनदेखा करना

FIDO2 लॉगिन समारोह को प्रमाणित करता है। कुकीज़ और टोकन को सुरक्षित रखें, प्रमाणीकरण के बाद सत्रों को घुमाएं, संवेदनशील कार्रवाइयों के लिए स्टेप-अप की आवश्यकता होती है, और समझौता किए गए सत्रों को निरस्त करें।

एक परिनियोजन चेकलिस्ट

लॉन्च से पहले, पुष्टि करें कि:

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

FIDO2 के साथ डिडिट कहाँ फिट बैठता है

FIDO2 एक क्रेडेंशियल पंजीकृत होने के बाद प्रमाणीकरण को संभालता है। डिडिट आईडी सत्यापन, जीवंतता पहचान, और बायोमेट्रिक प्रमाणीकरण के माध्यम से आसन्न पहचान निर्णय का समर्थन कर सकता है। प्रकाशित बायोमेट्रिक प्रमाणीकरण मूल्य निर्धारण $0.10 प्रति जांच है।

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

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

FIDO2 का क्या मतलब है?

FIDO का अर्थ है फास्ट आइडेंटिटी ऑनलाइन। FIDO2 W3C WebAuthn को सार्वजनिक-कुंजी प्रमाणीकरण के लिए FIDO एलायंस CTAP के साथ जोड़ने वाला मानक परिवार है।

क्या FIDO2 WebAuthn के समान है?

नहीं। WebAuthn रिलाइंग-पार्टी और क्लाइंट एपीआई और डेटा मॉडल को परिभाषित करता है। FIDO2 में WebAuthn और CTAP शामिल हैं, जो क्लाइंट प्लेटफॉर्म को रोमिंग ऑथेंटिकेटर से जोड़ता है।

क्या पासकी FIDO2 क्रेडेंशियल हैं?

हाँ। पासकी पासवर्ड रहित साइन-इन के लिए डिज़ाइन किए गए खोज योग्य FIDO क्रेडेंशियल हैं। उन्हें योग्य डिवाइसों में सिंक्रनाइज़ किया जा सकता है या डिवाइस-बाउंड रह सकता है।

क्या FIDO2 फ़िशिंग-प्रतिरोधी है?

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

क्या FIDO2 बायोमेट्रिक्स का उपयोग करता है?

यह एक ऑथेंटिकेटर को सक्रिय करने और उपयोगकर्ता सत्यापन सेट करने के लिए एक स्थानीय बायोमेट्रिक का उपयोग कर सकता है। रिलाइंग पार्टी को आमतौर पर परिणाम और क्रिप्टोग्राफिक अभिकथन प्राप्त होता है, न कि बायोमेट्रिक टेम्पलेट।

क्या FIDO2 किसी व्यक्ति की पहचान सत्यापित करता है?

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

जब कोई उपयोगकर्ता हर ऑथेंटिकेटर खो देता है तो क्या होता है?

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

प्राथमिक संदर्भ

• FIDO एलायंस उपयोगकर्ता प्रमाणीकरण विनिर्देश
• W3C वेब प्रमाणीकरण स्तर 3 उम्मीदवार सिफारिश स्नैपशॉट
• FIDO एलायंस CTAP 2.3 प्रस्तावित मानक
• NIST SP 800-63B-4: प्रमाणीकरण और प्रमाणीकरण प्रबंधन
• NIST SP 800-63B-4 प्रमाणीकरण आवश्यकताएँ

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