security नमक पीढ़ी और मुक्त स्रोत सॉफ्टवेयर




open-source encryption (5)

चूंकि हैशिंग नमक के बारे में प्रश्न काफी नियमित आधार पर आते हैं और इस विषय के बारे में काफी भ्रम लगता है, इसलिए मैंने यह जवाब बढ़ाया।


नमक क्या है?

एक नमक एक निश्चित लंबाई के बाइट्स का एक यादृच्छिक सेट है जो हैश एल्गोरिदम के इनपुट में जोड़ा जाता है।


एक हैश को सलाम (या बीजिंग) क्यों उपयोगी है?

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

  1. नमक से पहले प्रीकंप्यूटेड हमलों की कठिनाई / लागत बढ़ जाती है ( इंद्रधनुष सारणी सहित)
  2. नमस्कार सुनिश्चित करता है कि एक ही पासवर्ड के परिणामस्वरूप एक ही हैश नहीं है। यह सुनिश्चित करता है कि आप यह निर्धारित नहीं कर सकते कि दो उपयोगकर्ताओं के पास एक ही पासवर्ड है या नहीं। और, इससे भी महत्वपूर्ण बात यह है कि आप यह निर्धारित नहीं कर सकते कि एक ही व्यक्ति अलग-अलग प्रणालियों में एक ही पासवर्ड का उपयोग करता है या नहीं।
  3. नमस्कार पासवर्ड की जटिलता को बढ़ाता है, जिससे दोनों शब्दकोशों की प्रभावशीलता में कमी आती है- और जन्मदिन के हमले (यह केवल तभी सच है जब नमक हैश से अलग रखा जाता है)।
  4. उचित नमक प्रीकंपुटेशन हमलों के लिए भंडारण की आवश्यकता को बहुत बढ़ा देता है, उस बिंदु तक जहां वे अब व्यावहारिक नहीं हैं। (8 बिट केस-सेंसिटिव अल्फा-न्यूमेरिक पासवर्ड 16 बिट नमक के साथ, 128 बिट मान के लिए धोया गया है, इंद्रधनुष में कमी के बिना केवल 200 exabytes ले जाएगा)।


नमक को गुप्त होने की कोई आवश्यकता नहीं है।

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

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


तो, नमक को यादृच्छिक क्यों होना चाहिए?

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

यह कुछ डेटा से नमक प्राप्त करने का प्रयास कर रहा है जो "संभवतः अद्वितीय" है, जैसे उपयोगकर्ता आईडी, लेकिन ऐसी योजनाएं अक्सर कुछ ग़लत विवरणों के कारण विफल होती हैं:

  1. यदि आप उदाहरण के लिए उपयोग करते हैं , तो उपयोगकर्ता आईडी , कुछ बुरे लोग, अलग-अलग सिस्टम पर हमला कर सकते हैं, बस अपने संसाधनों को पूल कर सकते हैं और उपयोगकर्ता आईडी 1 से 50 के लिए प्रीकंप्यूटेड टेबल बना सकते हैं। उपयोगकर्ता आईडी अद्वितीय प्रणाली-व्यापी है लेकिन दुनिया भर में नहीं है

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

  3. विशिष्टता भी अस्थायी है। कभी-कभी, उपयोगकर्ता अपना पासवर्ड बदलते हैं। प्रत्येक नए पासवर्ड के लिए , एक नया नमक चुना जाना चाहिए। अन्यथा, एक हमलावर ने पुराने पासवर्ड के हैश को प्राप्त किया और नए के हैश एक साथ दोनों पर हमला करने का प्रयास कर सकते थे।

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


निष्कर्ष के तौर पर:

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

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


उपयोगी स्रोत:
stackoverflow.com: पासवर्ड हैश के लिए गैर यादृच्छिक नमक
ब्रूस श्नीयर: प्रैक्टिकल क्रिप्टोग्राफी (पुस्तक)
Matasano सुरक्षा: इंद्रधनुष टेबल्स के साथ पर्याप्त है
usenix.org: यूनिक्स क्रिप्ट 1 9 76 से नमक का इस्तेमाल किया
owasp.org : नमक क्यों जोड़ें
openwall.com : Salts

अस्वीकरण:
मैं एक सुरक्षा विशेषज्ञ नहीं हूँ। (हालांकि इस उत्तर की समीक्षा थॉमस पोर्निन ने की थी)
अगर वहां से किसी भी सुरक्षा पेशेवर को कुछ गलत लगता है, तो कृपया टिप्पणी करें या इस विकी उत्तर को संपादित करें।

जैसा कि मैं इसे समझता हूं, लवण पैदा करने के लिए सबसे अच्छा अभ्यास अपने स्रोत कोड में संग्रहीत कुछ गुप्त सूत्र (या यहां तक ​​कि जादू निरंतर) का उपयोग करना है।

मैं एक परियोजना पर काम कर रहा हूं जिसे हम ओपन सोर्स के रूप में रिलीज करने की योजना बना रहे हैं, लेकिन समस्या यह है कि स्रोत के साथ नमक पैदा करने के लिए गुप्त सूत्र आता है, और इसलिए हमारी साइट पर इंद्रधनुष तालिका हमलों को चलाने की क्षमता है।

मुझे लगता है कि बहुत से लोगों ने मेरे सामने इस समस्या पर विचार किया है, और मैं सोच रहा हूं कि सबसे अच्छा अभ्यास क्या है। ऐसा लगता है कि अगर कोड खुला स्रोत है तो नमक होने का कोई मतलब नहीं है, क्योंकि नमक आसानी से विपरीत-इंजीनियर हो सकते हैं।

विचार?


एक डेस्कटॉप एप्लिकेशन के मामले में जो डेटा को एन्क्रिप्ट करता है और इसे रिमोट सर्वर पर भेजता है, तो आप हर बार एक अलग नमक का उपयोग करने पर विचार कैसे करते हैं?

उपयोगकर्ता के पासवर्ड के साथ पीकेसीएस # 5 का उपयोग करके, डेटा को एन्क्रिप्ट करने के लिए इसे एन्क्रिप्शन कुंजी उत्पन्न करने के लिए नमक की आवश्यकता होती है। मुझे पता है कि डेस्कटॉप एप्लिकेशन में नमक हार्डकोडेड (obfuscated) रखना एक अच्छा विचार नहीं है।

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


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


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

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


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

मुझे पसंद है कि django-पंजीकरण में नमक कैसे उत्पन्न होता है। संदर्भ: http://bitbucket.org/ubernostrum/django-registration/src/tip/registration/models.py#cl-85

salt = sha_constructor(str(random.random())).hexdigest()[:5]
activation_key = sha_constructor(salt+user.username).hexdigest()
return self.create(user=user,
           activation_key=activation_key)

वह एक यादृच्छिक संख्या और उपयोगकर्ता नाम हैश उत्पन्न करने के लिए उत्पन्न शा के संयोजन का उपयोग करता है।

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





rainbowtable