hash इंद्रधनुष तालिका हमले के खिलाफ पासवर्ड नमक कैसे मदद करता है?




cryptography salt (8)

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

मैंने कई ट्यूटोरियल देखे हैं जो सुझाव देते हैं कि नमक को निम्न के रूप में उपयोग किया जाना चाहिए:

$hash =  md5($salt.$password)

तर्क यह है कि हैश अब मूल पासवर्ड पर नहीं है, बल्कि पासवर्ड और नमक का संयोजन है। लेकिन $salt=foo और $password=bar और $hash=3858f62230ac3c915f300c664312c63f । अब इंद्रधनुष तालिका वाला कोई व्यक्ति हैश को उलट सकता है और इनपुट "foobar" के साथ आ सकता है। फिर वे पासवर्ड के सभी संयोजनों (एफ, फू, फू, ... ओबार, ओबर, बार, आरआर, आरआर) का प्रयास कर सकते थे। पासवर्ड प्राप्त करने में कुछ और मिलीसेकंड लग सकते हैं, लेकिन बहुत कुछ नहीं।

मैंने देखा है कि अन्य उपयोग मेरे लिनक्स सिस्टम पर है। / Etc / छाया में हैश किए गए पासवर्ड वास्तव में नमक के साथ संग्रहीत होते हैं। उदाहरण के लिए, "फू" का नमक और "बार" का पासवर्ड इस पर हैश: $1$foo$te5SBM.7C25fFDu6bIRbX1 । यदि कोई हैकर किसी भी तरह से इस फ़ाइल पर अपना हाथ पाने में सक्षम था, तो मुझे नहीं लगता कि नमक किस उद्देश्य का काम करता है, क्योंकि te5SBM.7C25fFDu6bIRbX के रिवर्स हैश को "foo" रखने के लिए जाना जाता है।

किसी भी प्रकाश के लिए धन्यवाद कोई भी इस पर शेड कर सकते हैं।

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


फिर भी एक और महान सवाल, कई विचारशील उत्तरों के साथ - एसओ +1!

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

यह महत्वपूर्ण क्यों है?

उत्तर पश्चिमी अमेरिका में एक बड़ी सॉफ्टवेयर कंपनी में पासवर्ड डेटाबेस की कल्पना करो। मान लें कि इसमें 30,000 प्रविष्टियां हैं, जिनमें से 500 में पासवर्ड ब्लूस्क्रीन है । मान लीजिए कि एक हैकर इस पासवर्ड को प्राप्त करने का प्रबंधन करता है, इसे उपयोगकर्ता से आईटी विभाग में ईमेल में पढ़कर कहें। यदि पासवर्ड अनसाल्टेड हैं, तो हैकर डेटाबेस में हैश वैल्यू पा सकता है, फिर अन्य 49 9 खातों तक पहुंच प्राप्त करने के लिए बस पैटर्न-मिलान करें।

पासवर्ड को सब्सक्राइब करना सुनिश्चित करता है कि 500 ​​खातों में से प्रत्येक के पास अद्वितीय (नमक + पासवर्ड) होता है, जिसमें से प्रत्येक के लिए एक अलग हैश उत्पन्न होता है, और इस प्रकार एक खाते में उल्लंघन को कम करता है। और आइए आशा करते हैं कि, सभी संभावनाओं के मुताबिक, किसी भी उपयोगकर्ता को ईमेल संदेश में सादे टेक्स्ट पासवर्ड लिखने के लिए पर्याप्त जानकारी नहीं है, उसके पास अगले ओएस के लिए अनियंत्रित एपीआई तक पहुंच नहीं है।


नमकीन का एक उद्देश्य प्रीकंप्यूटेड हैश टेबल को हराने के लिए है। अगर किसी के पास लाखों पूर्व-गणना वाले हैंश की सूची है, तो वे अपने टेबल में $ 1 $ foo $ te5SBM.7C25fFDu6bIRbX1 को देखने में सक्षम नहीं होंगे, भले ही वे हैश और नमक को जानते हों। उन्हें अभी भी बलपूर्वक बल देना होगा।

एक और उद्देश्य, जैसा कि कार्ल एस का उल्लेख है, हैश की सूची को अधिक महंगा बनाने के लिए ब्रूट बनाना है। (उन्हें सभी अलग लवण दें)

लवण सार्वजनिक होने पर भी इन दोनों उद्देश्यों को पूरा किया जाता है।


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

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

