2012-09-21 6 views
6

मैं Rfc2898DeriveBytes का उपयोग कर रहा हूं ताकि उपयोगकर्ता द्वारा आपूर्ति किए गए स्ट्रिंग पासवर्ड से एन्क्रिप्शन कुंजी और प्रारंभिक वेक्टर उत्पन्न हो सके, सममित एन्क्रिप्शन (उदा। एस्मानेड) के साथ उपयोग करने के लिए।पासवर्ड स्ट्रिंग से एन्क्रिप्शन कुंजी और IV प्राप्त करते समय नमक के रूप में पासवर्ड के SHA1 हैश का उपयोग करना ठीक है?

मैं Rfc2898DeriveBytes पर नमक पैरामीटर के रूप में पासवर्ड का SHA1 हैश ले रहा हूं। क्या वह ठीक है? यदि नहीं, तो मुझे नमक कहाँ से मिलना चाहिए? डिक्रिप्ट करते समय मुझे उसी नमक की आवश्यकता होगी, है ना? इसलिए मुझे इसे कहीं भी अनएन्क्रिप्टेड स्टोर करना है - असुरक्षित। अगर मुझे इसे सुरक्षित रूप से स्टोर करना है, तो यह सिर्फ एक और "पासवर्ड" बन जाता है, है ना?

void SecureDeriveKeyAndIvFromPassword(string password, int iterations, 
    int keySize, int ivSize, out byte[] key, out byte[] iv) 
{ 
    // Generate the salt from password: 

    byte[] salt = (new SHA1Managed()).ComputeHash(Encoding.UTF8.GetBytes(password)); 

    // Derive key and IV bytes from password: 

    Rfc2898DeriveBytes derivedBytes = new Rfc2898DeriveBytes(password, salt, iterations); 

    key = derivedBytes.GetBytes(keySize); 
    iv = derivedBytes.GetBytes(ivSize); 
} 

मैंने निरंतर (हार्ड-कोडित) नमक का उपयोग करके देखा है, और मैंने लोगों को इसके बारे में शिकायत देखी है। मैंने सोचा कि पासवर्ड से नमक निकालना बेहतर विचार होगा, लेकिन मुझे यकीन नहीं है कि यह एक इष्टतम समाधान है।

संक्षेप में, मेरे पास एक फ़ाइल है जिसे एन्क्रिप्ट किया जाना चाहिए, और उपयोगकर्ता द्वारा पासवर्ड स्ट्रिंग इनपुट होना चाहिए। सुरक्षित एन्क्रिप्शन कुंजी और IV प्राप्त करने के लिए मैं Rfc2898DeriveBytes का सही तरीके से उपयोग कैसे करूं?

धन्यवाद।

संपादित करें:

अपने जवाब के लिए धन्यवाद। अब मैं समझता हूं कि नमक का मुख्य (शायद केवल?) उद्देश्य इंद्रधनुष सारणी की पीढ़ी को असंभव बनाना है - आप "पी @ $$ w0rd" के हैश को पूर्व-उत्पन्न नहीं कर सकते हैं क्योंकि प्रत्येक के लिए यह एक अलग हैश होगा नमक मूल्य मैं इसे पूरी तरह से समझता हूं, लेकिन ... क्या यह वास्तव में सममित एन्क्रिप्शन के लिए प्रासंगिक है? मैं कहीं भी हैश को स्टोर नहीं कर रहा हूं? तो अगर हमलावर के पास सभी संभावित पासवर्ड संयोजनों के लिए इंद्रधनुष तालिका है, तो वह ज्यादा नहीं कर सकता है, है ना?

तो, मेरे सवाल है: वहाँ, प्रत्येक सुरक्षित करने का कार्यवाही में यादृच्छिक नमक का उपयोग कर उपयोग की तुलना का कोई विशेष लाभ है पासवर्ड व्युत्पन्न (या हार्ड-कोडेड) नमक, जब सममित एन्क्रिप्शन एल्गोरिदम के साथ प्रयोग किया है (जैसे .NET का प्रबंधन किया गया है)?

+0

पासवर्ड के केवल हैश-मूल्य को स्टोर करना बेहतर है। एन्क्रिप्टेड पासवर्ड के विपरीत, हैश-वैल्यू को उलट नहीं किया जा सकता है, भले ही हमलावर आपके कोड को नियंत्रित करता है और कुंजी जानता है। तो आप पासवर्ड क्यों एन्क्रिप्ट करेंगे (पीबीकेडीएफ 2 एन्क्रिप्शन नहीं है, यह हैशिंग है)? – martinstoeckli

+0

@martinstoeckli, मैं पासवर्ड एन्क्रिप्ट नहीं कर रहा हूं, न ही मैं कहीं भी अपने हैश को संग्रहीत कर रहा हूं। मैं सिर्फ स्ट्रिंग पासवर्ड से एन्क्रिप्शन कुंजी (और iv) प्राप्त करता हूं और उसके बाद पेलोड एन्क्रिप्ट करता हूं। –

