बैकएंड इंटरव्यू: आप एक सुरक्षित ईमेल-बदलने का फ़्लो कैसे डिज़ाइन करेंगे?

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

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

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

इंटरव्यूअर क्या जांचता है

इंटरव्यूअर एक सक्रिय सत्र और हाल ही में पुनः सिद्ध की गई पहचान के बीच का अंतर समझना चाहता है। बेहतरीन उत्तर उच्च-जोखिम वाले खातों के लिए पुनः प्रमाणीकरण (reauthentication) या मौजूदा मल्टी-फ़ैक्टर विधि की मांग करते हैं। वे सत्यापन सफल होने तक प्रस्तावित पते को अलग रखते हैं।

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

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

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

चरण-दर-चरण गहन विश्लेषण

चरण 1: खाते और लंबित अनुरोध का मॉडल बनाएं

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

चरण 2: पुनः प्रमाणित करें और जोखिम सीमा निर्धारित करें

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

चरण 3: वन-टाइम टोकन जनरेट करें और वितरित करें

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

चरण 4: सत्यापित करें और एटॉमिक रूप से कमिट करें

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

चरण 5: पुराने पते, सत्रों और सूचनाओं को संभालें

पुराने पते पर एक सुरक्षा सूचना भेजें और अनुरोध के लंबित रहने के दौरान रद्दीकरण की अनुमति दें। सफलता पर, लंबे समय तक चलने वाले रिफ़्रेश टोकन रद्द करें या अन्य सत्रों को पुनः प्रमाणित करने की आवश्यकता रखें; उच्च-जोखिम वाले खातों के लिए तत्काल वैश्विक निरस्तीकरण की आवश्यकता हो सकती है। नया पता तत्काल रिकवरी का एकमात्र प्रमाण नहीं बनना चाहिए।

चरण 6: एन्यूमरेशन, दुरुपयोग और रेस कंडीशन्स को नियंत्रित करें

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

चरण 7: रिकवरी और अनुपलब्ध मामलों को डिज़ाइन करें

पुराने टोकन को अमान्य करते हुए डिलीवरी में देरी के लिए सीमित पुन: भेजने की अनुमति दें। यदि पुराना पता खो जाता है, तो असत्यापित नए पते को अधिग्रहण (takeover) के पर्याप्त प्रमाण के रूप में स्वीकार न करें; खाते की अधिक मजबूत रिकवरी प्रक्रिया का उपयोग करें। डिलीवरी विफलताओं, पहले से उपयोग किए जा रहे पतों, और नीतिगत अस्वीकृतियों को ऑडिट रिकॉर्ड में आंतरिक कारण कोड बनाए रखते हुए सुरक्षित संदेश प्रदर्शित करने चाहिए।

चरण 8: खतरों का परीक्षण करें और परिणामों को मापें

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

समझौते (Trade-offs), सीमाएं, और सूचना प्राप्ति

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

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

मॉडल उच्च-गुणवत्ता वाला उत्तर

“मैं ईमेल परिवर्तन को एक उच्च-जोखिम वाली स्टेट मशीन के रूप में मानूंगा। उपयोगकर्ता हालिया पुनः प्रमाणीकरण और, आवश्यकता पड़ने पर, एक मौजूदा MFA जांच पूरी करता है। प्रस्तावित पता एक लंबित रिकॉर्ड में जाता है; वर्तमान पता लॉगिन और रिकवरी के लिए आधिकारिक बना रहता है। एक CSPRNG कम TTL के साथ एक सिंगल-यूज़ टोकन उत्पन्न करता है, जबकि डेटाबेस केवल इसका डाइजेस्ट, उद्देश्य, वर्ज़न, और स्थिति संग्रहीत करता है।

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

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

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

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

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

पहले नया पता क्यों न लिखें और एसिंक्रोनस रूप से सत्यापित क्यों न करें?

लॉगिन, रिकवरी, और सूचनाएं तुरंत इसका उपभोग कर सकती हैं, जबकि रोलबैक रेस कंडीशन्स उत्पन्न करता है। एक अलग लंबित मान अप्रमाणित इनपुट को पहचान सीमा से बाहर रखता है।

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

कोई जोखिम-स्वतंत्र संख्या नहीं है। डिलीवरी वितरण और खतरे के लक्ष्यों के आधार पर एक छोटी विंडो चुनें, सीमित पुन: भेजने की सुविधा जोड़ें, और वास्तविक जारी करने-से-समाप्ति व्यवहार को मापें।

क्या पुराने पते की सूचना MFA की जगह ले सकती है?

नहीं। सूचना और रद्दीकरण गहन-सुरक्षा (defense-in-depth) और रिकवरी संकेत हैं, न कि उच्च-आश्वासन पहचान का प्रमाण। उच्च-जोखिम वाले खातों को अभी भी एक मौजूदा MFA विधि या मजबूत रिकवरी की आवश्यकता होती है।

क्या होगा यदि दो टैब एक साथ पुष्टि करते हैं?

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

आप टोकन को एनालिटिक्स से बाहर कैसे रखते हैं?

एक वन-टाइम पाथ का उपयोग करें, एज और एप्लिकेशन स्तरों पर क्वेरी पैरामीटर फ़िल्टर करें, उपभोग के बाद एक साफ़ URL पर रीडायरेक्ट करें, और संवेदनशील प्रतिक्रियाओं के लिए कैशिंग अक्षम करें।