एमआईटी पाठ्यक्रम "कंप्यूटर सिस्टम सुरक्षा"। व्याख्यान 17: उपयोगकर्ता प्रमाणीकरण, भाग 1

मैसाचुसेट्स इंस्टीट्यूट ऑफ टेक्नोलॉजी। व्याख्यान पाठ्यक्रम # 6.858। "कंप्यूटर सिस्टम की सुरक्षा।" निकोलाई ज़ेल्डोविच, जेम्स मिकेंस। 2014 साल

कंप्यूटर सिस्टम सुरक्षा सुरक्षित कंप्यूटर सिस्टम के विकास और कार्यान्वयन पर एक कोर्स है। व्याख्यान खतरे के मॉडल को कवर करते हैं, हमले जो सुरक्षा से समझौता करते हैं, और हाल के वैज्ञानिक कार्यों के आधार पर सुरक्षा तकनीक। विषयों में ऑपरेटिंग सिस्टम (OS) सुरक्षा, सुविधाएँ, सूचना प्रवाह प्रबंधन, भाषा सुरक्षा, नेटवर्क प्रोटोकॉल, हार्डवेयर सुरक्षा और वेब अनुप्रयोग सुरक्षा शामिल हैं।

व्याख्यान 1: "परिचय: खतरे के मॉडल" भाग 1 / भाग 2 / भाग 3
व्याख्यान 2: "हैकर हमलों का नियंत्रण" भाग 1 / भाग 2 / भाग 3
व्याख्यान 3: "बफर ओवरफ्लो: शोषण और संरक्षण" भाग 1 / भाग 2 / भाग 3
व्याख्यान 4: "पृथक्करण का पृथक्करण" भाग 1 / भाग 2 / भाग 3
व्याख्यान 5: "सुरक्षा प्रणालियाँ कहाँ से आती हैं?" भाग 1 / भाग 2
व्याख्यान 6: "अवसर" भाग 1 / भाग 2 / भाग 3
व्याख्यान 7: "मूल ग्राहक सैंडबॉक्स" भाग 1 / भाग 2 / भाग 3
व्याख्यान 8: "नेटवर्क सुरक्षा मॉडल" भाग 1 / भाग 2 / भाग 3
व्याख्यान 9: "वेब अनुप्रयोग सुरक्षा" भाग 1 / भाग 2 / भाग 3
व्याख्यान 10: "प्रतीकात्मक निष्पादन" भाग 1 / भाग 2 / भाग 3
व्याख्यान 11: "उर / वेब प्रोग्रामिंग भाषा" भाग 1 / भाग 2 / भाग 3
व्याख्यान 12: नेटवर्क सुरक्षा भाग 1 / भाग 2 / भाग 3
व्याख्यान 13: "नेटवर्क प्रोटोकॉल" भाग 1 / भाग 2 / भाग 3
व्याख्यान 14: "एसएसएल और एचटीटीपीएस" भाग 1 / भाग 2 / भाग 3
व्याख्यान 15: "मेडिकल सॉफ्टवेयर" भाग 1 / भाग 2 / भाग 3
व्याख्यान 16: "साइड चैनल हमलों" भाग 1 / भाग 2 / भाग 3
व्याख्यान 17: "उपयोगकर्ता प्रमाणीकरण" भाग 1 / भाग 2 / भाग 3

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



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

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

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

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



तो पासवर्ड क्या है? पासवर्ड उपयोगकर्ता और सर्वर के लिए एक साझा रहस्य है। इस प्रकार, पासवर्ड योजना के एक आदिम कार्यान्वयन के लिए मूल रूप से केवल एक सर्वर-साइड टेबल होना चाहिए जो उपयोगकर्ता नाम को उनके पासवर्ड पर मैप करता है।

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

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

कम से कम सिद्धांत में, हैश का उपयोग करना एक बहुत अच्छी बात है। लेकिन अब व्यवहार में, हमलावरों को हैश मान की उलटा छवि को निर्धारित करने के लिए एक क्रूर-बल के हमले का उपयोग नहीं करना होगा।



