स्पष्ट टेक्स्ट पासवर्ड से सुरक्षित पासवर्ड बनाने के लिए Rfc2898DeriveBytes का उपयोग करते समय नमक का महत्व

Question

मैं अपने सी # .NET ऐप्स में से किसी एक में फ़ाइलों का एन्क्रिप्शन और डिक्रिप्शन शामिल करना चाहता हूं। परिदृश्य सरल है: उपयोगकर्ता ए उपयोगकर्ता बी को एईएस 256-एन्क्रिप्टेड फ़ाइल भेजता है। स्पष्ट टेक्स्ट पासवर्ड को एक अलग चैनल (जैसे फोन कॉल या जो कुछ भी) पर आदान-प्रदान किया जाता है।

मैं क्या समझ मैं एक अधिक सुरक्षित हो सकता है 10,000 राउंड का उपयोग कर पासवर्ड में उपयोगकर्ता का स्पष्ट पाठ पासवर्ड परिवर्तित करने के लिए Rfc2898DeriveBytes का उपयोग करना चाहिए से

। (this article देखें)।

जो मुझे समझ में नहीं आता वह मेरे परिदृश्य में नमक की भूमिका है। आम तौर पर शब्दकोश हमलों को रोकने के लिए हैशिंग पासवर्ड में नमक का उपयोग किया जाता है। लेकिन मेरे परिदृश्य में पीबीकेडीएफ 2 अल्गो का उपयोग पीबीकेडीएफ 2-राउंड द्वारा आवश्यक अतिरिक्त गणना जोड़कर स्पष्ट टेक्स्ट पासवर्ड को कम या आसान अनुमानित कमजोरियों की भरपाई करने के लिए किया जाता है।

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

मैं क्या समझ रहा लेकिन मेरी स्थिति में एक निरंतर नमक का उपयोग करें और एक अच्छा स्पष्ट पाठ पासवर्ड नियम लागू लगातार नमक की कमजोरी की भरपाई करने के लिए कोई विकल्प नहीं है से

। क्या मेरी धारणा सही है?

Answer 1

लवण, पासवर्ड हैशिंग (और कुंजी व्युत्पत्ति) के संदर्भ में, इंद्रधनुष तालिकाओं की तरह precomputation हमलों को रोकने के लिए किया जाता है।

ध्यान दें कि नमक प्रत्येक पासवर्ड के लिए अलग और अप्रत्याशित (अधिमानतः यादृच्छिक) होना चाहिए। यह भी ध्यान रखें कि लवणों को गुप्त नहीं होना चाहिए - यही पासवर्ड है। नमक को गुप्त रखकर आपको कोई सुरक्षा नहीं मिलती है।

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

क्या कोई विशिष्ट कारण है कि आप एईएस -256 का उपयोग कर रहे हैं? यह अतिरिक्त दौर के कारण एईएस-128 की तुलना में लगभग 40% धीमी है, और यह कोई व्यावहारिक सुरक्षा लाभ प्रदान नहीं करता है (विशेष रूप से पासवर्ड-आधारित एन्क्रिप्शन के मामले में नहीं)।

क्रिप्टोग्राफिक प्राइमेटिव्स से अपना स्वयं का प्रोटोकॉल बनाने के बजाय PGP जैसे एक अच्छी तरह से स्थापित मानक का उपयोग करने पर विचार करना भी उचित है, क्योंकि सुरक्षित प्रोटोकॉल बनाना इतना कठिन है कि विशेषज्ञ भी हमेशा इसे सही नहीं पाते हैं।

Answer 2

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

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