ब्लॉक सिफर एसएएलटी: स्पष्ट पाठ या रहस्य?

Question

वेब पर कई लेख और उद्धरण कह रहे हैं कि 'नमक' गुप्त रखा जाना चाहिए। Salt पर भी विकिपीडिया प्रविष्टि:

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

जब से मैं एक तथ्य यह है कि एन्क्रिप्शन नमक (या प्रारंभ वेक्टर) ठीक हैं एन्क्रिप्टेड पाठ के साथ स्पष्ट पाठ पर संग्रहीत करने के लिए, मैं पूछना चाहता हूँ क्यों यह गलत धारणा perpetuated है के लिए पता करने के लिए होता है?

मेरी राय यह है कि समस्या की उत्पत्ति एन्क्रिप्शन नमक (ब्लॉक सिफर के प्रारंभिक वेक्टर) और हैशिंग 'नमक' के बीच एक आम भ्रम है। हैश किए गए पासवर्ड संग्रहीत करने में एक गैर अभ्यास, या 'नमक' जोड़ने का एक आम अभ्यास है, और (मामूली) सच है कि यह 'नमक' बेहतर रखा जाता है। जो बदले में यह नमक नहीं बनाता है, लेकिन में गुप्त नामक बहुत स्पष्ट रूप से एक कुंजी है। यदि आप आलेख Storing Passwords - done right! पर आलेख देखते हैं जो विकिपीडिया 'नमक' प्रविष्टि से जुड़ा हुआ है, तो आप देखेंगे कि इस तरह के 'नमक', पासवर्ड हैश के बारे में बात कर रही है। मुझे इनमें से अधिकतर योजनाओं से असहमत होना पड़ता है क्योंकि मेरा मानना ​​है कि पासवर्ड संग्रहण योजना को HTTP Digest authentication के लिए भी अनुमति देनी चाहिए, इस मामले में केवल उपयोगकर्ता नाम का HA1 पाचन ही संभव संग्रहण है: दायरे: पासवर्ड, Storing password in tables and Digest authentication देखें।

यदि इस मुद्दे पर आपकी राय है, तो कृपया यहां प्रतिक्रिया के रूप में पोस्ट करें।

1. क्या आपको लगता है कि ब्लॉक सिफर एन्क्रिप्शन के लिए नमक छुपाया जाना चाहिए? समझाएं क्यों और कैसे।
2. क्या आप सहमत हैं कि कंबल कथन 'लवण छुपाया जाना चाहिए' नमकीन हैशिंग से निकलता है और एन्क्रिप्शन पर लागू नहीं होता है?
3. क्या हम चर्चा में स्ट्रीम सिफर (आरसी 4) शामिल कर सकते हैं?

Answer 1

तरह LFSR परामर्श का कहना है:

लोगों की है कि ज्यादा होशियार आप से कर रहे हैं कर रहे हैं और मुझे लगता है कि और अधिक समय बिताया है की तुलना में इस विषय के बारे में आप सोच या मैं कभी होगा।

जो कम से कम कहने का एक भारित उत्तर है। ऐसे लोग हैं जो, ईमानदार श्रेणी में मामूली रूप से, धन उपलब्ध होने पर कुछ बाधाओं को नजरअंदाज कर देंगे। वहां बहुत से लोग हैं जिनके पास आग में कोई त्वचा नहीं है और उस प्रकार के लिए सीमाएं कम कर देंगे ....

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

1. क्या आपको लगता है कि ब्लॉक सिफर एन्क्रिप्शन के लिए नमक छिपा किया जाना चाहिए? व्याख्या करें क्यों और कैसे।

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

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

वास्तव में कोई जवाब नहीं है।

2. क्या आप सहमत हैं कि कंबल स्टेटमेंट 'लवण छुपाया जाना चाहिए' नमकीन हैशिंग से निकलता है और एन्क्रिप्शन पर लागू नहीं होता है?

यह किसने कहा, कहां, और किस आधार पर दिया गया था।

3. क्या हमें चर्चा में स्ट्रीम सिफर (आरसी 4) शामिल करना चाहिए?

एक सिफर एक सिफर है - इससे क्या अंतर आएगा?

Answer 2

यदि आप ब्लॉक साइफर में चतुर्थ के बारे में बात कर रहे हैं, तो यह निश्चित रूप से स्पष्ट होना चाहिए। अधिकांश लोग गुप्त चतुर्थ का उपयोग कर अपने सिफर कमजोर बनाते हैं।