हमलावर वास्तव में इस तथ्य का फायदा उठा सकते हैं कि व्यवहार में पासवर्ड का असमान वितरण है। और असमान वितरण से मेरा मतलब है ... मान लें कि हम जानते हैं कि सभी पासवर्ड 20 वर्णों तक लंबे हैं। व्यवहार में, उपयोगकर्ता इस पूरी श्रेणी का उपयोग नहीं करते हैं, जैसे कि 123, टॉड, या कुछ इसी तरह के पासवर्ड पसंद करते हैं। हालांकि, अनुभवजन्य अध्ययन से पता चला है कि ऐसे पासवर्ड कैसे काम करते हैं, और यह पाया गया कि लगभग 20% उपयोगकर्ता 5000 सबसे लोकप्रिय पासवर्ड का उपयोग करते हैं। दूसरे शब्दों में, इसका मतलब है कि अगर किसी हमलावर के पास इन 5,000 पासवर्डों का डेटाबेस है, तो वह आसानी से उन्हें हैश कर सकता है और फिर, चोरी की गई पासवर्ड टेबल को देखने के दौरान, बस हैश से मिलान कर सकता है। तो अनुभवजन्य रूप से, एक हैकर लगभग 20% पासवर्ड को पुनर्प्राप्त करने में सक्षम होगा जो सर्वर टेबल में हैं।

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

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



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

मान लीजिए आप एक कुंजी उत्पन्न करना चाहते हैं। एक उदाहरण PBKDF2 प्रमुख पीढ़ी मानक है या, संभवतः, बीसीक्रिप्ट, आप इंटरनेट से उनके बारे में अधिक जान सकते हैं। आइए कल्पना करें कि इन प्रमुख पीढ़ी के कार्यों में से एक की गणना के लिए कुछ सेकंड नहीं बल्कि पूरे एक सेकंड की आवश्यकता होती है। वास्तव में, यह हमलावर के काम को और अधिक कठिन बना देगा, क्योंकि 5000 "शीर्ष" पासवर्ड के लिए मान उत्पन्न करने के प्रयास में अधिक समय लगेगा।

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

मैं एक बार फिर से दोहराता हूं - इंद्रधनुष तालिका बनाने के आर्थिक लाभों को अधिकतम करने के लिए, एक हमलावर पासवर्ड के असमान वितरण का लाभ उठा सकता है, जो मैंने पहले के बारे में बात की थी। इस प्रकार, एक हमलावर ऐसी तालिका का निर्माण केवल सभी संभावित पासवर्डों के कुछ छोटे सेट के लिए कर सकता है।

छात्र: शायद "नमस्कार" यह बहुत कठिन है?

प्रोफेसर: हाँ, हाँ, बिल्कुल। हम कुछ सेकंड में "नमस्कार" पर जाएंगे। सामान्य तौर पर, यदि आप नमकीन का उपयोग नहीं करते हैं, तो इंद्रधनुष तालिकाएं एक हमलावर को कुछ प्रयासों के साथ ऑफ़लाइन अनुमति देती हैं, इस तालिका की गणना करने के लिए, और फिर किए गए काम के आधार पर मूल पासवर्ड की गणना करने की क्षमता से लाभ उठाएं।

अगली बात यह है कि आप स्थिति को सुधारने के बारे में सोच सकते हैं। यह कैसे काम करता है? मूल सिद्धांत पासवर्ड पीढ़ी पद्धति में कुछ अतिरिक्त यादृच्छिकता का परिचय देना है। आप इस हैश फ़ंक्शन को लेते हैं, इसमें "नमक" डालते हैं, और फिर पासवर्ड, और यह सब सर्वर पर एक तालिका में संग्रहीत किया जाता है।



