बैकएंड इंटरव्यू: आप कुकी लॉगिन को डिवाइस-बाउंड सेशन में कैसे अपग्रेड करेंगे?

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

एक मौजूदा लॉगिन सिस्टम लॉन्ग-लिव्ड कुकीज़ के साथ उपयोगकर्ताओं को साइन इन रखता है। सुरक्षा टीम कुकी चोरी के बाद क्रॉस-डिवाइस रीप्ले को कम करना चाहती है, लेकिन वह सभी क्लाइंट्स को एक साथ अपग्रेड नहीं कर सकती या की रोटेशन (key rotation), ब्राउज़र रीस्टार्ट या डिवाइस रिकवरी के दौरान बड़े पैमाने पर लॉगआउट नहीं करा सकती। एक DBSC इंटीग्रेशन डिज़ाइन करें जिसमें रजिस्ट्रेशन, रिफ्रेश, रिवोकेशन, फॉलबैक, ऑडिट और क्रमिक रोलआउट (gradual rollout) शामिल हो।

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

• क्या आप लॉन्ग-लिव्ड आइडेंटिटी सेशन, शॉर्ट-लिव्ड ऑथराइजेशन कुकी और डिवाइस प्राइवेट की को अलग करते हैं।
• क्या आप रजिस्ट्रेशन और रिफ्रेश एंडपॉइंट्स, चैलेंज-रिस्पॉन्स और सर्वर-साइड बाइंडिंग रिकॉर्ड्स को समझा सकते हैं।
• क्या आप नॉन-एक्सपोर्टेबल कीज़, असमर्थित ब्राउज़र, अनुपलब्ध कुकीज़ और डिवाइस माइग्रेशन को संभालते हैं।
• क्या आप रिवोकेशन, की रोटेशन, समवर्ती (concurrent) रिफ्रेश और विसंगति का पता लगाने (anomaly detection) को डिज़ाइन करते हैं।
• क्या कम्पैटिबिलिटी और सुरक्षा सीमाएँ रोलआउट, मॉनिटरिंग और रोलबैक में दिखाई देती हैं।

पहले स्पष्ट करने योग्य प्रश्न

1. किन खातों या ऑपरेशन्स के लिए डिवाइस बाइंडिंग की आवश्यकता है, और कौन सामान्य कुकीज़ रख सकते हैं?
2. अधिकतम सेशन लाइफटाइम, रिफ्रेश अंतराल और स्वीकार्य पुनः लॉगिन दर (re-login rate) क्या हैं?
3. क्या आपको एकाधिक डिवाइस, एंटरप्राइज प्रॉक्सी, बिना TPM वाले डिवाइस या क्रॉस-साइट सबडोमेन की आवश्यकता है?
4. प्रूफ विफल होने के बाद, क्या सिस्टम को साइन आउट करना चाहिए, MFA पर फॉलबैक करना चाहिए, या उच्च जोखिम वाली कार्रवाइयों को फ्रीज करना चाहिए?
5. क्या मौजूदा गेटवे रजिस्ट्रेशन और रिफ्रेश हेडर पास कर सकता है, और किन फ़ील्ड्स को लॉग किया जा सकता है?

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

"मैं मौजूदा लॉगिन स्थिति को कम्पैटिबिलिटी लेयर के रूप में रखूँगा। लॉगिन के बाद, एक Secure-Session-Registration रिस्पॉन्स ब्राउज़र से डिवाइस की (key) बनाने के लिए कहता है। सर्वर केवल पब्लिक की, सेशन आइडेंटिफायर, रिफ्रेश एंडपॉइंट, स्कोप और स्थिति को स्टोर करता है, फिर लॉन्ग-लिव्ड कुकी को शॉर्ट-लिव्ड कुकी से बदल देता है। जब यह समाप्त हो जाती है, तो ब्राउज़र एक की प्रूफ के साथ रिफ्रेश एंडपॉइंट को कॉल करता है; सर्वर एक नई कुकी जारी करने से पहले सिग्नेचर, चैलेंज, सेशन और रिस्क पॉलिसी को सत्यापित करता है। रजिस्ट्रेशन या रिफ्रेश विफलताएँ क्षमता और जोखिम के अनुसार एक सामान्य सेशन या MFA पर फॉलबैक होती हैं। रिवोकेशन, रोटेशन, ऑडिट और रोलआउट मेट्रिक्स विस्तार को नियंत्रित करते हैं।"

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

