डिवाइस-बाउंड बनाम सिंक की गई पासकी (SCA और पासकी I)

अवलोकन: पासकी के साथ मजबूत ग्राहक प्रमाणीकरण (SCA)#

• PSD2 और SCA आवश्यकताओं का विश्लेषण
• पासकी के लिए SCA आवश्यकताओं का क्या अर्थ है
• पासकी के लिए PSD3 / PSR के निहितार्थ

1. परिचय: डिवाइस-बाउंड बनाम सिंक की गई पासकी#

हमारे पिछले पासकी PSD2 ब्लॉग पोस्ट में, हमने चर्चा की थी कि Revolut और Finom जैसे फिनटेक द्वारा पासकी का पहले से ही कैसे उपयोग किया जा रहा है और वे बैंकिंग की डिजिटल सुरक्षा में कैसे सुधार करते हैं।

पासकी दो मुख्य रूपों में आती हैं: सिंक की गई पासकी (synced passkeys) और डिवाइस-बाउंड पासकी (device-bound passkeys)। जहाँ सिंक की गई पासकी उपयोगकर्ताओं को कई डिवाइसों पर निर्बाध रूप से प्रमाणित करने की अनुमति देती हैं, वहीं डिवाइस-बाउंड पासकी सख्ती से एक पासकी डिवाइस जैसे कि हार्डवेयर सुरक्षा कुंजी या स्थानीय ऑथेंटिकेटर से जुड़ी होती हैं।

चार ब्लॉग पोस्ट की इस श्रृंखला के साथ, हम गहराई से विश्लेषण करना चाहते हैं कि विभिन्न प्रकार की पासकी (डिवाइस-बाउंड बनाम सिंक की गई) SCA और PSD2 आवश्यकताओं का कैसे अनुपालन करती हैं।

श्रृंखला का यह पहला भाग डिवाइस-बाउंड और सिंक की गई पासकी के बीच के अंतर को समझने के बारे में है।

दूसरा भाग बताता है कि PSD2 और मजबूत ग्राहक प्रमाणीकरण (Strong Customer Authentication - SCA) का क्या अर्थ है, इसे समझने योग्य तरीके से, इसके ऐतिहासिक विकास को भी प्रस्तुत करता है।

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

श्रृंखला का चौथा और अंतिम भाग यह निष्कर्ष निकालता है कि भविष्य में SCA और पासकी के लिए PSD3 / PSR का क्या अर्थ होगा।

2. मजबूत ग्राहक प्रमाणीकरण, PSD2 और पासकी#

हमारे पिछले ब्लॉग पोस्ट के प्रकाशन के बाद, हमें पासकी पर हमारे रुख, विशेष रूप से PSD2 ढांचे के तहत SCA के संबंध में, बहुत सारे अनुवर्ती प्रश्न प्राप्त हुए। न केवल पासकी के अनुप्रयोग को समझने में, बल्कि यह भी समझने में स्पष्ट रुचि है कि वे नियामक तकनीकी मानकों (RTS) के साथ कैसे संरेखित होते हैं। इसके अतिरिक्त, हितधारक पासकी के उपयोग पर यूरोपीय बैंकिंग प्राधिकरण (EBA) सहित नियामकों से संभावित व्याख्याओं और मार्गदर्शन के बारे में उत्सुक हैं।

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

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

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

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

3. डिवाइस-बाउंड पासकी से सिंक की गई पासकी तक#

डिवाइस-बाउंड और सिंक की गई पासकी के बीच के अंतर को समझने के लिए, हम संक्षेप में यह पता लगाएंगे कि इकोसिस्टम कैसे विकसित हुआ।

3.1 डिवाइस-बाउंड पासकी (सिंगल-डिवाइस पासकी) क्या हैं?#

हम उनके तकनीकी विवरणों पर गहराई से नज़र डालने से पहले डिवाइस-बाउंड पासकी के इतिहास और विकास को देखकर शुरू करते हैं।

3.1.1 डिवाइस-बाउंड पासकी का इतिहास#

