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




cryptography passwords (4)

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

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

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

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

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

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

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

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

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

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


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

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


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


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

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





passwords