सुरक्षित प्राधिकरण

शुभ दिन, प्रिय हबरज़ितली!

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

हाल ही में, एक स्नातक परियोजना को पूरा करते समय (वैसे, "ऑनलाइन लर्निंग मैनेजमेंट सिस्टम" विषय पर), और मैंने इसके बारे में सोचा। मैं प्राधिकरण के दौरान पासवर्ड सुरक्षा में सुधार करने के लिए एक विचार के साथ आया था। विचार पूरी तरह से नहीं है और पूरी तरह से सोचा नहीं गया है, इसलिए मैं इसे जानकार लोगों के साथ साझा करना चाहता हूं।

सिद्धांत

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

कैसे चलेगा?

मैं निम्नलिखित रूप में सर्वर को एक पासवर्ड भेजने का सुझाव देता हूं: MD5(MD5()+UNIX-timestamp)
पृष्ठ पर लॉगिन फ़ॉर्म भरने के बाद, उपयोगकर्ता "लॉगिन" बटन पर क्लिक करता है, जिसके बाद जावास्क्रिप्ट पासवर्ड से एमडी 5 हैश लेता है, इस लाइन में वर्तमान यूनिक्स समय जोड़ता है, और फिर से प्राप्त लाइन से एमडी 5 लेता है। इस मान को पासवर्ड के बजाय फ़ील्ड में प्रतिस्थापित किया जाता है। इसके अलावा लॉगिन फॉर्म में आपको एक प्रकार का फ़ील्ड सम्मिलित करना होगा जिसमें छिपाया गया है जिसमें UNIX समय सम्मिलित किया जाएगा। स्क्रिप्ट निष्पादित होने के बाद, डेटा सर्वर पर भेजा जाता है।

सर्वर की ओर से, एक स्ट्रिंग डेटाबेस से निर्दिष्ट लॉगिन द्वारा पुनर्प्राप्त की जाती है और यह जांचा जाता है कि क्या एमडी 5 स्ट्रिंग (यूनिक्स समय + (डेटाबेस से पासवर्ड हैश]) के बराबर है जो सर्वर ब्राउज़र ने संचारित किया। यदि हाँ, तो प्राधिकरण सफल था और बाद के प्रमाणीकरण के लिए एक यादृच्छिक स्ट्रिंग उपयोगकर्ता को कुकीज़ में भेजी जाती है, यह डेटाबेस को भी लिखा जाता है।

नुकसान

इस तकनीक में कुछ कमियां हैं, इसलिए बोलना है।

1. मुख्य एक समय से संबंधित है। यह उपयोगकर्ता की ओर है और सर्वर की तरफ लगभग समान होना चाहिए (मुझे नहीं पता कि यह लगभग कितना है, मैं taking 60 सेकंड लेने का सुझाव देता हूं)। इसी समय, यह अतिरिक्त सुरक्षा तत्वों में से एक होगा: डेटा को एक बार इंटरसेप्ट करके, हमलावर बाद में लॉग इन नहीं कर पाएगा, क्योंकि सर्वर अनुरोध आने पर समय की जांच करेगा।

2. और क्या होगा यदि एक हमलावर, डेटा प्राप्त करने के बाद, तुरंत लॉग इन करने की कोशिश करता है? वह सफल होगा, क्योंकि उन्हीं those 60 सेकेंड्स में पास नहीं हुआ होगा। इस समस्या को हल करने के लिए, मैं उस प्रकार के अन्य फ़ील्ड को छिपाने के लिए फ़ॉर्म में प्रस्तावित करता हूं जिसमें सर्वर कुंजी (रैंडमो द्वारा गठित) को रखेगा। इस कुंजी को समय और पासवर्ड के साथ एक साथ एन्क्रिप्ट किया जा सकता है, सर्वर में वापस स्थानांतरित कर दिया जाता है और वहां इसे भी चेक किया जाएगा।

3. तीसरा भी समय से संबंधित है। आप पूछते हैं, यदि किसी उपयोगकर्ता के पास कंप्यूटर पर निर्धारित समय है जो सर्वर पर मूल रूप से समय से अलग है, तो आपको क्या करना चाहिए? "मैं नहीं जानता," मैं आपको बताता हूँ। यद्यपि भविष्य के लिए एक विचार है: सर्वर को डेटा भेजने से पहले, वेब पेज सर्वर को समय का पता लगाने के लिए AJAX अनुरोध कर सकता है, और फिर डेटा भेज सकता है। वैसे, एक ही यादृच्छिक कुंजी समान अनुरोध में आ सकती है।

और एक कुंजी के साथ सिर्फ एक विकल्प बनाना असंभव था?

नहीं, आप नहीं कर सकते। यह मेरा विचार है। अनुरोध के उत्पन्न होने पर इसकी प्रारंभिक अवधारणा समय जांच का उपयोग कर रही थी। एक खुली कुंजी का विचार मेरे दिमाग में बहुत बाद में आया।

परिणाम

एक झपट्टा में, हमें कई स्तर की सुरक्षा मिलती है: पासवर्ड स्पष्ट पाठ में प्रेषित नहीं किया जाता है, समय की जांच की जाती है, सार्वजनिक कुंजी लागू होती है।

हमारे पास सब कुछ है और कुछ भी नहीं है। मेरे पास तब थोड़ा समय था, इसलिए मैं इसे जीवन भर नहीं ला सका। केवल एक विचार-तैयार विचार है।

प्रिय ख़बरवचन, मुझे बताओ, क्या यह विचार विकसित करने के लायक है? मेरे पास अब इस संबंध में कुछ आधार है। अगर आपको मेरा विचार पसंद आया, तो अगले लेख में मैं अपने काम के परिणामों को प्रकाशित करूंगा। यदि किसी के पास इस विषय पर कोई सुझाव है, तो कृपया लिखें। आपकी आलोचना के लिए अग्रिम धन्यवाद।