encryption - अलग-अलग फाइलों के लिए पासवर्ड सुरक्षा कैसे कार्यान्वित करें?




cryptography passwords (4)

कुंजी जनरेशन

मैं आपके पासवर्ड से एक कुंजी उत्पन्न करने के लिए पीकेसीएस # 5 संस्करण 2.0 में परिभाषित पीबीकेडीएफ 2 जैसे एक मान्यता प्राप्त एल्गोरिदम का उपयोग करने की अनुशंसा करता हूं। यह आपके द्वारा रूपरेखा वाले एल्गोरिदम के समान है, लेकिन एईएस के उपयोग के लिए लंबी सममित कुंजी बनाने में सक्षम है। आपको एक ओपन-सोर्स लाइब्रेरी ढूंढने में सक्षम होना चाहिए जो विभिन्न एल्गोरिदम के लिए पीबीई कुंजी जेनरेटर लागू करता है।

फाइल प्रारूप

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

पासवर्ड सत्यापन

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

वैकल्पिक रूप से, आप सामग्री पर एक मैक की गणना कर सकते हैं। एक पासवर्ड पर एक हैश टकराव एक हमलावर के लिए उपयोगी होने की संभावना है; सामग्री पर एक हैश टकराव बेकार होने की संभावना है। लेकिन यह एक वैध प्राप्तकर्ता को यह जानने के लिए काम करेगा कि गलत पासवर्ड का इस्तेमाल डिक्रिप्शन के लिए किया गया था।

क्रिप्टोग्राफिक नमक

Salt पूर्व-गणना शब्दकोश हमलों को विफल करने में मदद करता है।

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

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

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

मैं एक छोटा डेस्कटॉप ऐप लिख रहा हूं जो डेटा फ़ाइल एन्क्रिप्ट करने और पासवर्ड से बचाने में सक्षम होना चाहिए (यानी किसी को डिक्रिप्ट करने के लिए सही पासवर्ड दर्ज करना होगा)। मैं एन्क्रिप्टेड डेटा फ़ाइल को स्वयं निहित और पोर्टेबल होना चाहता हूं, इसलिए फ़ाइल में प्रमाणीकरण को एम्बेड किया जाना चाहिए (या तो मुझे लगता है)।

मेरे पास एक रणनीति है जो व्यावहारिक प्रतीत होती है और जो मुझे पता है (जो शायद खतरनाक होने के लिए पर्याप्त है) के आधार पर तार्किक लगता है, लेकिन मुझे नहीं पता कि यह वास्तव में एक अच्छा डिजाइन है या नहीं। तो मुझे बताओ: क्या यह पागल है? क्या ऐसा करने का कोई बेहतर / सर्वोत्तम तरीका है?

  • चरण 1: उपयोगकर्ता सादे-पाठ पासवर्ड में प्रवेश करता है, उदाहरण के लिए "MyDif HardPassword"
  • चरण 2: ऐप उपयोगकर्ता-पासवर्ड को हश करता है और उस फ़ाइल का उपयोग डेटा फ़ाइल को एन्क्रिप्ट / डिक्रिप्ट करने के लिए सममित कुंजी के रूप में करता है। उदाहरण के लिए "MyDif HardPassword" -> "HashedUserPwdAndKey"।
  • चरण 3: ऐप चरण 2 से हैश मान रखता है और डेटा फ़ाइल शीर्षलेख (यानी डेटा फ़ाइल का अनएन्क्रिप्टेड भाग) में नया मान सहेजता है और उपयोगकर्ता के पासवर्ड को सत्यापित करने के लिए उस मान का उपयोग करता है। उदाहरण के लिए "HashedUserPwdAndKey" -> "HashedValueForAuthentication"

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

तो क्या यह डिज़ाइन उचित रूप से सुरक्षित है, या निराशाजनक रूप से बेवकूफ़ है, या कहीं बीच में है? धन्यवाद!

संपादित करें: स्पष्टीकरण और अनुवर्ती प्रश्न फिर से: नमक।
मैंने सोचा था कि नमक को उपयोगी होने के लिए गुप्त रखा जाना चाहिए था, लेकिन आपके उत्तरों और लिंक का मतलब यह नहीं है। उदाहरण के लिए, एरिक्सन (नीचे) द्वारा लिंक किया गया यह स्पेस कहता है:

इस प्रकार, यहां परिभाषित पासवर्ड-आधारित कुंजी व्युत्पन्न पासवर्ड, नमक और एक पुनरावृत्ति गणना का एक कार्य है, जहां बाद की दो मात्राओं को गुप्त नहीं रखा जाना चाहिए।

क्या इसका मतलब यह है कि मैं नमक मूल्य को उसी स्थान / फ़ाइल में रखी हुई कुंजी के रूप में स्टोर कर सकता हूं और अभी भी अधिक सुरक्षित हो सकता है अगर मैंने हैशिंग के दौरान नमक का उपयोग नहीं किया? वह कैसे काम करता है?

थोड़ा और संदर्भ: एन्क्रिप्टेड फ़ाइल को दूसरों द्वारा साझा या डिक्रिप्ट करने के लिए नहीं है, यह वास्तव में एकल-उपयोगकर्ता डेटा है। लेकिन मैं उन कंप्यूटरों पर साझा वातावरण में इसे तैनात करना चाहता हूं, जिन्हें मैं पूरी तरह से नियंत्रित नहीं करता (उदाहरण के लिए) और फ़ाइल को कॉपी करके डेटा माइग्रेट / स्थानांतरित करने में सक्षम हो (इसलिए मैं इसे घर पर अलग-अलग उपयोग कर सकता हूं वर्कस्टेशन, आदि)।


एक संपीड़न लाइब्रेरी का उपयोग क्यों न करें जो पासवर्ड-सुरक्षित फ़ाइलों का समर्थन करता है? मैंने एक पासवर्ड-सुरक्षित ज़िप फ़ाइल का उपयोग किया है जिसमें अतीत में XML सामग्री है:}


जैसा कि नियाज ने कहा, यदि आप मजबूत एल्गोरिदम के गुणवत्ता कार्यान्वयन का उपयोग करते हैं, तो SHA-265 और AES जैसे हैशिंग और एन्क्रिप्शन के लिए दृष्टिकोण उचित लगता है। इसके अतिरिक्त मैं सभी पासवर्ड हैंश का शब्दकोश बनाने की संभावना को कम करने के लिए Salt का उपयोग करने की सलाह दूंगा।

बेशक, ब्रूस श्नीयर की एप्लाइड क्रिप्टोग्राफी पढ़ना कभी भी गलत नहीं होता है।


यदि आप एक मजबूत हैश एल्गोरिदम (SHA-2) और एक मजबूत एन्क्रिप्शन एल्गोरिदम (एईएस) का उपयोग कर रहे हैं, तो आप इस दृष्टिकोण के साथ ठीक काम करेंगे।





passwords