security - एक हैश के लिए नमक छिपाने की आवश्यकता




encryption hash (7)

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

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

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

संपादित करें: ठीक है तो यही कारण है कि मुझे लगता है कि यह वास्तव में नमक को एन्क्रिप्ट करने के लिए प्रेरित है। (lemme पता है कि मैं सही रास्ते पर हूँ)।

निम्नलिखित स्पष्टीकरण के लिए, हम मान लेंगे कि पासवर्ड हमेशा 8 अक्षर होते हैं और नमक 5 होता है और सभी पासवर्ड में लोअरकेस अक्षर होते हैं (यह केवल गणित को आसान बनाता है)।

प्रत्येक प्रविष्टि के लिए एक अलग नमक होने का मतलब है कि मैं एक ही इंद्रधनुष तालिका का उपयोग नहीं कर सकता (वास्तव में तकनीकी रूप से मैं कर सकता था अगर मेरे पास पर्याप्त आकार में से एक था, लेकिन चलिए इस पल के लिए अनदेखा करते हैं)। नमक के लिए यह वास्तविक कुंजी है जो मैं समझता हूं, क्योंकि प्रत्येक खाते को क्रैक करने के लिए मुझे प्रत्येक के लिए बोलने के लिए पहिया को फिर से शुरू करना होता है। अब अगर मुझे पता है कि हैश उत्पन्न करने के लिए पासवर्ड में सही नमक कैसे लागू किया जाए, तो मैं ऐसा करूँगा क्योंकि नमक वास्तव में हैश वाक्यांश की लंबाई / जटिलता को बढ़ाता है। तो मैं संभावित संयोजनों की संख्या काट रहा हूं जिन्हें मुझे "पता" करने के लिए उत्पन्न करने की आवश्यकता होगी मेरे पास पासवर्ड है + 13 ^ 26 से 8 ^ 26 तक नमक क्योंकि मुझे पता है कि नमक क्या है। अब यह आसान बनाता है, लेकिन अभी भी वास्तव में कठिन है।

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

यहां एक लिंक है जो बताता है कि ब्रूट फोर्स अटैक के तहत कितने पासवर्ड होंगे: http://www.lockdown.co.uk/?pg=combi


... हैश को नमक करने के लिए उपयोगकर्ता नाम या फोन नंबर की तरह कुछ। ...

मेरा सवाल यह है कि यदि दूसरा दृष्टिकोण वास्तव में जरूरी है? मैं पूरी तरह सैद्धांतिक परिप्रेक्ष्य से समझ सकता हूं कि यह पहले दृष्टिकोण की तुलना में अधिक सुरक्षित है, लेकिन व्यावहारिक दृष्टिकोण से क्या है?

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

क्या प्रत्येक खाते में एक फोन नंबर की आवश्यकता को रोकना सुनिश्चित करने के लिए एक पूर्ण सुरक्षा समीक्षा शामिल करने की आवश्यकता है ताकि आप यह सुनिश्चित कर सकें कि आपने उन खातों को सुरक्षा समझौता नहीं किया है?


"नमक" की मेरी समझ यह है कि यह क्रैकिंग को और अधिक कठिन बनाता है, लेकिन यह अतिरिक्त डेटा को छिपाने की कोशिश नहीं करता है। यदि आप नमक "गुप्त" बनाकर अधिक सुरक्षा पाने की कोशिश कर रहे हैं, तो आप वास्तव में बस अपनी एन्क्रिप्शन कुंजी में अधिक बिट्स चाहते हैं।


एक छुपा नमक अब नमक नहीं है। यह काली मिर्च है। इसका उपयोग है। यह नमक से अलग है।

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

मिर्च के बारे में अधिक जानकारी के लिए, here जांचें।

hmac भी देखें।


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

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


मैं नमक छिपाने के लिए जाते हैं। मैं इसे याद करने से पहले पासवर्ड की शुरुआत से 1 से 1024 तक यादृच्छिक संख्या तैयार करके नमक के 10 बिट का उपयोग करता हूं। उपयोगकर्ता को हैश के साथ दर्ज किया गया पासवर्ड की तुलना करते समय, मैं 1 से 1024 तक लूप करता हूं और जब तक मुझे मैच नहीं मिल जाता तब तक नमक के हर संभव मूल्य को आज़माएं। यह एक सेकंड के 1/10 से कम लेता है। मुझे PHP password_hash और password_verify से इस तरह से ऐसा करने का विचार मिला। मेरे उदाहरण में, "लागत" 10 बिट नमक के लिए 10 है। या किसी अन्य उपयोगकर्ता ने कहा, छुपा "नमक" को "काली मिर्च" कहा जाता है। नमक डेटाबेस में एन्क्रिप्ट नहीं किया गया है। यह ब्रूट मजबूर हो गया है। यह इशारा 1000 गुना बड़ा करने के लिए आवश्यक इंद्रधनुष तालिका बना देगा। मैं sha256 का उपयोग करता हूं क्योंकि यह तेज़ है, लेकिन अभी भी सुरक्षित माना जाता है।


यहां एक साधारण उदाहरण दिखाया गया है कि प्रत्येक हैश के लिए एक ही नमक क्यों खराब है

निम्नलिखित तालिका पर विचार करें

UserId  UserName,   Password
     1  Fred       Hash1 =  Sha(Salt1+Password1)    
     2  Ted        Hash2 =  Sha(Salt2+Password2)    

प्रकरण 1 जब नमक 1 नमक 2 जैसा ही होता है यदि हैश 2 को हैश 1 के साथ प्रतिस्थापित किया गया है तो उपयोगकर्ता 2 उपयोगकर्ता 1 पासवर्ड से लॉगऑन कर सकता है

केस 2 जब नमक 1 एक ही नमक नहीं 2 यदि हैश 2 को हैश 1 के साथ प्रतिस्थापित किया गया है तो उपयोगकर्ता 2 उपयोगकर्ता 1 पासवर्ड के साथ लॉगऑन नहीं कर सकता है।


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







brute-force