क्रिप्टोग्राफी में हठधर्मिता के बारे में

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

इस परियोजना को समुदाय द्वारा अच्छी तरह से प्राप्त किया गया है, और कुछ समय के लिए एचएन के शीर्ष पर रहा है। प्रतिक्रिया के लिए धन्यवाद।

रिलीज के बाद, मुझे हैश फ़ंक्शन को बदलने के लिए कई अनुरोध मिले, जिसका उपयोग मैंने डेटाबेस में हैश पासवर्ड के लिए किया:

# Turn the password into an hashed one, using # SHA1(salt|password). def hash_password(password) Digest::SHA1.hexdigest(PasswordSalt+password) end 

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

आइए, अभी के लिए एक कदम वापस लें और इस सब के साथ मूल समस्या को देखें, और यह कोड कितना असुरक्षित है।

समस्या

समस्या को समझना बहुत आसान है, लेकिन मैं इसे विस्तार से समझाऊंगा। डेटाबेस में पासवर्ड को स्पष्ट में संग्रहीत नहीं करने के लिए, वे आमतौर पर हैशेड होते हैं।

 HP = HASH (password) # HP – hashed password,   

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

हालाँकि, अगर कोई हमलावर (उसे ईव कहता है) एक डेटाबेस डंप हो जाता है तो क्या होता है? ईवा में हैशेड पासवर्ड का एक सेट होगा, चलो उन्हें एचपी 1, एचपी 2, एचपी 3 कहते हैं, ... उसका लक्ष्य ऐसे हमले को खोजना है जो एचपी को वापस पी में बदल देगा।

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

लेकिन शायद हमारे उपयोगकर्ता, बॉब ने एक पासवर्ड चुना, जो शब्दकोश में नहीं पाया जा सकता है, और बहुत लंबा नहीं है।

ईव पासवर्ड के लिए सभी संयोजनों को उत्पन्न कर सकता है, कह सकता है, लंबाई में 6 अक्षर तक, और उनके हैश की गणना करें। यह हमला अधिक कम्प्यूटेशनल रूप से जटिल है। यदि पासवर्ड 6 अक्षरों का एक बाइनरी स्ट्रिंग है, तो कहें, तो कुल 256 ^ 6 संयोजन हैं, अर्थात् 281474976710656।

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

 281474976710656 / 1000000000 = 281474  

यह केवल तीन दिन है, या, औसतन, यहां तक ​​कि आधा भी। अच्छा नहीं है! यह बहुत आसान है। एक और समस्या है, उपयोगकर्ता समान संभावना वाले सभी 256 वर्णों का उपयोग करने की संभावना नहीं है। सबसे खराब स्थिति पर विचार करें, यह लोअरकेस में केवल 26 अक्षर हैं, कोई संख्या और अन्य वर्ण नहीं हैं। इस बार 8 अक्षरों का पासवर्ड लें।

26 ^ 8 संभावित पासवर्ड हैं, अर्थात् 208 827 064 576। इस समय, हमारे पासवर्ड को 208 सेकंड (या औसत पर इस बार आधा) में फटा जा सकता है।

यह निश्चित रूप से अच्छा नहीं है। एक हमलावर के लिए दुर्गम होने के लिए हमारा अल्फ़ाबेटिक पासवर्ड कब तक होना चाहिए जो एक अरब हैश की गणना प्रति सेकंड कर सकता है?

14 पात्रों का चयन औसतन 1024 वर्षों में किया जाएगा। 16 पात्रों के लिए, हमलावर को 1382824 साल बिताने होंगे। 12 वर्ण एक वर्ष और एक आधे (फिर से, औसतन) के लिए प्रतिरोध करेंगे, जो निश्चित रूप से अधिकांश अनुप्रयोगों के लिए पर्याप्त नहीं है।

तो क्या SHA1 पासवर्ड हैशिंग के लिए सुरक्षित है? हां, यदि उपयोगकर्ता ने 14 वर्णों या उससे अधिक के एक मजबूत पासवर्ड का चयन किया है। अन्यथा, बहुत सुरक्षित नहीं है। यह सब पासवर्ड की लंबाई पर निर्भर करता है, और यह कोई रहस्य नहीं है कि उपयोगकर्ताओं को छोटे और कमजोर पासवर्ड लेने की बुरी आदत है।

लेकिन यह और भी बुरा है

दुर्भाग्य से, वास्तव में, सब कुछ बदतर है। उदाहरण के लिए, एक पासवर्ड के हमारे 12 पात्रों के खिलाफ हमलों को तुरंत किया जा सकता है: आप लगभग तीन साल खर्च कर सकते हैं और सभी संयोजनों के लिए राख की गणना कर सकते हैं और उन्हें फॉर्म पी -> एचपी की तालिका में लिख सकते हैं।

हालाँकि, ऐसी तालिका में बहुत अधिक जगह होती है (86,792 टेराबाइट्स, सटीक होने के लिए), और यह यहां तक ​​माना जाता है कि हम डेटा को इतनी आसानी से संग्रहीत करते हैं कि हम पी, एचपी (एक अप्राप्य लक्ष्य) की एक जोड़ी पर केवल एक बाइट खर्च करते हैं। हालांकि, यह एक वास्तविक खतरा है जब तालिका का आकार उचित सीमा के भीतर है।

लब्बोलुआब यह है कि अक्सर क्रिप्टोग्राफी के हमलों में अधिक समय के बजाय, अधिक स्थान की कीमत पर किया जा सकता है।

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

 HP = HASH ("foolame") 

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

यादृच्छिक लवण

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