+0

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

उत्तर

8

एक नमक प्रत्येक पासवर्ड के लिए अद्वितीय होना चाहिए, जिसका अर्थ है कि हर पासवर्ड के लिए एक यादृच्छिक पासवर्ड बनाएं जिसे आप हैश करना चाहते हैं। नमक एक रहस्य नहीं है और आपके गणना किए गए हैश-मूल्य के साथ सादा पाठ संग्रहीत किया जा सकता है।

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

MSDN में एक उदाहरण है जहां नमक ऑपरेटिंग सिस्टम के यादृच्छिक स्रोत से प्राप्त हुआ है। सुरक्षित नमक पाने के लिए यह सबसे अच्छा है, इसे अपने पासवर्ड से न डालें।

3

मुझे नहीं पता कि Rfc2898DeriveBytes क्या है लेकिन मैं आपको निम्नलिखित बता सकता हूं: नमक को सुरक्षित नहीं किया जाना चाहिए। अब, आपने कहा है कि आपने लोगों को कठोर कोडित, नमक के निरंतर मूल्यों के बारे में शिकायत की है, और जो भी कहता है वह सही है। नमक एक यादृच्छिक मूल्य होना चाहिए, कभी भी स्थिर नहीं होना चाहिए, अन्यथा इसका उद्देश्य पराजित हो जाता है।

क्या आप समझते हैं कि नमक का उपयोग किस लिए किया जाता है? आप स्पष्ट रूप से नहीं करते हैं। नमक के रूप में हैश का उपयोग करना एक बुरा विचार है क्योंकि पासवर्ड एक्स हमेशा उसी उद्देश्य वाई के साथ नमक किया जाएगा, फिर से, इसके उद्देश्य को हराया जाएगा।

+1

आरएफसी 28 9 8 को पासवर्ड आधारित कुंजी व्युत्पन्न समारोह 2 या पीबीकेडीएफ 2 के रूप में भी जाना जाता है। – akton

+0

@akton धन्यवाद। हालांकि, TX_ की समस्या यह नहीं समझ रही है कि नमक किसके लिए काम करता है। –

+0

मैं बस मदद करना चाहता था जब मैंने कहा "मैं वास्तव में नहीं जानता कि आरएफसी 28 9 8 डेरिवेट्स क्या है"। मैं सादे पाठ या संदेश से प्राप्त लवण के बारे में आपकी टिप्पणी से सहमत हूं। – akton

3

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

  • हर बार जब आप पासवर्ड
  • पासवर्ड जांचों के बीच में परिवर्तन नहीं करता है
  • प्रत्येक (या सबसे) पासवर्ड गणना के लिए अलग जाँच उपलब्ध है:

    नमक मूल्य का एक अच्छा विकल्प है कि है

एक उपयोगकर्ता नाम तब एक सभ्य विकल्प होगा, बशर्ते यह परिवर्तित न हो। या, जब आप पहली बार उपयोगकर्ता बनाते हैं और नमक के रूप में स्टोर करते हैं, तो अपने डेटाबेस में उपयोगकर्ता डेटा के साथ एक पूरी तरह यादृच्छिक मान उत्पन्न करें।

4

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

ऐसी स्थितियां हैं जहां बहु-लक्षित हमले लागू होते हैं, लेकिन इंद्रधनुष तालिकाएं नहीं होती हैं।

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

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

0

अन्य पहले से ही नमक के उद्देश्य को समझाते हैं, और यह सार्वजनिक जानकारी क्यों हो सकती है।

अपने प्रश्न के उत्तर का एक अतिरिक्त हिस्सा: पासवर्ड से नमक प्राप्त करें। यह प्रोग्रामिंग गलती के समान ही होगा जो एशले मैडिसन हैक के बाद लाखों पासवर्ड उजागर करता है।

समस्या यह है कि जब आप नमक उत्पन्न करने के लिए पासवर्ड का उपयोग करते हैं, तो आप अनिवार्य रूप से पासवर्ड को दूसरे में उपलब्ध कराते हैं, और बहुत आसान-टू-क्रैक, फॉर्म। हमलावर पूरी तरह से पीबीकेडीएफ 2 के आउटपुट को अनदेखा कर सकता है, और केवल नमक को उलट देता है। यह केवल SHA1 के साथ संरक्षित है, जो पहले से ही टूटा हुआ है।

एशले मैडिसन में, त्रुटि समान थी। पासवर्ड को bcrypt का उपयोग करके मुख्य डेटाबेस में संग्रहीत किया गया था, और सुरक्षित माना जाता था। लेकिन फिर किसी ने पाया कि कई खातों के पासवर्ड वास्तव में दो बार संग्रहीत किए गए थे, और दूसरी प्रति केवल एमडी 5 के साथ संरक्षित थी।

संबंधित मुद्दे