2026 में पासकी और मल्टीएकाउंटिंग: कैसे न करें अकाउंट्स को एक्सेस कीज़ से जोड़ना

1 सितंबर 2026 से, Microsoft ने Entra ID में डिफ़ॉल्ट लॉगिन के तरीके के रूप में पासकीज़ को शामिल करना शुरू किया, और 1 फरवरी 2027 से, SMS और वॉयस कोड की अपनी डिलीवरी को बंद कर देगा। Google ने अक्टूबर 2023 में व्यक्तिगत खातों के लिए लॉगिन का मुख्य विकल्प पासकीज़ को बना दिया। एक व्यक्ति के लिए एक खाते के साथ यह सुविधाजनक है। उन लोगों के लिए जो एंटी-डिटेक्ट में दर्जनों खातों का प्रबंधन करते हैं, पासकी आसानी से एक अदृश्य धागा बन जाती है जो अलग-अलग प्रोफाइल को जोड़ती है। नीचे हम समझते हैं कि यह कैसे होता है और एक योजना कैसे बनाई जाए जिसमें कुंजी खातों के बीच "लीक" न हो।

क्यों यह सवाल अभी उठा

पासकीज़ 2022 से मौजूद हैं, लेकिन 2026 में "इन्हें सक्षम किया जा सकता है" से "आपसे अनुरोध किया जाएगा" में बदल गए। तीन विशेष कारण:

• Microsoft Entra ID। सितंबर 2026 से, उन उपयोगकर्ताओं के लिए जो SMS या कॉल द्वारा लॉगिन की पुष्टि करते हैं, स्वचालित रूप से पासकीज़ सक्षम हो जाती हैं: अगले MFA सत्यापन पर कुंजी पंजीकरण का प्रस्ताव आएगा। 31 जनवरी 2027 तक इसे टाला जा सकता है, 1 फरवरी 2027 से इसे छोड़ना संभव नहीं होगा। Microsoft इसका समर्थन करने के लिए अपने आंकड़े प्रस्तुत करता है: AI के साथ फ़िशिंग अभियान 54% क्लिक प्राप्त करते हैं जबकि सामान्य अभियानों के लिए यह 12% है।
• Google। अक्टूबर 2023 से व्यक्तिगत खातों में डिफ़ॉल्ट रूप से "जहां संभव हो पासवर्ड दर्ज करने से बचें" विकल्प सक्षम है। यदि कुंजी बनाई गई है, तो Google इसका उपयोग करके लॉगिन करने का प्रस्ताव देता है।
• प्रबंधकों के बीच कुंजी का स्थानांतरण। FIDO Alliance ने Credential Exchange मानक (CXF और CXP प्रारूप) प्रकाशित किया। iOS 26 और macOS 26 में, Apple Passwords, 1Password, Bitwarden, Dashlane और अन्य ऐप्स के बीच पासकीज़ को एन्क्रिप्टेड रूप में स्थानांतरित किया जा सकता है, बिना फ़ाइल को निर्यात किए। कुंजी अब एक ही स्टोरेज से स्थायी रूप से बंधी नहीं है। मल्टी-खाता प्रबंधन के लिए यह एक अवसर और एक जोखिम दोनों है।

पासकी कैसे काम करती है और यह प्रोफाइल की अलगाव को क्यों तोड़ती है

पासकी एक क्रिप्टोग्राफिक कुंजी की जोड़ी है। सार्वजनिक कुंजी साइट पर संग्रहीत होती है, जबकि निजी कुंजी "प्रमाणीकर्ता" पर होती है। कुंजी डोमेन से जुड़ी होती है (विशिष्टता में इसे rpId कहा जाता है), इसलिए फ़िशिंग साइट इसे प्राप्त नहीं कर पाएगी। मल्टी-खाता प्रबंधन के लिए मुख्य प्रश्न है निजी कुंजी भौतिक रूप से कहाँ स्थित है। एंटी-डिटेक्ट कुकीज़, localStorage, IndexedDB और फ़िंगरप्रिंट को अलग करता है। कुंजी का भंडारण अक्सर ब्राउज़र प्रोफाइल के बाहर होता है:

• Windows Hello कुंजी को Windows खाते के स्तर पर संग्रहीत करता है। किसी भी ब्राउज़र और इस खाते के तहत किसी भी प्रोफाइल को एक ही भंडारण का उपयोग करना होता है।
• macOS पर iCloud कुंजी का बंडल Apple ID से संबंधित है। एक ही मैक पर Chrome और Safari एक ही कुंजी सेट को देखते हैं।
• Google पासवर्ड प्रबंधक Google खाते से जुड़ा होता है, जिसमें ब्राउज़र या फोन लॉगिन होता है। एक कार्यात्मक Google खाता बीस प्रोफाइल पर एक सामान्य सुरक्षित स्थान होता है।
• एक्सटेंशन-प्रबंधक (Bitwarden, 1Password और अन्य) अपने खाते के भंडारण में कुंजी को संग्रहीत करते हैं। सभी प्रोफाइल के लिए एक भंडारण एकल बिंदु के रूप में कार्य करता है, जिसके माध्यम से सब कुछ देखा जा सकता है।

यहां से एक सामान्य विफलता होती है। आप खाते नंबर 7 के प्रोफाइल में "पासकी के साथ लॉगिन करें" पर क्लिक करते हैं, और सिस्टम खाते नंबर 3 और 12 की कुंजी को उसी साइट पर दिखाता है। साइट इस सूची को नहीं देखती: यह केवल चयनित कुंजी प्राप्त करती है। लेकिन एक गलत क्लिक — और खाता नंबर 3 खाते नंबर 7 के प्रोफाइल, IP और फ़िंगरप्रिंट से लॉगिन हो जाता है। इस प्रकार का संबंध अब रद्द नहीं किया जा सकता।

साइट वास्तव में पासकी के साथ लॉगिन करते समय क्या जानती है

पासकी जोखिम-स्कोरिंग को समाप्त नहीं करती है, यह केवल पासवर्ड को बदलती है। लॉगिन करते समय, साइट अभी भी IP, ब्राउज़र फ़िंगरप्रिंट और सत्रों का इतिहास देखती है। इसके अलावा, यह WebAuthn के कुछ अपने संकेत प्राप्त करती है:

• कुंजी पहचानकर्ता (credential ID)। यह "खाता — प्रमाणीकर्ता" जोड़ी के लिए अद्वितीय है।
• AAGUID — प्रमाणीकर्ता के मॉडल की पहचान। इसके आधार पर, साइटें जैसे Google खाते की सेटिंग्स में कुंजी पर हस्ताक्षर करती हैं: "iCloud Keychain में बनाई गई", "Google पासवर्ड प्रबंधक में" आदि। यह आपके डिवाइस का अद्वितीय नंबर नहीं है, लेकिन यह एक और विशेषता है जो प्रोफाइल की कथा के साथ मेल खानी चाहिए।
• BE और BS फ्लैग्स (backup eligibility और backup state) दिखाते हैं कि क्या यह कुंजी सिंक्रनाइज़ की गई है या डिवाइस से जुड़ी हुई है।

निष्कर्ष: "मोबाइल" प्रोफाइल, जो Windows Hello से कुंजी के साथ लॉगिन करता है, उतना ही असंगत लगता है जैसे ब्राजील के समय क्षेत्र और जर्मनी से IP के साथ iPhone। कुंजी को उसी कथा के साथ मेल खाना चाहिए जो प्रॉक्सी और फ़िंगरप्रिंट के साथ है।

चरण-दर-चरण योजना: एक खाता — एक प्रोफाइल — एक भंडारण — एक IP