नमक क्या है? यह इस हैश फ़ंक्शन के पहले भाग का प्रतिनिधित्व करने वाली एक लंबी स्ट्रिंग है। तो इस योजना का उपयोग करना बेहतर क्यों है? ध्यान दें कि "नमक" वास्तव में सर्वर साइड पर स्पष्ट पाठ में संग्रहीत है। आप सोच सकते हैं: ठीक है, अगर यह "नमक" सर्वर साइड पर स्पष्ट पाठ में संग्रहीत है और एक हमलावर पासवर्ड के लिए उपयोगकर्ता नाम की एक मेज चुरा सकता है, तो वह इस "नमक" को भी क्यों नहीं चुरा सकता है? ऐसे समाधान का क्या उपयोग है?

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

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

श्रोता: इसे "नमक" क्यों कहा जाता है?

प्रोफेसर: यह एक अच्छा सवाल है, और मैं इसका जवाब निश्चित रूप से नहीं दे सकता। हालांकि, मुझे यकीन है कि इसके लिए कुछ औचित्य है। कुकीज़ को कुकीज़ क्यों कहा जाता है? इंटरनेट शायद जानता है कि क्यों, लेकिन मुझे पता नहीं है।

छात्र: शायद इसलिए कि "नमक" हैश में थोड़ा "स्वाद" जोड़ता है?

प्रोफेसर: ठीक है, मुझे खुशी है कि हम यह फिल्म कर रहे हैं क्योंकि हमारे पास स्पष्ट रूप से एक फिल्म पुरस्कार पाने का मौका है। मुझे यकीन है कि इंटरनेट पर किसी तरह का जवाब है, इसलिए मैं बाद में इसकी तलाश करूंगा।
तो, उपरोक्त दृष्टिकोण काफी सरल हैं। मैंने मान लिया कि उपयोगकर्ता किसी तरह सर्वर को पासवर्ड भेजता है, लेकिन यह निर्दिष्ट नहीं करता है कि यह कैसे होता है। तो हम इन पासवर्ड को कैसे पास करते हैं?

सबसे पहले, आप स्पष्ट पाठ में नेटवर्क पर पासवर्ड भेज सकते हैं। यह बुरा है क्योंकि नेटवर्क पर एक घुसपैठिया हो सकता है जो आपके द्वारा भेजे जाने वाले ट्रैफ़िक पर नज़र रखता है। वह बस एक पासवर्ड असाइन कर सकता है और आपको प्रतिरूपित कर सकता है।

इसलिए, हम हमेशा एक स्ट्रॉ आदमी से शुरू करते हैं, इससे पहले कि मैं आपको दूसरे स्ट्रॉ मैन दिखाऊं, जो निश्चित रूप से, मोटे तौर पर दोषपूर्ण भी हैं। तो पहली बात जो आप सोच सकते हैं, वह है क्लियर टेक्स्ट में पासवर्ड भेजना। सुरक्षा के दृष्टिकोण से, एक एन्क्रिप्टेड कनेक्शन के माध्यम से पासवर्ड भेजना बेहतर है, इसलिए हम क्रिप्टोग्राफी का उपयोग करते हैं। यह संभव है कि हमारे पास नेटवर्क पर भेजने से पहले पासवर्ड को बदलने के लिए किसी प्रकार की गुप्त कुंजी का उपयोग किया जाता है। तो उच्चतम स्तर पर, ऐसा लगता है कि एन्क्रिप्शन हमेशा चीजों को बेहतर करता है, जैसे ट्रेडमार्क गारंटी उत्पाद की गुणवत्ता।

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

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

वास्तव में, आप कुछ व्यक्ति को कुछ भेज रहे हैं, जिसके बाद उसे आपके सभी रहस्यों को अपने कब्जे में लेने का अवसर मिलेगा।

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

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

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



सर्वर को उत्तर पता है, इसलिए फिलहाल सर्वर इस क्रम को स्वीकार कर सकता है - ग्राहक की प्रतिक्रिया। सर्वर उस चुनौती को भी जानता है जिसे उसने भेजा था, और संभवतः पासवर्ड को जानता है, इसलिए सर्वर प्राप्त हैश के मूल्य की गणना कर सकता है और देख सकता है कि यह वास्तव में उपयोगकर्ता द्वारा भेजे गए मेल से मेल खाता है।

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

