पूरे ऑथेंटिकेशन पाथ का ऑडिट करें, केवल एक लॉगिन स्क्रीन का नहीं
एक मजबूत दिखने वाली लॉगिन स्क्रीन पूरे ऑथेंटिकेशन मैकेनिज्म को बयां नहीं करती है। अकाउंट एक्सेस इस बात पर भी निर्भर करता है कि कोई फ़ैक्टर कैसे एनरोल किया गया है, सर्विस नियमित लॉगिन को कैसे सत्यापित करती है, संवेदनशील बदलाव से पहले यह दोबारा कब पूछती है, सेशन्स कितने समय तक जारी रहते हैं, रिकवरी कैसे काम करती है, और खोए हुए फ़ैक्टर को कैसे बदला जाता है। सात कॉलमों के साथ एक ऑथेंटिकेशन-पाथ मैप बनाएं: नामांकन, नियमित लॉगिन, अतिरिक्त सत्यापन, संवेदनशील-कार्रवाई पुनर्जांच, सेशन नियंत्रण, रिकवरी, और रिटायरमेंट या प्रतिस्थापन। प्रत्येक कॉलम के लिए ऑथेंटिकेटर, इसे कौन सत्यापित करता है, कौन सा चैनल प्रॉम्प्ट ले जाता है, उपयोगकर्ता क्या देखता है, क्या फ़ॉलबैक मौजूद है, और कौन सा देखने योग्य परिणाम पूरा होने की पुष्टि करता है, इसे रिकॉर्ड करें। यह अकाउंट ऑथेंटिकेशन को स्थानीय फ़ोन अनलॉक से अलग करता है और यह उजागर करता है कि कब कोई सुविधाजनक तरीका चुपचाप किसी कमजोर पाथ पर फ़ॉलबैक कर जाता है।
प्रत्येक भूमिका, फ़ैक्टर और प्रवेश बिंदु का नाम दर्ज करें
अकाउंट आइडेंटिफ़ायर, क्रेडेंशियल सर्विस या आइडेंटिटी प्रोवाइडर, वेरिफ़ायर, कंपैनियन ऐप, पंजीकृत ऑथेंटिकेटर्स, रिकवरी कॉन्टैक्ट्स, विश्वसनीय डिवाइसेस और सक्रिय सेशन्स से शुरुआत करें। NIST का डिजिटल आइडेंटिटी मॉडल प्रूफिंग, ऑथेंटिकेटर्स, वेरिफ़ायर्स, फ़ेडरेशन और सेशन्स को संबंधित लेकिन अलग-अलग कार्यों के रूप में मानता है। पासवर्ड एक ज्ञात चीज़ (something known) है; एक पंजीकृत डिवाइस या क्रिप्टोग्राफ़िक कुंजी एक धारित चीज़ (something held) है; एक फ़िंगरप्रिंट डिवाइस पर ऑथेंटिकेटर को सक्रिय कर सकता है, बिना खुद एक रिमोट अकाउंट क्रेडेंशियल बने। इसके आइकन से सुरक्षा लेबल तय करने के बजाय यह रिकॉर्ड करें कि वर्तमान उत्पाद वास्तव में क्या प्रदान करता है। इसमें वेब लॉगिन, मोबाइल ऐप, थर्ड-पार्टी साइन-इन, पासवर्ड रीसेट, डिवाइस अनुमोदन और सहायता-प्राप्त (सपोर्ट-असिस्टेड) रिकवरी शामिल करें। अज्ञात पाथ तब तक अज्ञात रहते हैं जब तक कि वर्तमान आधिकारिक दस्तावेज़ या कोई नियंत्रित परीक्षण उनका समाधान नहीं कर देता।
नियमित लॉगिन की तुलना संवेदनशील-कार्रवाई जांच से करें
उन कार्रवाइयों की सूची बनाएं जो अकाउंट नियंत्रण को बदलती हैं: ऑथेंटिकेटर जोड़ना या हटाना, रिकवरी ईमेल बदलना, डेटा निर्यात करना, अतिरिक्त सत्यापन अक्षम करना, बाहरी पहचान को लिंक करना, रिकवरी कोड देखना, अकाउंट हटाना या सभी सेशन्स से साइन आउट करना। जांचें कि क्या ऐप प्रत्येक समर्थित कार्रवाई से पहले नए ऑथेंटिकेशन का अनुरोध करता है और यह किस फ़ैक्टर को स्वीकार करता है। OWASP का ऑथेंटिकेशन मार्गदर्शन संवेदनशील बदलावों, रिकवरी और सेशन हैंडलिंग के लिए पुनः-ऑथेंटिकेशन (reauthentication) को अलग नियंत्रण मानता है। पाँच मिनट पहले ही अनलॉक किया गया फ़ोन इस बात का प्रमाण नहीं है कि अकाउंट-नियंत्रण परिवर्तन को नए सिरे से सत्यापित किया गया था। हानिरहित सेटिंग्स और अपने स्वयं के अकाउंट का उपयोग करें; बार-बार रिकवरी या लॉकआउट ट्रिगर न करें। सटीक प्रॉम्प्ट, गंतव्य, उपयोग किया गया फ़ैक्टर, कैंसलेशन व्यवहार और क्या अन्य सेशन्स में कोई दृश्यमान बदलाव हुआ, इसे रिकॉर्ड करें।
ऑथेंटिकेटर के गुणों को बिना किसी रैंकिंग में बदले जांचें
प्रदान की गई प्रत्येक विधि के लिए, नामांकन पूर्वापेक्षाएँ, डिवाइस बाइंडिंग, सिंक्रोनाइज़ेशन, बैकअप, फ़िशिंग प्रतिरोध, उपयोगकर्ता सत्यापन, प्रतिस्थापन और निरसन (रेवोकेशन) नोट करें। NIST बताता है कि पासवर्ड फ़िशिंग-प्रतिरोधी नहीं होते हैं और मैन्युअल रूप से दर्ज किए गए वन-टाइम आउटपुट को फ़िशिंग-प्रतिरोधी नहीं माना जाता है क्योंकि एक ढोंगी वेरिफ़ायर उन्हें रिले कर सकता है। कुछ क्रिप्टोग्राफ़िक ऑथेंटिकेटर किसी आउटपुट को वेरिफ़ायर नाम या संरक्षित चैनल से बांधते हैं। यह किसी एक विधि को सार्वभौमिक समाधान नहीं बनाता है: उपलब्धता, समर्थित डिवाइसेस, रिकवरी और साझा-डिवाइस सीमाएं अभी भी मायने रखती हैं। CISA जहाँ उपलब्ध हो वहाँ MFA की अनुशंसा करता है, लेकिन दो प्रॉम्प्ट केवल तभी उपयोगी होते हैं जब वे वास्तव में अलग हों और फ़ॉलबैक कोई अस्पष्टीकृत बाईपास न हो। विधि के प्रलेखित गुण को रिकॉर्ड करें, न कि 'उन्नत' या 'सुरक्षित' जैसे मार्केटिंग विशेषण को।
सेशन्स और रिकवरी को अलग-अलग स्टेट मशीनों के रूप में ट्रैक करें
सफल ऑथेंटिकेशन के बाद, एक सेशन समाप्ति, साइन-आउट, जोखिम घटना या सर्वर-साइड निरसन तक मान्य रह सकता है। रिकवरी एक नया ऑथेंटिकेटर स्थापित कर सकती है, पासवर्ड रीसेट कर सकती है, फ़ेडरेटेड प्रविष्टि को पुनर्स्थापित कर सकती है या सहायता टीम को शामिल कर सकती है। दोनों अनुक्रमों को चरण दर चरण बनाएं। परीक्षण करें कि क्या किसी एक डिवाइस से साइन आउट करने पर दूसरे पर प्रभाव पड़ता है, क्या फ़ैक्टर बदलने से पुराने सेशन बंद हो जाते हैं, और क्या सेशन सूची ब्राउज़र प्रोफाइल को भौतिक डिवाइसेस से अलग पहचानती है। फिर अनावश्यक रीसेट किए बिना रिकवरी पूर्वापेक्षाओं और सूचनाओं का निरीक्षण करें। ऐसा रिकवरी मेलबॉक्स जो अब आपके नियंत्रण में नहीं है, एक फोन नंबर जो जल्द ही बंद होने वाला है या सामान्य नोट्स में संग्रहीत बैकअप कोड एक अन्य प्रकार से सावधानीपूर्वक बनाए गए लॉगिन पाथ को कमजोर कर सकता है। कभी भी क्रेडेंशियल्स, अस्थायी कोड, रिकवरी लिंक या सटीक निजी उत्तरों को ऑडिट रिकॉर्ड में न रखें।
तीन सीमित ट्रांज़िशन परीक्षण चलाएं
पहला, अपने नियंत्रण वाले डिवाइस पर एक नियमित साइन-इन करें और फ़ैक्टर, प्रॉम्प्ट स्रोत, परिणामी सेशन और दृश्यमान अकाउंट पहचान रिकॉर्ड करें। दूसरा, एक हानिरहित संवेदनशील सेटिंग खोलें, नए-सत्यापन प्रॉम्प्ट पर रद्द करें और पुष्टि करें कि सेटिंग और सेशन्स अपरिवर्तित रहें। तीसरा, एक गैर-आवश्यक ऑथेंटिकेटर को केवल तभी जोड़ें या बदलें जब सर्विस प्रतिवर्ती (रिवर्सिबल) पाथ का दस्तावेजीकरण करती हो; इसे एक बार सत्यापित करें, फिर परीक्षण फ़ैक्टर को हटा दें और पुष्टि करें कि यह अब काम नहीं करता है। यदि प्रतिस्थापन सुरक्षित रूप से प्रतिवर्ती नहीं है, तो इसे निष्पादित करने के बजाय केवल इसका निरीक्षण करें। ऐप संस्करण, डिवाइस, टाइमस्टैम्प, अपेक्षित स्थिति, प्रेक्षित स्थिति और अनसुलझे प्रश्नों को रिकॉर्ड करें। एक सफल परीक्षण केवल उस पाथ और संस्करण को कवर करता है; यह अदृश्य सर्वर व्यवहार को स्थापित नहीं करता है।
सबसे कमजोर ट्रांज़िशन के आधार पर निर्णय लें, सबसे मजबूत स्क्रीनशॉट पर नहीं
प्रत्येक पाथ को अभीष्ट, प्रेक्षित, अनुपलब्ध या अज्ञात के रूप में संक्षेप में प्रस्तुत करें। एक आकर्षक पासकी प्रॉम्प्ट उस रिकवरी की भरपाई नहीं करता जो बिना किसी दूसरी जांच के पुराने मेलबॉक्स को स्वीकार कर लेती है। नियमित लॉगिन पर MFA इस बात का उत्तर नहीं देता कि फ़ैक्टर हटाना नए सत्यापन की मांग करता है या नहीं। एक पूर्ण चेकलिस्ट में कम से कम एक सुरक्षित रिकवरी मार्ग, सेशन्स की समीक्षा करने या उन्हें बंद करने का तरीका, अकाउंट-नियंत्रण परिवर्तनों के लिए स्पष्ट नोटिस और खोए हुए ऑथेंटिकेटर्स को हटाने की एक प्रलेखित विधि दिखनी चाहिए। यदि कोई महत्वपूर्ण पाथ अज्ञात है, तो आधिकारिक सहायता प्राप्त करते समय अकाउंट में अत्यधिक संवेदनशील सामग्री रखने से बचें। मुख्य डिवाइस, रिकवरी कॉन्टैक्ट, आइडेंटिटी प्रोवाइडर, ऑथेंटिकेटर प्रकार या ऐप संस्करण बदलने के बाद मैप पर दोबारा गौर करें—ऐसे शेड्यूल पर नहीं जो बिना किसी नए साक्ष्य के केवल गतिविधि बढ़ाता है।
सामान्य प्रश्न
क्या ऐप लॉक अकाउंट ऑथेंटिकेशन के समान है?
नहीं। एक स्थानीय लॉक किसी एक डिवाइस को नियंत्रित कर सकता है जबकि रिमोट अकाउंट सेशन्स और रिकवरी अलग-अलग नियंत्रणों का पालन करते हैं।
क्या MFA स्वचालित रूप से हर अकाउंट परिवर्तन को अधिक सुरक्षित बनाता है?
स्वचालित रूप से नहीं। जांचें कि कौन से फ़ैक्टर्स नियमित लॉगिन, रिकवरी, फ़ैक्टर हटाने और संवेदनशील परिवर्तनों की सुरक्षा करते हैं।
क्या मुझे अकाउंट रिकवरी का बार-बार परीक्षण करना चाहिए?
नहीं। पूर्वापेक्षाओं का निरीक्षण करें और केवल तभी सीमित, प्रलेखित परीक्षण करें जब सर्विस एक सुरक्षित प्रतिवर्ती मार्ग प्रदान करती हो।