पहले को समझने के लिए, एक पासवर्ड फ़ाइल की कल्पना करें जिसमें सैकड़ों उपयोगकर्ता नाम और पासवर्ड शामिल हैं। नमक के बिना, मैं "md5 (प्रयास [0])" की गणना कर सकता हूं, और तब फ़ाइल को स्कैन कर सकता हूं यह देखने के लिए कि क्या हैश कहीं भी दिखाई देता है या नहीं। यदि लवण मौजूद हैं, तो मुझे "एमडी 5 (नमक [ए]। प्रयास [0]) की गणना करना है," एंट्री ए के खिलाफ तुलना करें, फिर "एमडी 5 (नमक [बी]। प्रयास [0])", एंट्री बी के खिलाफ तुलना करें , आदि। अब मेरे पास n गुना अधिक काम है, जहां n फ़ाइल में निहित उपयोगकर्ता नाम और पासवर्ड की संख्या है।

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

लेकिन अगर पासवर्ड फ़ाइल को नमकीन किया जाता है, तो इंद्रधनुष तालिका में "नमक पासवर्ड" पूर्व-धोया जाना होगा। अगर नमक पर्याप्त रूप से यादृच्छिक है, तो यह बहुत ही असंभव है। मेरे पास आमतौर पर इस्तेमाल होने वाले, प्री-हैश किए गए पासवर्ड (इंद्रधनुष तालिका) की मेरी सूची में "हैलो" और "फूबार" और "क्वर्टी" जैसी चीजें होंगी, लेकिन मेरे पास "jX95psDZhello" जैसी चीजें नहीं हैं I "LPgB0sdgxfoobar" या "dZVUABJtqwerty" पूर्व-गणना की गई। इससे इंद्रधनुष तालिका निषिद्ध रूप से बड़ी होगी।

इसलिए, नमक हमलावर को एक-गणना-प्रति-पंक्ति-प्रति-प्रयास में वापस कर देता है, जो, जब पर्याप्त रूप से लंबे, पर्याप्त यादृच्छिक पासवर्ड के साथ मिलकर होता है, तो (आमतौर पर बोलना) अचूक होता है।


मैं लवण लागू करने के लिए एक अच्छी विधि खोज रहा था और नमूना कोड के साथ यह उत्कृष्ट लेख पाया:

http://crackstation.net/hashing-security.htm

लेखक प्रति उपयोगकर्ता यादृच्छिक लवण का उपयोग करने की सिफारिश करता है, ताकि नमक तक पहुंच प्राप्त करने से हैश की पूरी सूची क्रैक करने में आसान न हो।

पासवर्ड स्टोर करने के लिए:

  • एक सीएसपीआरएनजी का उपयोग कर एक लंबे यादृच्छिक नमक उत्पन्न करें।
  • नमक को पासवर्ड में तैयार करें और इसे मानक क्रिप्टोग्राफ़िक हैश फ़ंक्शन जैसे SHA256 के साथ हैश करें।
  • उपयोगकर्ता के डेटाबेस रिकॉर्ड में नमक और हैश दोनों को बचाएं।

पासवर्ड सत्यापित करने के लिए:

  • डेटाबेस से उपयोगकर्ता के नमक और हैश को पुनः प्राप्त करें।
  • नमक को दिए गए पासवर्ड पर तैयार करें और हैश फ़ंक्शन का उपयोग करके इसे हश करें।
  • डेटाबेस से हैश के साथ दिए गए पासवर्ड के हैश की तुलना करें। यदि वे मेल खाते हैं, तो पासवर्ड सही है। अन्यथा, पासवर्ड गलत है।

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

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


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

इस तरह के हमले ऐसे मामले में अप्रभावी होते हैं जहां पासवर्ड में कई और वर्ण होते हैं और आम शब्द आधारित प्रारूपों के अनुरूप नहीं होते हैं। एक उपयोगकर्ता के साथ शुरू करने के लिए एक मजबूत पासवर्ड के साथ हमले की इस शैली के लिए कमजोर नहीं होगा। दुर्भाग्य से, बहुत से लोग अच्छे पासवर्ड नहीं चुनते हैं। लेकिन एक समझौता है, आप इसे यादृच्छिक जंक जोड़कर उपयोगकर्ता के पासवर्ड में सुधार कर सकते हैं। तो अब, "शिकारी 2" के बजाय उनका पासवर्ड प्रभावी ढंग से "शिकारी 2908! Fld2R75 {R7 /; 508PEzoz ^ U430" बन सकता है, जो एक बहुत मजबूत पासवर्ड है। हालांकि, क्योंकि अब आपको यह अतिरिक्त पासवर्ड घटक स्टोर करना है, इससे मजबूत समग्र पासवर्ड की प्रभावशीलता कम हो जाती है। जैसा कि यह पता चला है, अभी भी इस तरह की एक योजना के लिए शुद्ध लाभ है क्योंकि अब प्रत्येक पासवर्ड, यहां तक ​​कि कमजोर वाले, अब भी पूर्व-गणना वाले हैश / इंद्रधनुष तालिका के लिए कमजोर नहीं हैं। इसके बजाए, प्रत्येक पासवर्ड हैश प्रविष्टि केवल एक अद्वितीय हैश तालिका के लिए कमजोर है।

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

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