ऐतिहासिक रूप से, WebAuthn (पासकी का अंतर्निहित मानक) के भीतर प्रमाणीकरण तंत्र भौतिक उपकरणों से कसकर जुड़े हुए थे: सुरक्षा कुंजियाँ (उदा. YubiKeys)। पासकी को व्यापक रूप से अपनाने से पहले, एकल ऑथेंटिकेटर से बंधे FIDO2 क्रेडेंशियल सुरक्षा में स्वर्ण मानक का प्रतिनिधित्व करते थे। ये क्रेडेंशियल उस डिवाइस से जुड़े होते हैं जिस पर वे रहते हैं। इस बाइंडिंग का निहितार्थ महत्वपूर्ण था: क्रेडेंशियल को इसके मूल हार्डवेयर से परे स्थानांतरित या उपयोग नहीं किया जा सकता था।

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

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

3.1.2 डिवाइस-बाउंड पासकी का तकनीकी विवरण#

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

व्यवहार में डिवाइस-बाउंड क्रेडेंशियल्स का एक उल्लेखनीय उदाहरण Windows इकोसिस्टम के भीतर देखा जाता है। Windows 10 और Windows 11 पर Windows Hello क्रेडेंशियल डिवाइस-बाउंड बने हुए हैं—Windows Hello स्वयं अभी तक डिवाइसों के बीच पासकी सिंक नहीं करता है। हालाँकि, Microsoft ने (Edge 142 के साथ शुरू होकर) Microsoft Edge में पासकी सेविंग और सिंकिंग की शुरुआत करके एक महत्वपूर्ण पहला कदम उठाया है। Microsoft Password Manager के माध्यम से यह ब्राउज़र-स्तरीय सिंक, Edge का उपयोग करते समय पासकी को Windows डिवाइसों में सिंक करने में सक्षम बनाता है, ठीक उसी तरह जैसे Google Password Manager Windows पर Chrome ब्राउज़र में पासकी सिंक को सक्षम बनाता है। यह Windows पासकी क्षमताओं में एक महत्वपूर्ण प्रगति का प्रतिनिधित्व करता है, हालाँकि यह Windows Hello प्लेटफ़ॉर्म ऑथेंटिकेटर के बजाय Edge ब्राउज़र के लिए विशिष्ट है। Windows Hello पासकी डिवाइस-बाउंड बनी हुई हैं, लेकिन यह Edge एकीकरण Windows पर सिंक की गई पासकी की दिशा में एक व्यावहारिक मार्ग प्रदान करता है जबकि प्लेटफ़ॉर्म ऑथेंटिकेटर स्वयं भविष्य में सिंक का समर्थन करने के लिए विकसित हो सकता है।

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

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

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

3.2 सिंक की गई पासकी (मल्टी-डिवाइस पासकी) क्या हैं?#

यहाँ भी, हम तकनीकी विवरणों का विश्लेषण करने से पहले सिंक की गई पासकी के ऐतिहासिक विकास पर एक नज़र डालते हैं। कभी-कभी सिंक की गई पासकी को सिंक करने योग्य पासकी (syncable passkeys) भी कहा जाता है।

3.2.1 सिंक की गई पासकी का इतिहास#

2021 के मध्य से अंत के आसपास WebAuthn लेवल 2 और CTAP 2.1 विनिर्देशों के प्रकाशन के बाद, WebAuthn वर्किंग ग्रुप ने WebAuthn मानक के पासवर्ड को बदलने और अपनाने को बढ़ाने की क्षमता में बाधा डालने वाली प्राथमिक बाधाओं को दूर करने के उद्देश्य से एक महत्वपूर्ण उद्योग पहल शुरू की। यह पहल दो महत्वपूर्ण क्षेत्रों पर केंद्रित थी: अतिरिक्त हार्डवेयर सुरक्षा उपकरणों की आवश्यकता को समाप्त करना और मौजूदा मानकों के साथ पूर्ण बैकवर्ड अनुकूलता बनाए रखते हुए ऑथेंटिकेटर को खोने से जुड़े जोखिम को कम करना।