1. ट्रस्ट सीमाओं और स्थिति (state) को परिभाषित करें

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

2. एक डिवाइस-बाउंड सेशन रजिस्टर करें

सफल लॉगिन के बाद, रजिस्ट्रेशन रिस्पॉन्स हेडर लौटाएं। ब्राउज़र एक की-पेयर (की जोड़ी) जनरेट करता है और पब्लिक की को रजिस्ट्रेशन एंडपॉइंट पर सबमिट करता है। सर्वर एक बार इस्तेमाल होने वाले (one-time) रजिस्ट्रेशन टोकन, लॉगिन सेशन और ओरिजिन को मान्य करता है, बाइंडिंग लिखता है, और JSON सेशन निर्देश के साथ एक शॉर्ट-लिव्ड कुकी लौटाता है। रजिस्ट्रेशन इडेम्पोटेंट (idempotent) होना चाहिए ताकि पुनः प्रयास करने पर कोई ऐसी अनाथ बाइंडिंग न बने जिसे रद्द न किया जा सके।

Secure-Session-Registration: (ES256); path="/StartSession"
Set-Cookie: auth_cookie=short-lived; Max-Age=600; Secure; HttpOnly; SameSite=Lax

3. रिफ्रेश के दौरान की प्रूफ को सत्यापित करें

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

4. फॉलबैक और एकाधिक डिवाइस को संभालें

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

5. रोटेशन, कंकरेंसी और रिकवरी डिज़ाइन करें

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

6. मॉनिटर करें, ऑडिट करें और धीरे-धीरे रोल आउट करें

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

एक सशक्त उत्तर का उदाहरण

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

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

• पब्लिक की को उपयोगकर्ता की पहचान मानना → बाइंडिंग और ऑथेंटिकेशन प्रिंसिपल्स आपस में मिल जाते हैं → इसे केवल सेशन प्रूफ सामग्री के रूप में उपयोग करें।
• केवल लॉन्ग-लिव्ड कुकी को छोटा करना → चोर अभी भी इसके लाइफटाइम के दौरान इसे रीप्ले कर सकता है → शॉर्ट-लिव्ड कुकी को की प्रूफ से बांधें।
• रिफ्रेश पर रीप्ले सुरक्षा को छोड़ देना → एक ही प्रूफ का पुन: उपयोग किया जा सकता है → एक वन-टाइम चैलेंज, टाइम विंडो और एटॉमिक स्टेट अपडेट को बाइंड करें।
• असमर्थित होने पर सभी को साइन आउट करना → कम्पैटिबिलिटी और उपलब्धता प्रभावित होती है → क्षमता और जोखिम के अनुसार सामान्य सेशन या MFA पर फॉलबैक करें।
• DBSC को अपरिवर्तनीय (irrevocable) मानना → खोए हुए डिवाइस को अलग-थलग नहीं किया जा सकता → ऑडिट के साथ डिवाइस-स्तरीय और उपयोगकर्ता-स्तरीय रिवोकेशन प्रदान करें।

फॉलो-अप और उत्तर

क्या एक प्राइवेट की कुकी चोरी के हर रूप को रोकती है?

नहीं। DBSC मुख्य रूप से किसी कुकी को दूसरे डिवाइस पर निर्यात (export) करने के बाद सीधे रीप्ले को कम करता है। मूल डिवाइस को नियंत्रित करने वाला मैलवेयर, लॉगिन के दौरान हमले, या एक कॉम्प्रोमाइज्ड सर्वर के लिए अभी भी अन्य सुरक्षा उपायों की आवश्यकता होती है। खतरे के मॉडल (threat model) और अवशिष्ट जोखिम (residual risk) को स्पष्ट रूप से बताएं।

सामान्य-सेशन पाथ को क्यों बनाए रखें?

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

आप समवर्ती रिफ्रेश रेस (concurrent refresh races) को कैसे रोकते हैं?

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

डिवाइस माइग्रेशन या रीस्टोर के दौरान क्या होता है?

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