जो वास्तव में स्थिति है। आप कभी भी उपयोगकर्ताओं को खराब पासवर्ड पसंद से पूरी तरह से सुरक्षित नहीं कर सकते हैं, लेकिन आप अपने उपयोगकर्ताओं के पासवर्ड को उस स्तर पर समझौता करने की लागत बढ़ा सकते हैं जो एक उपयोगकर्ता के पासवर्ड को भी महंगा रूप से महंगा बना देता है।


जहां तक ​​मुझे पता है, नमक का उद्देश्य शब्दकोश हमलों को कठिन बनाना है।

यह एक ज्ञात तथ्य है कि कई लोग प्रतीत होता है कि यादृच्छिक तारों के बजाए पासवर्ड के लिए सामान्य शब्दों का उपयोग किया जाएगा।

तो, एक हैकर केवल ब्रूट फोर्स का उपयोग करने के बजाय इसका लाभ उठा सकता है। वह aaa, aab, aac जैसे पासवर्ड नहीं देख पाएंगे ... लेकिन इसके बजाय शब्दों और सामान्य पासवर्ड का उपयोग करें (जैसे अंगूठे के नाम के भगवान!;))

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

उम्मीद है की वो मदद करदे!


अन्य उत्तरों विषय की आपकी गलतफहमी को संबोधित नहीं करते हैं, इसलिए यहां जाता है:

नमक के दो अलग-अलग उपयोग

मैंने कई ट्यूटोरियल देखे हैं जो सुझाव देते हैं कि नमक को निम्न के रूप में उपयोग किया जाना चाहिए:

$hash = md5($salt.$password)

[...]

मैंने देखा है कि अन्य उपयोग मेरे लिनक्स सिस्टम पर है। / Etc / छाया में हैश किए गए पासवर्ड वास्तव में नमक के साथ संग्रहीत होते हैं।

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

हैश की सुरक्षा

अब इंद्रधनुष तालिका वाला कोई व्यक्ति हैश को उलट सकता है और इनपुट "foobar" के साथ आ सकता है।

[...]

चूंकि te5SBM.7C25fFDu6bIRbX के रिवर्स हैश को "foo" रखने के लिए जाना जाता है।

हैश को इस तरह से (सिद्धांत में, कम से कम) को उलटना संभव नहीं है। "Foo" के हैश और "saltfoo" के हैश में कुछ भी सामान्य नहीं है। एक क्रिप्टोग्राफिक हैश फ़ंक्शन के इनपुट में भी एक बिट को बदलने से आउटपुट को पूरी तरह बदलना चाहिए।

इसका मतलब है कि आप सामान्य पासवर्ड के साथ इंद्रधनुष तालिका नहीं बना सकते हैं और बाद में इसे कुछ नमक के साथ "अपडेट" कर सकते हैं। आपको नमक को शुरुआत से खाते में लेना होगा।

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

नमक की गुणवत्ता

लेकिन $salt=foo कहो

"फू" नमक की बेहद खराब पसंद होगी। आम तौर पर आप ASCII में एन्कोड किए गए यादृच्छिक मान का उपयोग करेंगे।

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

आक्रमण

यदि कोई हैकर किसी भी तरह से इस फाइल पर अपना हाथ पाने में सक्षम था, तो मुझे नहीं लगता कि नमक किस उद्देश्य परोसता है,

इंद्रधनुष तालिका हमले की हमेशा आवश्यकता होती है /etc/passwd (या जो भी पासवर्ड डेटाबेस उपयोग किया जाता है), या फिर आप इंद्रधनुष तालिका में हैंश की तुलना वास्तविक पासवर्ड के हैंश से कैसे करेंगे?

उद्देश्य के लिए: मान लीजिए कि हमलावर 100,000 आम तौर पर इस्तेमाल किए जाने वाले अंग्रेजी शब्दों और सामान्य पासवर्ड ("गुप्त" सोचें) के लिए इंद्रधनुष तालिका बनाना चाहता है। नमक के बिना उसे 100,000 हैश का प्रीकंप्यूट करना होगा। पारंपरिक यूनिक्स के 2 अक्षरों के नमक के साथ भी (प्रत्येक 64 विकल्पों में से एक है: [a–zA–Z0–9./] ) उसे 4,096,000,000 हैश की गणना और स्टोर करना होगा ... काफी सुधार।





rainbowtable