3.2.1.1 सुरक्षित हार्डवेयर मॉड्यूल के रूप में प्लेटफ़ॉर्म ऑथेंटिकेटर्स का उपयोग#

पहली चुनौती - नए हार्डवेयर की आवश्यकता को समाप्त करना - आधुनिक उपभोक्ता उपकरणों (उदा. Touch ID, Face ID, Windows Hello) में पाए जाने वाले अंतर्निहित प्लेटफ़ॉर्म ऑथेंटिकेटर्स के उपयोग के माध्यम से संबोधित किया गया था।

आधुनिक डिवाइस तेजी से विशेष सुरक्षा मॉड्यूल से लैस हो रहे हैं, जैसे कि Android पर Trusted Execution Environment (TEE), iOS और macOS पर Secure Enclave, और Windows डिवाइसों पर Trusted Platform Module (TPM)। ये अभिन्न सुरक्षा कीस्टोर पासकी के लिए एक मजबूत आधार के रूप में काम करते हैं, प्रभावी रूप से अंतर्निहित "सुरक्षा कुंजियों" के रूप में कार्य करते हैं। यह दृष्टिकोण सार्वजनिक कुंजी क्रिप्टोग्राफी को व्यापक रूप से अपनाने की अनुमति देता है, सुरक्षा का एक स्तर जो पहले केवल बाहरी हार्डवेयर सुरक्षा कुंजियों (उदा. YubiKeys) के माध्यम से प्राप्त किया जा सकता था, और बड़े पैमाने पर तकनीक-प्रेमी व्यक्तियों या अत्यधिक विनियमित उद्योगों के भीतर संगठनों तक ही सीमित था।

TEE, Secure Enclave, या TPM की क्षमताओं का दोहन करके, WebAuthn प्रोटोकॉल मजबूत, क्रिप्टोग्राफ़िक उपयोगकर्ता प्रमाणीकरण तंत्र प्रदान करने के लिए सशक्त होते हैं। अब, परिष्कृत प्रमाणीकरण विधियों को उपयोगकर्ता के अनुकूल और आम जनता के लिए सुलभ बना दिया गया है, अतिरिक्त, विशेष हार्डवेयर की आवश्यकता के बिना।

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

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

3.2.1.2 क्लाउड पर पासकी का सिंक्रोनाइज़ेशन#

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

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

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

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

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

3.2.2 सिंक की गई पासकी का तकनीकी विवरण#

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

जब प्लेटफ़ॉर्म रेजिडेंट कुंजियों का अनुरोध करते हैं, "requireResidentKey" पैरामीटर को required या preferred पर सेट करके, क्लाउड सेवाओं का समर्थन करने वाले प्लेटफ़ॉर्म स्वचालित रूप से सिंक की गई पासकी बनाते हैं। यह प्रक्रिया सुनिश्चित करती है कि उपयोगकर्ता अपने क्रेडेंशियल्स पर भरोसा कर सकते हैं जो उनके विभिन्न डिवाइसों में सुलभ हैं। Windows पर, सिंक की गई पासकी अब Microsoft Edge/Microsoft Password Manager (ब्राउज़र-स्तरीय सिंक) के माध्यम से उपलब्ध हैं, जबकि Windows Hello प्लेटफ़ॉर्म ऑथेंटिकेटर क्रेडेंशियल डिवाइस-बाउंड बने हुए हैं। पासकी प्रबंधन क्षमताओं वाले तृतीय-पक्ष पासवर्ड प्रबंधक (उदा. Dashlane, KeePassXC, 1Password) भी सभी प्लेटफ़ॉर्म पर सिंक प्रदान करते हैं। ऐसे परिदृश्यों में जहाँ सिंक की गई पासकी का उपयोग किया जाता है, isBackupEligible और isBackedUp फ़्लैग 1 पर सेट होते हैं, जो बैकअप पात्रता और सफल सिंक्रोनाइज़ेशन का संकेत देते हैं।

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

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

