सबसे सुरक्षित प्रमाणीकरण। सर्वर पर क्लाइंट प्राधिकरण एल्गोरिथ्म की चर्चा

सभी को नमस्कार। एक बार के पासवर्ड पर हाल ही में चर्चा किया गया लेख। मैं इसे थोड़ा पूरक करना चाहूंगा, क्योंकि आप इस विषय को विकसित नहीं कर सकते हैं, पंजीकरण और पासवर्ड परिवर्तन के रूप में उपयोगकर्ता के साथ काम करने के ऐसे ही महत्वपूर्ण क्षेत्रों के बारे में भूल जाते हैं।

यह पोस्ट केवल सॉकेट-आधारित प्राधिकरण प्रणाली में एक प्रस्ताव होगा और अब तक इसे लागू करने का दावा नहीं कर सकता है। हालाँकि मुझे यकीन है कि इस तरह की बात कहीं से पहले ही लागू हो चुकी है, लेकिन मुझे लगता है कि इस विषय पर समुदाय को विचार करना दिलचस्प होगा।

इसलिए, हमारे पास कई कार्य हैं जिन्हें पूरा करने की आवश्यकता है:

1. सर्वर पर स्वचालित क्लाइंट प्राधिकरण के लिए एक तंत्र बनाएँ।
2. प्रमाणीकरण के दौरान सबसे सुरक्षित पासवर्ड ट्रांसफर तंत्र को लागू करें, जिसमें पासवर्ड हैश की चोरी पूरी तरह से निरर्थक होगी।
3. पासवर्ड परिवर्तन तंत्र को सुरक्षित बनाएं।
4. एक सुरक्षित क्लाइंट पंजीकरण तंत्र बनाएँ।

डेटा और कार्य की स्थिति

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

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

1. स्वचालित प्राधिकरण का तंत्र

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

1. पासवर्ड को हैश करें ताकि वायरस क्लीन यूजर पासवर्ड को न देख सके।
2. पासवर्ड हैश को कुंजी द्वारा एन्क्रिप्ट किया जाना चाहिए और क्लाइंट पर लगातार भंडारण में संग्रहीत किया जाना चाहिए। यह पुन: प्रयोज्य होने के लक्ष्य के साथ किया जाता है। यदि आप एक खुला हैश छोड़ते हैं, तो वायरस, इस हैश को चोरी करने पर, मुख्य पासवर्ड को जानने के बिना सर्वर पर अधिकृत करने में सक्षम होगा। एक कुंजी के रूप में, कंप्यूटर से कुछ सिस्टम जानकारी लेना सबसे अच्छा होगा, उदाहरण के लिए, नेटवर्क कार्ड का मैक पता, हार्डवेयर का उत्पादन नंबर, या कुछ और जो डिक्रिप्शन के लिए एक स्थायी कुंजी हो सकता है। यह वायरस के प्रवेश के मामले में 100% सुरक्षा नहीं देगा, लेकिन पटाखे के काम को जटिल करेगा।
3. स्वचालित प्राधिकरण के साथ, एन्क्रिप्टेड हैश को कुछ डेटा के साथ डिक्रिप्ट और नमकीन किया जाएगा।

मुख्य समस्याएं

काश, हम केलॉगर्स और एक और दबाने वाले संक्रमण के साथ कुछ नहीं कर सकते हैं जो सीधे पासवर्ड को क्रैक करेगा, लेकिन हम इसे अच्छी तरह से इरादे के लिए जगह देते हैं

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

तो, हमारे पास एक पासवर्ड हैश है। अगला, हमें इस पासवर्ड को सैल्यूट करना होगा। इस तथ्य के कारण कि एप्लिकेशन भी नेटवर्क-आधारित है, हम नमक के रूप में उपयोग करेंगे:

• पासवर्ड हैश
• उपयोगकर्ता का बाहरी आईपी
• पासवर्ड सॉल्टिंग के लिए टाइमस्टैम्प
• लॉगिन (वैकल्पिक)

बाहरी आईपी

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

var socket = require('net').createConnection(80, 'google.com'); //      ,    var outsideCleintIP = socket.address().address; 

वर्तमान समय के साथ वन-टाइम पासवर्ड

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

