मैं इस पर थोड़ा अलग ले जाऊंगा।
मैं नमक-पासवर्ड हैश के साथ मिश्रित नमक को हमेशा स्टोर करता हूं।
उदाहरण के लिए, मैं पासवर्ड के नमकीन-हैश से पहले नमक का पहला आधा और पासवर्ड के नमकीन-हैश के बाद नमक के अंतिम भाग को रखूंगा। आवेदन इस डिजाइन के बारे में पता है, इसलिए इस डेटा को प्राप्त कर सकते हैं, और नमक और नमकीन पासवर्ड हैश प्राप्त कर सकते हैं।
इस दृष्टिकोण के लिए मेरे तर्क:
पासवर्ड/हैश डेटा के साथ छेड़छाड़ की और एक हमलावर के हाथों में गिर जाता है है, तो हमलावर पता नहीं होगा क्या नमक आंकड़ों को देखने से है। इस तरह एक हमलावर हश से मेल खाने वाले पासवर्ड को प्राप्त करने के लिए व्यावहारिक रूप से एक ब्रूट-फोर्स हमला नहीं कर सकता है, क्योंकि वह हैश को शुरू करने के बारे में नहीं जानता है और यह जानने का कोई तरीका नहीं है कि डेटा के कौन से हिस्से नमक के हिस्सों हैं, या नमकीन पासवर्ड हैश के हिस्सों (जब तक कि वह आपके एप्लिकेशन के प्रमाणीकरण तर्क) को नहीं जानता है।
यदि नमकीन पासवर्ड हैश को संग्रहीत किया जाता है, तो पासवर्ड प्राप्त करने के लिए एक क्रूर-बल हमला किया जा सकता है, जब नमकीन और धोया हुआ नमक-पासवर्ड हैश के समान डेटा उत्पन्न करता है।
हालांकि, उदाहरण के लिए, यहां तक कि अगर नमकीन पासवर्ड हैश को संग्रहीत किया गया था, लेकिन एक यादृच्छिक बाइट के साथ प्री-पेंड किया गया है, तब तक हमलावर इस बात से अनजान है कि इस पहले बाइट को त्याग दिया जाना है, यह होगा हमले की कठिनाई में भी वृद्धि। आपके उपयोगकर्ता को प्रमाणीकृत करने के लिए उपयोग किए जाने पर आपके एप्लिकेशन को डेटा के पहले बाइट को त्यागना होगा।
निष्कर्ष यह करने के लिए ..
1) कभी डेटा है कि आपके प्रमाणीकरण आवेदन यह सटीक रूप है में उपयोग करता है की दुकान।
2) यदि संभव हो, तो अतिरिक्त सुरक्षा के लिए अपना प्रमाणीकरण तर्क रहस्य रखें।
जाओ एक कदम आगे ..
आप अपने आवेदन के प्रमाणीकरण तर्क गुप्त नहीं रख सकते हैं - बहुत से लोग जानते हैं कि कैसे अपने डेटा डेटाबेस में संग्रहित है। और मान लीजिए कि आपने नमकीन-पासवर्ड हैश को नमक के साथ मिश्रित करने का फैसला किया है, नमक के कुछ नमक तैयार किए गए नमक के साथ, और शेष नमक इसे जोड़ते हैं।
यादृच्छिक नमक पैदा करते समय, आप यादृच्छिक रूप से तय कर सकते हैं कि नमक के पासवर्ड के पहले/बाद में आपके नमक का अनुपात क्या होगा।
उदाहरण के लिए, आप 512 बाइट्स का यादृच्छिक नमक उत्पन्न करते हैं। आप नमक को अपने पासवर्ड में जोड़ते हैं, और अपने नमकीन पासवर्ड के SHA-512 हैश प्राप्त करते हैं। आप एक यादृच्छिक पूर्णांक 200 भी उत्पन्न करते हैं। फिर आप नमक के पहले 200 बाइट्स को स्टोर करते हैं, इसके बाद नमकीन पासवर्ड हैश, इसके बाद नमक के शेष भाग होते हैं।
उपयोगकर्ता के पासवर्ड इनपुट को प्रमाणित करते समय, आपका आवेदन स्ट्रिंग से गुज़र जाएगा, और मान लें कि डेटा के पहले 1 बाइट नमक के पहले 1 बाइट है, इसके बाद नमकीन-हैश। यह पास असफल हो जाएगा। आवेदन नमक के पहले 2 बाइट्स के रूप में डेटा के पहले 2 बाइट्स का उपयोग करके जारी रहेगा, और नमक के पहले 200 बाइट्स के रूप में पहले 200 बाइट्स का उपयोग करने के बाद सकारात्मक परिणाम मिलने तक दोहराया जाएगा। यदि पासवर्ड गलत है, तो एप्लिकेशन सभी क्रमिक प्रयासों को तब तक जारी रखेगा जब तक कि कोई भी नहीं मिला।
इस दृष्टिकोण का पेशेवरों:
बढ़ाई गई सुरक्षा - भले ही आपका प्रमाणीकरण तर्क में जाना जाता है, सटीक तर्क संकलन समय पर अज्ञात है। सटीक तर्क के ज्ञान के साथ भी एक क्रूर बल हमले करने के लिए व्यावहारिक रूप से असंभव है। नमक की बढ़ी हुई लंबाई सुरक्षा को आगे बढ़ाएगी।
इस दृष्टिकोण का विपक्ष:
के बाद से सटीक तर्क रन-टाइम में मान लिया जाता है, इस दृष्टिकोण बहुत CPU- सघन है। नमक की लंबी अवधि, अधिक सीपीयू-गहन इस दृष्टिकोण बन जाता है।
गलत पासवर्ड प्रमाणीकरण में उच्चतम CPU लागत शामिल होगी। यह वैध अनुरोधों के प्रति प्रतिकूल हो सकता है, लेकिन हमलावरों के खिलाफ सुरक्षा बढ़ जाती है।
इस दृष्टिकोण को विभिन्न तरीकों से कार्यान्वित किया जा सकता है, और परिवर्तनीय-चौड़ाई नमक और/या नमकीन-पासवर्ड हैंश का उपयोग करके और भी अधिक सुरक्षित किया जा सकता है।
यदि कोई ऐसा स्थान है जहां आप उस नमक को स्टोर कर सकते हैं जिसे हमलावर नहीं मिल सकता है, तो आपको बस पासवर्ड भी स्टोर करना चाहिए। लेकिन हर पासवर्ड के लिए एक अलग नमक का उपयोग क्यों नहीं करते? – jrockway
वह हर पासवर्ड, जॉकवे के लिए एक अलग नमक का उपयोग कर रहा है। – Amber
आपके लवण कितने बड़े हैं? आपके लवण पर्याप्त बड़े (32 बिट्स) होना चाहिए कि व्यावहारिक रूप से कोई मौका नहीं है कि इसके लिए इंद्रधनुष तालिका का प्रीकंप्यूटेड किया गया है। –