1. इन्वेंट्री करें। उन साइटों की सूची बनाएं जहां आपके खातों के पास पहले से पासकीज़ हैं या उन्हें बनाने का प्रस्ताव आया है: Google, Microsoft, बड़े मार्केटप्लेस और सोशल नेटवर्क। प्रत्येक खाते की सुरक्षा सेटिंग्स में यह देखा जा सकता है कि कितनी कुंजी पंजीकृत हैं और वे कहाँ बनाई गई हैं। सभी अप्रत्याशित प्रविष्टियाँ "Windows Hello" और "iCloud Keychain" हटाने के लिए उम्मीदवार हैं।
2. कार्यात्मक प्रोफाइल के लिए सिस्टम कुंजी भंडारण बंद करें। उस ब्राउज़र में, जहां प्रोफाइल काम कर रहे हैं, अंतर्निहित प्रबंधक में पासवर्ड और पासकीज़ को सहेजने को बंद करें। कार्य मशीन पर Windows Hello या iCloud बंडल में कुंजी न बनाएं। यदि कुंजी बनाने की विंडो "इस कंप्यूटर" का सुझाव देती है, तो एक और तरीका चुनें।
3. प्रत्येक खाते के लिए भंडारण चुनें। नियम सरल है: भंडारण को उसी तरह विभाजित किया जाना चाहिए जैसे प्रोफाइल। विकल्प:
   • एक खाता या एक ग्राहक के एक समूह के लिए पासवर्ड प्रबंधक का अलग भंडारण;
   • कुछ सबसे मूल्यवान खातों के लिए हार्डवेयर कुंजी (FIDO2);
   • स्वचालन के लिए — सॉफ़्टवेयर प्रमाणीकर्ता, इसके बारे में चरण 6 में।
   सभी के लिए एक भंडारण सबसे सामान्य तरीका है जिससे आप खातों को आपस में जोड़ सकते हैं।
4. केवल "मूल" प्रोफाइल से कुंजी पंजीकृत करें। वही प्रोफाइल, वही फ़िंगरप्रिंट, वही प्रॉक्सी के साथ स्थायी सत्र, वही भूगोल, जो सामान्य खाते के काम के दौरान होता है। कुंजी का पंजीकरण एक संवेदनशील क्रिया है, और साइटें इसे ध्यान से देखती हैं। प्रक्रिया के बीच में IP बदलने से अक्सर अतिरिक्त सत्यापन होता है। एक प्रोफाइल के लिए एक पता कैसे बनाए रखें, इस पर हमने लेख में विस्तार से चर्चा की है स्टिकी सत्र या प्रोफाइल एंटी-डिटेक्ट के लिए रोटेशन.
5. एक बैकअप लॉगिन छोड़ें। खोया हुआ भंडारण खोए हुए खाते का अर्थ है। प्रत्येक खाते के लिए एक दूसरा लॉगिन तरीका होना चाहिए: दूसरे भंडारण में दूसरी पासकी, TOTP के साथ पासवर्ड या पुनर्प्राप्ति कोड जो कुंजी से अलग रखे जाते हैं। Microsoft Entra में सीधे उपयोगकर्ताओं को फरवरी 2027 तक फ़िशिंग-प्रतिरोधी तरीकों पर स्थानांतरित करने की मांग करता है। इंतजार न करें जब तक पंजीकरण की विंडो बंद नहीं होती।
6. स्वचालन में वर्चुअल प्रमाणीकर्ता का उपयोग करें। Chrome DevTools Protocol में WebAuthn डोमेन है। विधि addVirtualAuthenticator ctap2 प्रोटोकॉल और internal (प्लेटफ़ॉर्म) या usb/hybrid परिवहन के साथ एक सॉफ़्टवेयर प्रमाणीकर्ता बनाती है। पैरामीटर hasResidentKey और hasUserVerification कुंजी को प्रमाणीकर्ता पर संग्रहीत करने और उपयोगकर्ता की जांच को सक्षम करते हैं। getCredentials पंजीकरण के बाद कुंजी को पूरी तरह से लौटाता है: credentialId, rpId, userHandle, signCount और PKCS#8 प्रारूप में निजी कुंजी। addCredential अगली बार इसे वापस रखता है। यह एक कुंजी बनाता है जो केवल आपके सीक्रेट स्टोरेज में रहती है और एक विशेष खाते के सत्र से जुड़ती है। दो चेतावनियाँ: डोमेन को प्रयोगात्मक के रूप में चिह्नित किया गया है और WebAuthn का परीक्षण करने के लिए बनाया गया है, और निर्यात की गई निजी कुंजी पासवर्ड स्तर का एक रहस्य है, और इसे उसी तरह संग्रहीत किया जाना चाहिए।
7. कुंजी को Credential Exchange के माध्यम से स्थानांतरित करें, न कि मैन्युअल रूप से। यदि आप प्रबंधक को बदलते हैं या खातों को विभिन्न भंडारण में वितरित करते हैं, तो FIDO मानक के अनुसार अंतर्निहित निर्यात का उपयोग करें: इसे Apple Passwords, 1Password, Bitwarden, Dashlane, DuckDuckGo, Devolutions में समर्थन किया गया है। ध्यान दें कि macOS पर कुछ ऐप्स ने इस तंत्र को अभी तक लागू नहीं किया है।

छिपे हुए खतरे

• डिफ़ॉल्ट रूप से समन्वय। "इस डिवाइस पर" बनाई गई कुंजी तुरंत iCloud या Google क्लाउड में जा सकती है और इस खाते के सभी उपकरणों पर दिखाई दे सकती है, जिसमें आपका व्यक्तिगत फोन भी शामिल है।
• QR के माध्यम से क्रॉस-डिवाइस लॉगिन। "QR को फोन से स्कैन करें" परिदृश्य (हाइब्रिड परिवहन) प्रोफाइल के सत्र से वास्तविक फोन को जोड़ता है जिसमें अपनी कुंजी होती है। कार्यात्मक प्रोफाइल के लिए यह अतिरिक्त संबंध है।
• पूरी फार्म में समान AAGUID होना सामान्य है। लाखों लोग एक ही प्रबंधक का उपयोग करते हैं। समान प्रदाता खतरनाक नहीं है, बल्कि सामान्य कुंजी या सामान्य भंडारण है।
• पासकी "गंदे" लॉगिन का इलाज नहीं करती। यदि खाता उस IP से लॉगिन करता है जो पहले से ही पड़ोसी खातों पर उजागर हो चुका है, या उस डेटा सेंटर से जो साइट को पसंद नहीं है, तो मजबूत क्रिप्टोग्राफी मदद नहीं करेगी। जोखिम संकेतों के संयोजन के आधार पर आंका जाता है।
• दूसरे कारक को भी अलग करना आवश्यक है। यदि बैकअप लॉगिन TOTP है, तो रहस्य भी खातों में वितरित होते हैं, न कि व्यक्तिगत फोन पर एक ही ऐप में। 2FA और प्रॉक्सी को कैसे जोड़ें, इस पर हमने सामग्री में चर्चा की है प्रॉक्सी के माध्यम से दो-कारक प्रमाणीकरण पर.

किस प्रॉक्सी की आवश्यकता है और क्यों

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

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

निष्कर्ष

पासकीज़ फ़िशिंग के प्रति लॉगिन को सुरक्षित बनाती हैं, लेकिन खातों के बीच संबंध के बिंदु को कुकीज़ और पासवर्ड से कुंजी भंडारण में स्थानांतरित करती हैं। यह बिंदु अक्सर एंटी-डिटेक्ट प्रोफाइल के बाहर होती है: Windows Hello, iCloud, Google खाते या प्रबंधक के सामान्य भंडारण में। कार्यात्मक योजना इस प्रकार है: प्रत्येक खाते के लिए अपना प्रोफाइल, अपनी कुंजी का भंडारण, अपना स्थायी IP और बैकअप लॉगिन का तरीका होना चाहिए। स्वचालन के लिए CDP में एक वर्चुअल प्रमाणीकर्ता है। इस पर फरवरी 2027 से पहले ध्यान दें, जब Microsoft पंजीकरण को टालने की अनुमति देना बंद कर देगा। फिर आपको जल्दी में और वास्तविक खातों पर समस्या का समाधान करना होगा।