हैश फ़ंक्शन को धीमा करें

हालांकि, भले ही हम सभी टेबल-आधारित हमलों को रोकते हैं, फिर भी एक मूलभूत समस्या है: यदि पासवर्ड कम है और ईवा 1 बिलियन बार प्रति सेकंड एचएएच की गणना करने में सक्षम है, तो हमें समस्या है।

हम इस मामले में कुछ कर सकते हैं: एक हैश फ़ंक्शन का उपयोग करें जो धीमा है।

ऐसे एल्गोरिदम हैं जो सॉफ्टवेयर और हार्डवेयर दोनों की गणना में बहुत धीमी हैं। या हम एक मौजूदा एल्गोरिथ्म ले सकते हैं और इसे बहुत धीमी गति से बना सकते हैं, इसका उपयोग लूप में कर सकते हैं।

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

तथ्य यह है कि ब्लोफिश में धीमी कुंजी-साझाकरण एल्गोरिथ्म है, यह एचएएसएच के लिए एक अच्छा उम्मीदवार बनाता है।

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

हालांकि, यह एक लोकप्रिय विकल्प है, प्रोवोस और माज़िएरेस दो प्रसिद्ध क्रिप्टोग्राफ़र हैं, इसलिए एल्गोरिथ्म में संभवतः कोई स्पष्ट विकल्प नहीं हैं।

जैसे ही हम धीमी गति से हैश फ़ंक्शन का उपयोग करना शुरू करते हैं, हमलावर को समस्याएं शुरू होती हैं। इसलिए, उदाहरण के लिए, Bcrypt को कॉन्फ़िगर किया जा सकता है, जिससे यह तेज या धीमा हो सकता है। यदि आप इसे इतना धीमा कर देते हैं कि अच्छे हार्डवेयर के साथ भी आप प्रति सेकंड एक हजार से अधिक हैश की गणना नहीं कर सकते हैं, तो यह संभवतः आपके उपयोगकर्ताओं के लिए स्वीकार्य होगा, लेकिन यह ईव के लिए पहले से ही अव्यवहारिक है। उदाहरण के लिए, केवल निचले अक्षरों का उपयोग करते हुए 8 वर्णों का एक पासवर्ड:

 26 ^ 8 / 1000 / 3600 / 24 / 365 = 6,6218627782 

8 वर्णों के पासवर्ड को क्रैक करने के लिए 3.3 वर्ष (औसत)। शायद अभी भी पर्याप्त सुरक्षा नहीं है, लेकिन सिर्फ सेकंड से बेहतर है।

हालाँकि, ध्यान दें कि हम अभी भी शब्दकोश के हमलों से सुरक्षित नहीं हैं । यदि उपयोगकर्ता ने एक सामान्य शब्द चुना है, तो सब कुछ निराशाजनक है। 30k हैश की गणना अभी भी उचित मात्रा में की जा सकती है।

हठधर्मिता के बारे में

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

यह समझना महत्वपूर्ण है कि चीजें कैसे काम करती हैं। यह सुचारू रूप से हमें अगले विचार तक ले जाता है। "उपयोग bcrypt" कोरस के बाद, मैंने उत्तर दिया कि मैं SHA1 पुनरावृत्ति पर आधारित एक और समाधान का उपयोग कर सकता हूं। लेकिन, जाहिरा तौर पर, कई लोग मानते हैं कि एक प्रोग्रामर को क्रिप्टोग्राफी को नहीं समझना चाहिए। उसे इसे एक हठधर्मिता के रूप में देखना चाहिए। यदि आपके पास हठधर्मिता है, तो आप एक गरीब प्रोग्रामर होंगे, सबसे अधिक संभावना है। क्या होगा यदि आपके सिस्टम में bcrypt सपोर्ट नहीं है, लेकिन आपको इस पर काम करने की आवश्यकता है। मैंने एक तुच्छ योजना का सुझाव दिया:

 SHA1 (SHA1 (SHA1 (...( SHA1 (password | salt)))) 

क्या एक विधर्म! मुझे यह नहीं समझने के लिए एक मूर्ख माना जाता था कि यह इस तरह से चेन हैश फ़ंक्शन के लिए असुरक्षित है, और इसी तरह। लेकिन अगर आप थोड़ा सोचें तो क्या होगा?

SHA1 एक हैश फ़ंक्शन है। इसमें राउंड्स नामक छोटे चरण होते हैं, जिन्हें बार-बार किया जाता है। कोई कुंजी पृथक्करण नहीं है, क्योंकि यह एक ब्लॉक सिफर नहीं है, यह फ़ंक्शन बस इनपुट बिटस्ट्रीम को एक निश्चित लंबाई के आउटपुट मूल्य में संपीड़ित करता है।

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

तो क्यों न केवल बहुत सारे दौर जोड़ दिए जाएं? यह धीमा है। यहां तक ​​कि एक शौकिया क्रिप्टोग्राफर एक एल्गोरिथ्म विकसित कर सकता है जो सुरक्षित और धीमा है। एक अच्छा क्रिप्टोग्राफर सुरक्षा और गति के बीच एक समझौता पा सकता है।

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

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

ध्यान दें कि SHA1 (SHA1 (..) का परिणाम SHA1 के अंदर अधिक राउंड को जोड़ने के समान नहीं है, क्योंकि इसमें प्री- और पोस्ट-प्रोसेसिंग भी है।

और आपको पता है क्या? आज सुबह मुझे पता चला कि RFC2898 में वर्णित PBKDF1 एल्गोरिथ्म वही करता है जो मैंने सुझाया था।

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

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

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