एमडी 5 हैश नमक - नमक

Question

हाय स्टोर करने के लिए हाय मेरे पास MD5 हैश/नमक के बारे में कोई प्रश्न है।

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

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

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

क्या यह एक अच्छा समाधान है? नमक अभी भी अद्वितीय होगा, लेकिन सभी नमक एक ही अनुक्रम के साथ समाप्त हो जाएंगे।

Answer 1

एक हमलावर नमक जानने के लिए "अनुमत" है - आपकी सुरक्षा को इस तरीके से डिजाइन किया जाना चाहिए कि नमक के ज्ञान के साथ भी यह अभी भी सुरक्षित है।

नमक क्या करता है?

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

कैसे आप MD5 का उपयोग यह MD5 के बाद से एक कमजोरी नहीं रह गया है के रूप में देखा जाता है पर निर्भर करता है "cryptogtaphically सुरक्षित"

आप सुरक्षा को मजबूत करने के लिए आगे
आप हैश कई गणना कर सकते हैं चाहते हैं कई बार (हैश हैश इत्यादि) - इससे आपको बहुत अधिक लागत नहीं होती है, लेकिन यह एक क्रूर-बल हमले/गणना "इंद्रधनुष-टेबल" को और भी महंगा बनाता है ... कृपया स्वयं का आविष्कार न करें - सिद्ध मानक तरीके हैं ऐसा करने के लिए, उदाहरण के लिए देखें http://en.wikipedia.org/wiki/PBKDF2 और http://www.itnewb.com/tutorial/Encrypting-Passwords-with-PHP-for-Storage-Using-the-RSA-PBKDF2-Standard और http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx

ऐसे तंत्र का उपयोग करते हुए इन दिनों है अनिवार्य के बाद से "CPU/GPU समय" (इंद्रधनुष टेबल/जानवर बल आदि की तरह के हमलों के लिए प्रयोग करने योग्य) अधिक से अधिक व्यापक रूप से उपलब्ध हो रही है (वास्तव उदाहरण के लिए देखें कि अमेज़न के क्लाउड सेवा दुनिया भर में सबसे तेज़ सुपरमोटर्स के शीर्ष 50 में से एक है और किसी भी व्यक्ति द्वारा तुलनात्मक रूप से छोटी राशि के लिए उपयोग किया जा सकता है)!

नमक को 2 टुकड़ों में विभाजित करना, एक हार्डकोड/स्थिर और एक अद्वितीय भाग की अनुशंसा नहीं की जाती है!

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

कोई समस्या नहीं सब पर एक हमलावर अपना पूरा नमक पता करने के लिए यदि आप सुरक्षा के सही ढंग से लागू करने के लिए नहीं है ... (के रूप में टिप्पणी प्रति)

अद्यतन:

RFC 2898 is an important reference on PBKDF2। खंड 4.1 में यह नमक

नमक डेटा कि स्पष्ट रूप से विभिन्न कार्यों और अलग कुंजी लंबाई

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

इसके विपरीत ओपी क्या पूछ रहा है मूल रूप से डीबी में नमक का केवल एक हिस्सा भंडारित करता है जबकि अन्य (छोटे) भाग को एप्लिकेशन में हार्डकोड किया जाता है जिसका मतलब है कि डीबी में नमक पूरा नहीं होता है ... कर रहा है (कम से कम किसी भी एल्गोरिथ्म के लिए इस नमक की एन्ट्रापी खोने का मतलब है जो बदले में सुरक्षा नमक प्रदान करता है कमजोर की ओर जाता है (यानी एक 8 बिट स्थिर होने के साथ 64-बिट नमक वास्तव में केवल के रूप में एक 56 बिट नमक के रूप में सुरक्षित है) मैं यह कर सकते हैं अभी सोचो) ... यह विरोध करता है कि ओपी क्या चाहता है (बढ़ती सुरक्षा)।

अद्यतन 2 (प्रति owlstead के साथ चर्चा के रूप में):

आप एक अद्वितीय और यादृच्छिक नमक का उपयोग कर PBKDF2 साथ hashing से पहले प्लेन टेक्स्ट के लिए कुछ "गुप्त" (जो अपने आवेदन में hardcoded जा सकता है) जोड़ सकते हैं जो पूरी तरह से डीबी में संग्रहित है ... कि एक सा मदद कर सकता है, हालांकि यह IMO अंधकार द्वारा सुरक्षा के लिए खातों।