हम तुरंत एक पत्थर से 2 पक्षियों को मारते हैं: सिंक और हैश इंटरसेप्शन से बाहर समय।

सर्वर डिक्रिप्शन

अब सर्वर पर काम करने के बारे में थोड़ा। जब कोई हैश हमारे पास आता है, तो हमें उसी समान हैश बनाना होगा। हमारे पास पासवर्ड का ही एक हैश (डेटाबेस में संग्रहीत) है। हमारे पास प्राधिकरण के लिए एक अस्थायी विंडो है, हमारे पास एक कनेक्टेड उपयोगकर्ता आईपी है। हम आसानी से एक ही हैश बना सकते हैं और अधिकृत कर सकते हैं।

मुख्य समस्याएं

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

यहां मेरे पास पहले से ही उन लोगों के लिए एक सवाल है जो जानते हैं। क्या कोई हमलावर खुद पर नियंत्रण का प्रवाह ले सकता है ताकि सर्वर को ग्राहक के खराब होने की सूचना न हो?

3. पासवर्ड परिवर्तन तंत्र

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

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

मुख्य समस्याएं

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

4. पंजीकरण

हटाने योग्य पासवर्ड के साथ भी यही समस्या है। किसी तरह हैश को सर्वर में स्थानांतरित करना आवश्यक है ताकि हमलावर इसे चोरी न करे।
क्लाइंट को एसएमएस / मेल के माध्यम से उसका पासवर्ड भेजना संभव है, जिसे वह सुरक्षित पासवर्ड परिवर्तन के आधार पर बदल सकेगा, या हम फिर से सुरक्षा के लिए SSL / TSL का उपयोग कर सकते हैं।

मुख्य समस्याएं

हम फिर से सर्वर पर पासवर्ड संचारित करने की समस्या में भाग गए, पुनर्प्राप्ति के लिए केवल 2 विकल्प हैं। यह या तो एक एन्क्रिप्टेड संचार चैनल है या सर्वर पर पासवर्ड संचारित करने के लिए एक वैकल्पिक मार्ग है।

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

दबाने वाले मुद्दे

लोग प्रॉक्सी, डायनेमिक आईपी और अन्य चीजों जैसी चीजों का उल्लेख करेंगे। अब हम उनका विश्लेषण करेंगे।

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

2) प्रॉक्सी
सौभाग्य से, प्रॉक्सी ग्राहक के सामान्य संचालन में हस्तक्षेप करने में सक्षम नहीं होंगे। यदि ग्राहक खुले परदे के पीछे का उपयोग करता है, तो वह खुद को प्राधिकरण के अवरोधन के खतरे के लिए उजागर करता है और खुद को बुराई पिनोचियो होगा।

मैं चाहूंगा कि हेब्रा के उपयोगकर्ता अपने प्रश्नों या समस्याओं को यहाँ जोड़ दें।

केवल के लिए

इस एल्गोरिथ्म में केवल उन प्रणालियों में जीवन का अधिकार है जहां सर्वर के साथ प्राधिकरण सॉकेट / वेब सॉकेट पर होता है। मुझे अभी भी समझ नहीं आया कि यह प्राधिकरण एल्गोरिदम http अनुरोधों पर कैसे लागू किया जा सकता है, क्योंकि हम स्वयं प्रोटोकॉल की सीमाओं से सीमित हैं, हम क्लाइंट-> सर्वर-> क्लाइंट-> सर्वर से संवाद नहीं कर सकते हैं। आखिरी नोड अब प्रोटोकॉल विनिर्देश के कारण काम नहीं करता है (हालांकि शायद मैं गलत हूं)।

लेख की निरंतरता

यदि यह लेख आलोचना का सामना कर सकता है, तो मैं इस तंत्र को जावास्क्रिप्ट (नोड-वेबकिट) और पायथन में लागू करूंगा, ताकि आप शारीरिक कमजोरियों के लिए पहले से ही इस प्रणाली को रोक सकें, जो इस लेख में याद किया जा सकता है।

आप सभी को धन्यवाद, मैं रचनात्मक आलोचना और टिप्पणियों के लिए तत्पर हूं।