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