क्या आपको किसी कंपैनियन ऐप के लिए टू-फैक्टर ऑथेंटिकेशन सक्षम करना चाहिए? सेटअप और रिकवरी संबंधी बातें

सक्षम करने से पहले सुरक्षा सीमा की पुष्टि करें

जाँचें कि यह सुविधा क्या सुरक्षित करती है: प्रत्येक नया डिवाइस, केवल वेब साइन-इन, खरीदारी, निर्यात (एक्सपोर्ट्स), सुरक्षा परिवर्तन, या इनका कोई संयोजन। पता करें कि क्या ऐप खाता स्वतंत्र है या Apple, Google, या किसी अन्य पहचान प्रदाता (आइडेंटिटी प्रोवाइडर) का उपयोग करता है; बाद वाले मामले में, प्रासंगिक टू-फैक्टर नियंत्रण उस प्रदाता के पास हो सकता है। वर्तमान सत्रों (सेशंस) का भी निरीक्षण करें। दूसरा फ़ैक्टर सक्षम करने से भविष्य के लॉगिन सुरक्षित हो सकते हैं, लेकिन पहले से प्रमाणित डिवाइस स्वचालित रूप से निरस्त नहीं होता है। खाता ईमेल, पहचान प्रदाता, सक्रिय डिवाइस और आधिकारिक सहायता पृष्ठ की तारीख लिख लें। ऐप के "2FA का समर्थन करता है" का एक सामान्य दावा अपर्याप्त है यदि आपके द्वारा वास्तव में उपयोग किया जाने वाला साइन-इन मार्ग उस सेटिंग को बायपास करता है।

सेटअप कोड स्कैन करने से पहले रिकवरी को सुरक्षित करें

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

सबसे मजबूत समर्थित विधि चुनें जिसे आप संचालित कर सकते हैं

जब सेवा इसे सही ढंग से लागू करती है, तो एक पासकी (passkey) या हार्डवेयर सुरक्षा कुंजी फ़िशिंग के प्रति अधिक मज़बूत प्रतिरोध प्रदान कर सकती है; जब अधिक मज़बूत विकल्प उपलब्ध न हों तो आम तौर पर ट्रांसफ़रेबल टेक्स्ट कोड की तुलना में एक ऑथेंटिकेटर ऐप बेहतर होता है। CISA मार्गदर्शन स्पष्ट रूप से फ़िशिंग-प्रतिरोधी तरीकों को SMS और वॉइस से अलग करता है। यह प्रत्येक पासकी कार्यान्वयन को एक समान या प्रत्येक कोड को बेकार नहीं बनाता है। उत्पाद के वास्तविक मेनू में से चुनें, डिवाइस संगतता पर विचार करें, और यदि सेवा अनुमति देती है तो दूसरी स्वतंत्र विधि को नामांकित करें। किसी अन्य व्यक्ति द्वारा दिखाए गए QR कोड को स्कैन न करें या किसी अप्रत्याशित लॉगिन संकेत को स्वीकृत न करें। एक वैध दिखने वाला डोमेन भी ऐसे लॉगिन का हिस्सा हो सकता है जिसे आपने शुरू नहीं किया था।

सेटअप पूरा घोषित करने से पहले एक नए सत्र का परीक्षण करें

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

फ़ोन-बदलने और खोने के क्रम की योजना बनाएं

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

फ़ॉलबैक का ऑडिट करें क्योंकि यह वास्तविक आधार तय करता है

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

इस विषय को आगे पढ़ें