3.3 व्यापक भलाई के लिए WebAuthn क्रेडेंशियल्स की सिंगल-डिवाइस-बाइंडिंग का त्याग किया गया#

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

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

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

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

3.4 दोनों दुनिया का सर्वश्रेष्ठ: पासकी और supplementalPubKeys एक्सटेंशन [अगस्त 2024 से अप्रचलित]#

आइए विश्लेषण करें कि supplementalPubKeys एक्सटेंशन के साथ समझौता कैसे बना और इसका तकनीकी अर्थ क्या है।

3.4.1 devicePubKey से supplementalPubKeys एक्सटेंशन तक#

devicePubKey एक्सटेंशन से supplementalPubKeys एक्सटेंशन में संक्रमण के आसपास की चर्चा WebAuthn विनिर्देश की गतिशील प्रकृति पर प्रकाश डालती है। प्रारंभ में, devicePubKey ने डिवाइस-बाउंड सार्वजनिक कुंजियों के माध्यम से सुरक्षा बढ़ाने के लिए कार्य किया, लेकिन बाद में इसे WebAuthn Level 3 Editor's Working Draft में supplementalPubKeys के सुझाव द्वारा बदल दिया गया। यह नया एक्सटेंशन प्रमाणीकरण प्रक्रियाओं को बढ़ाने के लिए कई कुंजियों की अनुमति देकर अधिक व्यापक समाधान प्रदान करता है।

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

WebAuthn ड्राफ्ट से सीधे एक उदाहरण:

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

चर्चा के दौरान यह प्रकाश डाला गया कि ये केवल सुरक्षा के लिए अत्यधिक उच्च आवश्यकताओं वाले RPs के लिए थे (उदा. सार्वजनिक क्षेत्र (government) के संदर्भ में)।

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

अधिक समावेशी और लचीले ढांचे की दिशा में यह विकास वेब प्रमाणीकरण विधियों को सख्त उपयोग के मामलों में भी सुधारने के लिए WebAuthn समुदाय की प्रतिबद्धता को रेखांकित करता है।

3.4.2 supplementalPubKeys का तकनीकी विवरण#

WebAuthn में पेश किया गया supplementalPubKeys एक्सटेंशन प्राथमिक क्रेडेंशियल के साथ अतिरिक्त कीपेयर (keypairs) के उपयोग की अनुमति देता है।

मूल GitHub issue से लिया गया

छवि मूल GitHub issue (pk = पासकी, pspk = प्रदाता सप्लीमेंटल कुंजी, dspk = डिवाइस सप्लीमेंटल कुंजी) से ली गई supplementalPubKey की अवधारणा दिखाती है।

यहां बताया गया है कि यह कैसे काम करता है और इसका इच्छित उपयोग क्या है:

supplementalPubKey का उद्देश्य और कार्यक्षमता