छात्र: क्या एक सर्वर पर पासवर्ड भेजने और हैशेड सर्वर कॉल प्राप्त करने के बजाय एक क्लाइंट केवल सर्वर पर एक हैशेड पासवर्ड भेज सकता है?

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



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

प्रोफेसर: बिल्कुल सच। हां, यह इस आधार पर थोड़ा खतरनाक हो जाता है कि कौन इस कॉल को अपने कब्जे में ले सकता है। क्योंकि यदि क्लाइंट और सर्वर इस सी के मूल्यों को चुन सकते हैं, तो यह क्लाइंट के ऐसे हमलों को व्यवस्थित करने की क्षमता को जटिल बनाता है। इस प्रोटोकॉल का उपयोग करने में समस्याओं में से एक यह है कि क्लाइंट इस HCC मान को यादृच्छिक करने में सक्षम नहीं है। कोई कल्पना कर सकता है कि आप इस प्रोटोकॉल को सर्वर उलटा के लिए और अधिक जटिल बना सकते हैं, यदि क्लाइंट एचसीसी भाग में कुछ सी कॉल का चयन करने में सक्षम है, लेकिन इस मामले में क्लाइंट और सर्वर कॉल का एक जूसकैप होगा।
यदि कोई और प्रश्न नहीं हैं, तो हम मान लेंगे कि हमने क्लाइंट से सर्वर तक पासवर्ड ट्रांसफर तंत्र की चर्चा समाप्त कर दी है। , , brute-force, -, .

, , , HCC. , «». « ».

, , , , « ». «» , « » .

Antihammer – , , . , , brute-force , . , Antihammer – , , : « ».



-, . , 10 , : « 10 , ». . «» , TPN . ? – , , , .
, , , - . , , - , , . – . , , .

, — , , — . , , . , . , , .

, , , Dictionary attack, « ». , , Microsoft Telepathwords. . , , , Telepathwords , . , , , , .



«», , , , , «».



«» , . Telepathwords? , , . , .



, . , , . , .

, Telepathwords , , , , , . .
, — , , , .

: , , IP- , Antihammer .

: , . Antihammer IP-, , . , Antihammer , – . , Antihammer , , , , , , .

, . , . , .

: Antihammer? , , ? , , SRP Zero Knowledge Protocol, ZKP, …

: , ?

: ?

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

27:20 मि

एमआईटी पाठ्यक्रम "कंप्यूटर सिस्टम सुरक्षा"। व्याख्यान 17: उपयोगकर्ता प्रमाणीकरण, भाग 2


पाठ्यक्रम का पूर्ण संस्करण यहां उपलब्ध है ।

हमारे साथ बने रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक दिलचस्प सामग्री देखना चाहते हैं? एक आदेश रखकर या अपने दोस्तों को इसकी अनुशंसा करके हमें समर्थन दें, एंट्री-लेवल सर्वरों के अनूठे एनालॉग पर हैबर उपयोगकर्ताओं के लिए 30% छूट जो हमने आपके लिए ईजाद की है: VPS (KVM) E5-2650 v4 (6 कोर) 10GB DDR4 240GB SSD 1Gbps से पूरा सच $ 20 या सर्वर को कैसे विभाजित करें? (विकल्प RAID1 और RAID10 के साथ उपलब्ध हैं, 24 कोर तक और 40GB DDR4 तक)।

VPS (KVM) E5-2650 v4 (6 करोड़) 10GB DDR4 240GB SSD 1Gbps दिसंबर तक मुफ्त में जब छह महीने की अवधि के लिए भुगतान करते हैं, तो आप यहां ऑर्डर कर सकते हैं ।

डेल R730xd 2 बार सस्ता? केवल हमारे पास 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 टीवी 249 डॉलर में नीदरलैंड और यूएसए से है! इन्फ्रास्ट्रक्चर Bldg का निर्माण कैसे करें के बारे में पढ़ें । एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग?