स्ट्रिंग आधारित प्रोटोकॉल सुरक्षा की मूल बातें

Question

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

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

प्रमाणीकरण लेन-देन: ग्राहक जोड़ता है और तुरंत एक चुनौती प्रतिक्रिया एक 16 वर्ण हेक्स तार के साथ वापस भेज दिया जाता है। ग्राहक पक्ष उपयोगकर्ता नाम & पासवर्ड लेता है, पासवर्ड sha1 (नमक + sha1 (पासवर्ड) परिवर्तित किया जाता है और प्रमाण पत्र सर्वर पर वापस {उपयोगकर्ता नाम, पासवर्ड} के रूप में भेजा जाता है। सर्वर की तरफ, प्रमाणीकरण मानक लुकअप पैटर्न करता है (यदि उपयोगकर्ता मौजूद है और इनपुट के बराबर पासवर्ड है तो अनुदान दें)।

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

मैं कुछ याद आ रही है? क्या एक चरित्र स्ट्रीम आधारित प्रोटोकॉल के लिए एक बेहतर/अधिक सुरक्षित दृष्टिकोण है?

Answer 1

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

कभी भी व्हेल को पुनर्जीवित न करें, खासकर जब सुरक्षा की बात आती है।

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

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

Answer 2

आपका प्रमाणीकरण ठोस लगता है लेकिन man in the middle attacks पर प्रवण होता है क्योंकि यह सर्वर से कनेक्शन की अखंडता सुनिश्चित नहीं करता है।

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