security - हैश के साथ नमक स्टोर करना ठीक है?




hash salt (5)

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

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

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

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

मेरा सवाल है, क्या यह स्वीकार्य है? नमक को सीधे पासवर्ड से सुरक्षित रखने के साथ जुड़े कोई अतिरिक्त जोखिम है? ऐसा लगता है कि स्रोत कोड में नमक भंडारण अलग नहीं है, इसलिए पासवर्ड के साथ नमक भंडारण करके कोई सुरक्षा हानि नहीं है।

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


आपका दूसरा समाधान "प्रति पासवर्ड संग्रहीत नमक है" सही है और आमतौर पर उपयोग किया जाता है।

"नमक" मुख्य रूप से यह पता लगाने में मुश्किल होता है कि दो उपयोगकर्ताओं के पास एक ही पासवर्ड होता है - इसलिए आप पासवर्ड में एक ज्ञात "नमक" मिश्रण करते हैं। नमक पासवर्ड चेक समय पर gettable होने की जरूरत है।

तो आम तौर पर या तो आप एक यादृच्छिक नमक उत्पन्न करते हैं और इसे पासवर्ड से स्टोर करते हैं या आप नमक के रूप में कुछ अन्य पहचानकर्ता (उपयोगकर्ता आईडी, उपयोगकर्ता नाम आदि) का उपयोग करते हैं।


आपके पास वास्तव में उपयोगकर्ता तालिका में संग्रहीत नमक मान है: तालिका की पाकी।

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

यह एक करीबी डीपी wtb है: पासवर्ड हैशिंग, नमक और धोया मूल्यों का भंडारण


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


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

याद रखें: प्रत्येक क्रिप्टोग्राफिक एल्गोरिदम टूटने योग्य है। सुरक्षा को तोड़ने पर (इंद्रधनुष तालिका या अन्यथा के माध्यम से) जानकारी को अधिक महंगा माना जाता है, तो जानकारी केवल "सुरक्षित" माना जा सकता है।

संपादित करें:

मान लीजिए कि आप क्रिप्टोग्राफी के लिए बहुत नए हैं, यहां कुछ और सुझाव दिए गए हैं:

  • लंबे समय से लवण लवण बेहतर होते हैं।
  • एक नमक के लिए अधिक संभव मूल्य, बेहतर। एक अल्फा-न्यूमेरिक नमक एक संख्यात्मक से बेहतर है। एक बाइनरी नमक अल्फा-न्यूमेरिक से बेहतर होता है।
  • नमक एक ही पासवर्ड के खिलाफ ब्रूट-फोर्स हमले कम संभावना नहीं बनाते हैं।

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

नमक का बिंदु पूरी तरह से यह सुनिश्चित करने के लिए है कि आप पूरे डेटाबेस या यहां तक ​​कि कई डेटाबेस में एक ब्रूट फोर्स हमले की लागत को कम नहीं कर सकते हैं।

पहला सॉफ़्टवेयर के हर नए संस्करण के साथ नमक को बदलना है, लेकिन यह अच्छा नहीं है क्योंकि सॉफ़्टवेयर के नए संस्करण पुराने पासवर्ड हैंश के खिलाफ परीक्षण करने में सक्षम नहीं होंगे।

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





salt