• एक केंद्रीय पासकी क्रेडेंशियल रहता है: यह ध्यान रखना महत्वपूर्ण है कि केवल एक केंद्रीय पासकी उपयोगकर्ता प्रमाणीकरण की प्राथमिक विधि बनी हुई है, और अतिरिक्त कुंजियाँ सुरक्षा और आश्वासन की अतिरिक्त परतें प्रदान करती हैं। यह संरचना निर्बाध उपयोगकर्ता अनुभव सुनिश्चित करते हुए कई डिवाइसों में प्रमाणीकरण के लिए एकल, कोर पासकी का उपयोग करने की सादगी और दक्षता बनाए रखती है। इस बीच, सप्लीमेंटल कुंजियाँ प्रमाणीकरण संदर्भ को बढ़ाने का काम करती हैं, जो रिलायिंग पार्टी (RP) को सुरक्षा वातावरण या विशिष्ट प्रमाणीकरण मानकों के अनुपालन के बारे में अतिरिक्त संकेत प्रदान करती हैं। ये सप्लीमेंटल कुंजियाँ स्टैंडअलोन प्रमाणीकरण विधियाँ नहीं हैं, बल्कि प्राथमिक पासकी को बढ़ाती हैं, डिवाइस अखंडता के प्रमाण के साथ इसकी विश्वसनीयता को मजबूत करती हैं।
• डिवाइस-बाउंड कुंजियाँ: ये विशेष रूप से एक डिवाइस से जुड़ी होती हैं। वे आश्वासन प्रदान कर सकते हैं कि प्रमाणीकरण अनुरोध एक विश्वसनीय डिवाइस से आ रहा है जिसे पहले प्रमाणित किया गया है। उन्हें किसी भी परिस्थिति में सिंक नहीं किया जाएगा।
• प्रदाता-बाउंड कुंजियाँ (Provider-Bound Keys): इन कुंजियों का एक "प्रदाता" दायरा होता है, जिसका अर्थ है कि वे प्रमाणीकरण प्रदाता की नीतियों या प्रदाता के विशिष्ट सत्यापन के आधार पर अतिरिक्त आश्वासन प्रदान कर सकते हैं। उदाहरण के लिए, कोई प्रदाता उपयोगकर्ता द्वारा प्रमाणीकरण का उच्च स्तर (जैसे 2FA) पूरा करने के बाद ही ऐसी कुंजी जारी कर सकता है।
• मल्टीपल पब्लिक कुंजियाँ: अपने पूर्ववर्ती, devicePubKey एक्सटेंशन के विपरीत, जो केवल एक डिवाइस-बाउंड सार्वजनिक कुंजी की अनुमति देता था, supplementalPubKeys एक या दो सप्लीमेंटल कुंजी प्रकारों को शामिल करने में सक्षम बनाता है। ये कुंजियाँ विभिन्न उद्देश्यों और दायरों - अर्थात्, डिवाइस-बाउंड और प्रदाता-बाउंड दायरों की सेवा कर सकती हैं।

supplementalPubKey के उपयोग के मामले और उदाहरण

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

supplementalPubKey के तकनीकी पहलू

• कोई अपना क्रेडेंशियल आईडी नहीं: सप्लीमेंटल कुंजियाँ उपयोगकर्ता क्रेडेंशियल नहीं हैं और उनके पास अपनी स्वयं की क्रेडेंशियल आईडी नहीं है।
• सत्यापन विवरण (Attestation Statements): सप्लीमेंटल कुंजियों में वैकल्पिक रूप से एक सत्यापन हो सकता है। सप्लीमेंटल कुंजियों के दायरे और सुरक्षा स्तर को समझने के लिए ये महत्वपूर्ण हैं। एक सत्यापन हार्डवेयर-बाउंड कुंजी द्वारा प्राप्त सुरक्षा के स्तर, या अन्य प्रकार की सप्लीमेंटल कुंजी के लिए नीतियों को इंगित कर सकता है।
• रिलायिंग पार्टीज़ के लिए कार्यान्वयन: रिलायिंग पार्टी प्रमाणीकरण प्रक्रिया के भाग के रूप में इन सप्लीमेंटल कुंजियों का अनुरोध कर सकते हैं। हालाँकि, कई कुंजियों और सत्यापन विवरणों से निपटने की जटिलता का अर्थ है कि यह एक्सटेंशन विशिष्ट सुरक्षा आवश्यकताओं वाली संस्थाओं के लिए सबसे उपयुक्त है, जैसे कि बैंक या सख्त नियामक आवश्यकताओं के तहत काम करने वाली सेवाएँ।

