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

Question

मान लीजिए कि आप डीबीएमएस में कितने पासवर्ड को संग्रहीत करना चाहते हैं, यह तय करने की स्वतंत्रता थी। क्या इस तरह की योजना में स्पष्ट कमजोरियां हैं?

डीबीएमएस में संग्रहीत हैश मान बनाने के लिए, ले:

• एक मूल्य है कि नमक के हिस्से के रूप डीबीएमएस सर्वर उदाहरण के लिए अद्वितीय है,
• और के एक दूसरे हिस्से के रूप में उपयोगकर्ता नाम नमक,
• और वास्तविक पासवर्ड के साथ नमक के संयोजन बनाने के लिए,
• और SHA-256 कलन विधि का उपयोग पूरी स्ट्रिंग हैश,
• और डीबीएमएस में परिणाम की दुकान।

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

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

क्या पासवर्ड पहले और उपयोगकर्ता नाम और 'अद्वितीय मूल्य' दूसरा, या डेटा के तीन स्रोतों के किसी अन्य क्रमपरिवर्तन के लिए कोई फायदा होगा? या तारों को interleaving के बारे में क्या?

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

काफी सवाल अतः संबंधित का एक बहुत - इस सूची व्यापक होने की संभावना नहीं है:

• Encrypting/Hashing plain text passwords in database
• Secure hash and salt for PHP passwords
• The necessity of hiding the salt for a hash
• Clients-side MD5 hash with time salt
• Simple password encryption
• Salt generation and Open Source software
• Password hashes: fixed-length binary fields or single string field?

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

Answer 1

नमक को केवल यादृच्छिक और अद्वितीय होना चाहिए। इसे स्वतंत्र रूप से जाना जा सकता है क्योंकि यह हमलावर की मदद नहीं करता है। कई सिस्टम डेटाबेस में सादा पाठ नमक को हैशर्ड पासवर्ड के बगल में कॉलम में संग्रहीत करेंगे।

नमक यह सुनिश्चित करने में मदद करता है कि यदि दो लोग (उपयोगकर्ता ए और उपयोगकर्ता बी) एक ही पासवर्ड साझा करते हैं तो यह स्पष्ट नहीं है। प्रत्येक पासवर्ड के लिए यादृच्छिक और अद्वितीय नमक के बिना हैश मान समान होंगे और स्पष्ट रूप से यदि उपयोगकर्ता ए के लिए पासवर्ड क्रैक किया गया है तो उपयोगकर्ता बी के पास एक ही पासवर्ड होना चाहिए।

यह उन हमलों से बचाने में भी मदद करता है जहां ज्ञात पासवर्ड के विरुद्ध हैश का एक शब्दकोश मिलान किया जा सकता है। जैसे इंद्रधनुष टेबल।

भी "वर्क फैक्टर" के साथ एक एल्गोरिदम का उपयोग करने का अर्थ यह भी है कि कम्प्यूटेशनल पावर काम को बढ़ाता है क्योंकि हैश बनाने के लिए एल्गोरिदम को भी जाना पड़ सकता है। उदाहरण के लिए, bcrypt। इसका मतलब है कि ब्रूट फोर्स हमलों के अर्थशास्त्र अस्थिर हो जाते हैं। संभवतः ज्ञात हैश की सारणी बनाना मुश्किल हो जाता है क्योंकि उन्हें बनाने में अधिक समय लगता है; "कार्य कारक" में भिन्नता का अर्थ यह होगा कि अधिक तालिकाओं का निर्माण करना होगा।

Answer 2

पासवर्ड में यादृच्छिक नमक क्यों न जोड़ें और संयोजन हैश। इसके बाद हैश और नमक को एक बाइट [] में संयोजित करें और डीबी में स्टोर करें?

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

Answer 3

मुझे लगता है कि आप समस्या को अधिक जटिल बना रहे हैं।

समस्या से प्रारंभ:

1. आप कमजोर पासवर्ड की रक्षा करने की कोशिश कर रहे हैं?
2. क्या आप इंद्रधनुष के हमलों के खिलाफ कम करने की कोशिश कर रहे हैं?

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

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

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

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

Answer 4

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