प्रतिनिधि इंटरव्यू विषय

आप एक सुरक्षित मैजिक-लिंक लॉगिन कैसे डिज़ाइन करेंगे?

बैकएंडकठिन
Offer.cc संपादकीय टीमप्रकाशित अपडेट किया गया

प्रश्न

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

प्रॉम्प्ट और संदर्भ

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

साक्षात्कारकर्ता क्या परख रहा है

  • क्या आप अप्रत्याशित (unpredictable), कम समय तक चलने वाले और सिंगल-यूज़ टोकन का उपयोग करते हैं।
  • क्या आप अकाउंट एन्यूमरेशन, लॉग लीकेज और ब्रूट-फ़ोर्स सत्यापन को रोकते हैं।
  • क्या आप सुविधा को आश्वासन (assurance) और फ़िशिंग प्रतिरोध से अलग समझते हैं।
  • क्या सत्र, निरस्तीकरण, सूचनाएं, ऑडिट और फ़ॉलबैक पूर्ण हैं।

उत्तर देने से पहले स्पष्टीकरण प्रश्न

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

30-सेकंड उत्तर रूपरेखा

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

चरण-दर-चरण विस्तृत विश्लेषण

1. जनरेशन और स्टोरेज

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

2. अनुरोध और सत्यापन

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

3. सत्र और जोखिम नियंत्रण

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

उच्च-गुणवत्ता वाला नमूना उत्तर

मैं मैजिक लिंक को कम जोखिम वाले एक्सेस के लिए एक सुविधाजनक कारक के रूप में परिभाषित करता हूं, न कि एक सार्वभौमिक फ़िशिंग-प्रतिरोधी प्रमाणीकरणकर्ता के रूप में। एक अनुरोध के बाद, सेवा CSPRNG का उपयोग करती है, केवल हैश, उद्देश्य, समाप्ति और उपभोग की स्थिति को संग्रहीत करती है, और प्रत्येक पते के लिए समान परिणाम लौटाती है। सत्यापनकर्ता HTTPS पर हैश को खोजता है, इसे एटॉमिक रूप से उपयोग के रूप में चिह्नित करता है, सत्र ID को घुमाता है, एक सुरक्षित कुकी सेट करता है और एक ऑडिट इवेंट रिकॉर्ड करता है। लिंक अल्पकालिक और निरस्त करने योग्य होते हैं; उनके URL को लॉग और एनालिटिक्स से बाहर रखा जाना चाहिए। प्रीफ़ेच को संभालने के लिए, एक पुष्टिकरण पृष्ठ दिखाएं और एक जानबूझकर क्लिक की आवश्यकता रखें। अग्रेषण (forwarding) और एकाधिक उपकरणों के लिए, परिभाषित करें कि क्या एक बार उपभोग की अनुमति है और खाता स्वामी को कैसे सूचित किया जाए। भुगतान और विशेषाधिकार परिवर्तन MFA या WebAuthn का उपयोग करते हैं। परीक्षण रीप्ले, समवर्ती क्लिक, एन्यूमरेशन, रेट सीमाएं, मेल रिसाव, विसंगतिपूर्ण डिवाइस और निरस्तीकरण को कवर करते हैं।

सामान्य गलतियाँ

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

अनुवर्ती प्रश्न और उत्तर

मेल-क्लाइंट प्रीफ़ेचिंग के बारे में क्या करें?

GET विज़िट पर लॉगिन पूरा न करें। एक पुष्टिकरण पृष्ठ दिखाएं, केवल स्पष्ट उपयोगकर्ता कार्रवाई के बाद टोकन का उपभोग करें, और प्रीफ़ेच टेलीमेट्री को वास्तविक क्लिक से अलग करें।

टोकन कितने समय तक सक्रिय रहना चाहिए?

जोखिम और मेल-देरी बजट से एक छोटी विंडो चुनें, फिर रीप्ले और अप्रयुक्त दरों की निगरानी करें। समाप्ति के बाद, पुराने टोकन को बढ़ाने के बजाय एक नया टोकन जारी करें।

प्रशासकों या भुगतान अनुमोदन के लिए इसका उपयोग क्यों नहीं किया जाता?

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

सार्वजनिक स्रोत

संबंधित प्रश्न