चतुर्थ प्रत्येक एन्क्रिप्शन के लिए यादृच्छिक, अलग होना चाहिए। यादृच्छिक चतुर्थ प्रबंधन करना बहुत मुश्किल है, इसलिए कुछ लोग चतुर्थ उद्देश्य का उपयोग करते हुए एक निश्चित चतुर्थ का उपयोग करते हैं।

मैं गुप्त फिक्स्ड IV का उपयोग करके एन्क्रिप्टेड पासवर्ड वाले डेटाबेस के साथ काम करता था। वही पासवर्ड हमेशा एक ही सिफरटेक्स्ट में एन्क्रिप्ट किया जाता है। यह इंद्रधनुष तालिका हमले के लिए बहुत प्रवण है।

Answer 3

क्या आपको लगता है कि ब्लॉक सिफर एन्क्रिप्शन के लिए नमक छुपाया जाना चाहिए? समझाएं कि कैसे और कैसे

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

Answer 4

प्रति रिकॉर्ड नमक का उद्देश्य हैश को पीछे हटाना बहुत कठिन है। तो यदि पासवर्ड डेटाबेस का खुलासा किया गया है तो पासवर्ड तोड़ने के लिए आवश्यक प्रयास बढ़ गया है। तो यह मानते हुए कि हमलावर जानता है कि आप पूरे डेटाबेस के लिए एक इंद्रधनुष तालिका बनाने के बजाय हैश को कैसे करते हैं, उन्हें डेटाबेस में प्रत्येक प्रविष्टि के लिए ऐसा करने की आवश्यकता होती है।

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

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

एक डेटाबेस चौड़े नमक का इलाज किया जाना चाहिए क्योंकि यह एक कुंजी थी और नमक मूल्य तक पहुंच को सामान्य रूप से संरक्षित किया जाना चाहिए। ऐसा करने का एक तरीका नमक को उन घटकों में विभाजित करना है जो विभिन्न डोमेन में प्रबंधित होते हैं। कोड में एक घटक, कॉन्फ़िगरेशन फ़ाइल में से एक, डेटाबेस में से एक। केवल चलने वाला कोड इन सभी को पढ़ने में सक्षम होना चाहिए और थोड़ा सा एक्सओआर का उपयोग करके उन्हें एक साथ जोड़ना चाहिए।

अंतिम क्षेत्र जहां कई असफल होते हैं। इन नमक मूल्यों और एल्गोरिदम को बदलने का एक तरीका होना चाहिए। यदि कोई सुरक्षा घटना होती है तो हम नमक मूल्यों को आसानी से बदल सकते हैं। डेटाबेस में नमक संस्करण फ़ील्ड होना चाहिए और कोड संस्करण का उपयोग करेगा ताकि यह पता लगाया जा सके कि कौन से लवण का उपयोग करना है और किस संयोजन में। एन्क्रिप्शन या हैश सृजन हमेशा नवीनतम नमक एल्गोरिदम का उपयोग करता है, लेकिन डीकोड सत्यापन कार्य हमेशा रिकॉर्ड में निर्दिष्ट एल्गोरिदम का उपयोग करता है। इस तरह कम प्राथमिकता वाले डेटाबेस डेटाबेस डिक्रिप्टिंग और प्रविष्टियों को फिर से एन्क्रिप्ट करने के माध्यम से पढ़ सकते हैं।

Answer 5

प्रत्येक एन्क्रिप्टेड ब्लॉक अगला ब्लॉक IV है। तो परिभाषा के अनुसार, चतुर्थ रहस्य नहीं हो सकता है। प्रत्येक ब्लॉक एक चतुर्थ है।

पहला ब्लॉक बहुत अलग नहीं है। एक हमलावर जो सादे पाठ की लंबाई जानता है उसे संकेत हो सकता है कि पहला ब्लॉक IV है।

• BLOCK1 चतुर्थ है या अच्छी तरह से ज्ञात चतुर्थ के साथ एन्क्रिप्ट किया जा सकता था
• BLOCK2 एक चतुर्थ
• रूप में # 1 ब्लॉक के साथ एन्क्रिप्टेड है ...
• ब्लॉक एन एक के रूप में ब्लॉक # N-1 के साथ एन्क्रिप्टेड है IV

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