यह ध्यान रखना महत्वपूर्ण है कि, अप्रैल 2024 तक, supplementalPubKeys एक्सटेंशन को किसी भी प्रमुख ब्राउज़र द्वारा अपनाया नहीं गया है, और WebAuthn लेवल 3 विनिर्देश अभी भी विकास के अधीन है और परिवर्तन के अधीन है। क्या इस सुविधा को विनिर्देश के अंतिम संस्करण में शामिल किया जाएगा, और इसके संभावित भविष्य के कार्यान्वयन और अपनाने, अनिश्चित बना हुआ है, क्योंकि वर्तमान में यह केवल संपादक के ड्राफ्ट (Editor's Draft) में है।

3.4.3 अगस्त 2024 में supplementalPubKeys का अप्रचलन (Deprecation)#

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

अप्रचलन के बारे में अधिक जानकारी के लिए, आधिकारिक WebAuthn GitHub pull request देखें।

4. Corbado अभ्यास में डिवाइस-बाउंड बनाम सिंक की गई पासकी के अंतर को कैसे संभालता है#

डिवाइस-बाउंड और सिंक की गई पासकी के बीच के अंतर को समझना आवश्यक है, लेकिन बैंकों को बड़े पैमाने पर इन अंतरों को संचालित करने के लिए टूलिंग की भी आवश्यकता होती है। Corbado का प्लेटफ़ॉर्म डिवाइस ट्रस्ट इंटेलिजेंस (device trust intelligence) प्रदान करता है जो स्वचालित रूप से पासकी प्रकारों को वर्गीकृत करता है और प्रत्येक पर सही SCA उपचार लागू करता है।

पासकी प्रकारों में डिवाइस ट्रस्ट विज़िबिलिटी#

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

डैशबोर्ड डिवाइस वर्गीकरण को भी ट्रैक करता है - यह पहचानता है कि कौन से डिवाइस एकल उपयोगकर्ता के लिए अनन्य हैं (विशिष्ट बैंकिंग तैनाती में 92%), जो दो उपयोगकर्ताओं के बीच साझा किए जाते हैं (7%), और जो साझा/कियोस्क डिवाइस हैं (0.8%)। यह वर्गीकरण सीधे SCA अनुपालन निर्णयों में फ़ीड करता है।

विभिन्न पासकी परिदृश्यों के लिए नीति-आधारित नियंत्रण#

सभी पासकी को समान मानने के बजाय, Corbado की ट्रस्ट नीतियां बैंकों को पासकी प्रकार, डिवाइस स्थिति और ट्रस्ट स्तर के आधार पर अलग-अलग नियम लागू करने देती हैं। ज्ञात उपकरणों पर डिवाइस-बाउंड पासकी को घर्षण रहित (frictionless) प्रमाणीकरण मिलता है, जबकि नए उपकरणों पर सिंक की गई पासकी स्टेप-अप सत्यापन को ट्रिगर करती है - ठीक उसी तरह का सूक्ष्म दृष्टिकोण जिसकी PSD2 का SCA ढांचा मांग करता है।

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

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 विशेषज्ञ से बात करें →

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

डिवाइस-बाउंड पासकी सुरक्षा को कैसे बढ़ाती हैं?#

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

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

मुख्य नुकसान सीमित पोर्टेबिलिटी है। यदि डिवाइस खो जाता है, तो पासकी को तब तक पुनर्प्राप्त नहीं किया जा सकता जब तक कि उपयोगकर्ता किसी अन्य डिवाइस पर एक नया पंजीकृत न करे।

सिंक की गई पासकी क्यों पेश की गईं और उनके क्या लाभ हैं?#

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

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

5. निष्कर्ष#

हमारी 4 भाग की श्रृंखला के पहले भाग में, हमने विश्लेषण किया है कि डिवाइस-बाउंड और सिंक की गई पासकी के ऐतिहासिक और तकनीकी अंतर क्या हैं। इन अंतरों को समझने से हमें PSD2 और SCA की आवश्यकताओं को तदनुसार लागू करने में मदद मिलेगी। साथ ही हमने अभी भी विकसित हो रहे Webauthn लेवल 3 मानक में नवीनतम परिवर्तनों पर नज़र डालकर भविष्य में क्या हो सकता है, इस पर भी नज़र डाली है।

यहाँ हमारी श्रृंखला के अन्य भागों के लिंक दिए गए हैं:

• भाग 2 "PSD2 और SCA आवश्यकताओं का विश्लेषण (SCA और पासकी II)"
• भाग 3 "पासकी के लिए SCA आवश्यकताओं का क्या अर्थ है (SCA और पासकी III)"
• भाग 4 "पासकी के लिए PSD3 / PSR के निहितार्थ (SCA और पासकी IV)"