SRP पासवर्ड प्रमाणीकरण: लाभ और डेटा उल्लंघन की सीमाएँ

Secure Remote Password, यानी SRP, क्लाइंट और सर्वर को सामान्य प्रोटोकॉल आदान-प्रदान में पासवर्ड भेजे बिना उसका उपयोग करके प्रमाणीकरण करने देता है। इससे उस सर्वर के सामने पासवर्ड का खुलासा कम हो सकता है जिसे अन्यथा लॉगिन के दौरान पासवर्ड मिलता।

यह सर्वर से पासवर्ड से जुड़ा हर रहस्य नहीं हटाता। सर्वर एक वेरिफायर रखता है और चोरी हुआ वेरिफायर ऑफलाइन पासवर्ड अनुमान लगाने में मदद कर सकता है। “जीरो-नॉलेज लॉगिन” के दावों का आकलन करते समय यह अंतर जरूरी है।

पारंपरिक पासवर्ड लॉगिन की तुलना में क्या बदलता है?

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

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

RFC 2945 में SRP का विनिर्देश प्रोटोकॉल की बुनियाद समझाता है। बाद के प्रोफाइल और कार्यान्वयन के सटीक पैरामीटर और संदेश जाँचों की समीक्षा जरूरी है; किसी डिजाइन को “SRP” कहने से हर कार्यान्वयन निर्णय सही साबित नहीं होता।

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

चोरी हुआ वेरिफायर फिर भी क्यों महत्वपूर्ण है

RFC 5054 का खंड 3.3 चोरी हुए वेरिफायर पर स्पष्ट चर्चा करता है। यह बताता है कि वेरिफायर किसी हमलावर को सर्वर का रूप धारण करने और पासवर्ड पाने के लिए डिक्शनरी हमले करने दे सकता है।

महत्वपूर्ण अंतर यह है कि वेरिफायर बस दोबारा इस्तेमाल होने वाला क्लाइंट लॉगिन टोकन नहीं है। इससे वह हानिरहित नहीं हो जाता। हमलावर हर संभावित रहस्य के लिए डिस्क्रीट लॉगरिदम की समस्या हल करने के बजाय चोरी हुई सामग्री के विरुद्ध संभावित पासवर्ड जाँच सकता है। कमजोर या दोबारा इस्तेमाल किया गया पासवर्ड गंभीर जोखिम बना रहता है।

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

SRP किन चीजों से नहीं बचाता

समझौता हो चुका एंडपॉइंट: मालवेयर प्रोटोकॉल शुरू होने से पहले पासवर्ड पकड़ सकता है या उसके बाद प्रमाणीकृत सत्र चुरा सकता है।

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

रिकवरी के सभी रास्ते: ईमेल, SMS या सहायता की वह प्रक्रिया जो खाते तक पहुँच देती है, उसकी अपनी आवश्यकताएँ होती हैं। कमजोर वैकल्पिक रास्ता सबसे मजबूत सामान्य लॉगिन विधि को भी कमजोर कर सकता है।

हर सक्रिय नेटवर्क हमला: प्रोटोकॉल पैरामीटर, इनपुट सत्यापन, पारस्परिक पुष्टि और आसपास का प्रमाणीकृत कनेक्शन महत्वपूर्ण हैं। किसी डिप्लॉयमेंट के निर्धारित TLS सुरक्षा उपायों को “पासवर्ड कभी भेजा ही नहीं जाता” के नारे से न बदलें।

मेटाडेटा या चैट एन्क्रिप्शन: प्रमाणीकरण बताता है कि किसी सत्र को प्रवेश मिलना चाहिए या नहीं। वह यह तय नहीं करता कि बातचीत के कौन-से रिकॉर्ड मौजूद हैं या संदेश डिक्रिप्ट करने वाली कुंजियाँ किसके पास हैं।

Livara लॉगिन को पहचान रिकवरी से कैसे अलग रखता है

Livara का सुरक्षा अवलोकन SRP प्रमाणीकरण का वर्णन उसके LVR1 मैसेजिंग प्रोटोकॉल से अलग करता है। वह संस्करण 7 का एन्क्रिप्टेड पहचान बैकअप भी दस्तावेजित करता है, जो अलग यादृच्छिक 256-बिट रिकवरी कुंजी से सुरक्षित होता है।

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

खतरा मॉडल में डिवाइस से समझौता और संचार का दिखाई देने वाला मेटाडेटा भी शामिल है। SRP के आधार पर पूरी सेवा को उपयोगकर्ता की गतिविधि के हर पहलू के बारे में “जीरो नॉलेज” वाला नहीं कहना चाहिए।

आकलन की एक व्यावहारिक जाँच-सूची

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

तकनीकी समीक्षक के तौर पर सटीक प्रोटोकॉल प्रोफाइल, पासवर्ड से वेरिफायर बनाने की प्रक्रिया, इनपुट सत्यापन, विफलता प्रबंधन, पंजीकरण प्रवाह और रीसेट डिजाइन माँगें। क्लाइंट और सर्वर की साथ समीक्षा करें। केवल सफल लॉगिन परीक्षण पर निर्भर रहने के बजाय अमान्य सार्वजनिक मानों, रीप्ले और बीच में टूटे सत्रों के परीक्षण भी शामिल करें।

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