security - लवण शब्दकोश हमलों को 'असंभव' क्यों बनाते हैं?




hash salt (8)

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

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

उदाहरण: 64-बिट नमक (यानी 8 बाइट्स) के साथ आपको अपने शब्दकोश हमले में 2 64 अतिरिक्त पासवर्ड संयोजनों की जांच करने की आवश्यकता है। एक शब्दकोष के साथ 200,000 शब्द हैं जो आपको करना होगा

200,000 * 2 64 = 3.6 9 * 10 24

सबसे खराब मामले में परीक्षण - नमक के बिना 200,000 परीक्षणों की बजाय।

नमक का उपयोग करने का एक अतिरिक्त लाभ यह है कि एक हमलावर अपने शब्दकोश से पासवर्ड हैश की पूर्व-गणना नहीं कर सकता है। यह बस बहुत अधिक समय और / या जगह ले जाएगा।

अद्यतन करें

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

अद्यतन 2

सामान्य रूप से अपने पासवर्ड हैश को सुरक्षित करने के मामले पर एक अच्छा पठन (मूल प्रश्न से परे जा रहा है लेकिन अभी भी दिलचस्प है):

इंद्रधनुष सारणी के साथ पर्याप्त: आपको सुरक्षित पासवर्ड योजनाओं के बारे में क्या पता होना चाहिए

लेख का अनुशासन: bcrypt (Blowfish पर आधारित) या Eksblowfish के साथ बनाई गई नमकीन हैंश का उपयोग करें जो आपको धीमी गति से धीमा बनाने के लिए कॉन्फ़िगर करने योग्य सेटअप समय का उपयोग करने की अनुमति देता है।

संभावित डुप्लिकेट:
पासवर्ड नमक समझने में कुछ मदद की ज़रूरत है

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

मैं प्रक्रिया को समझता हूं, और अपनी कुछ परियोजनाओं में इसे स्वयं लागू करता हूं।

s =  random salt
storedPassword = sha1(password + s)

आपके द्वारा संग्रहीत डेटाबेस में:

username | hashed_password | salt

मैंने देखा है कि नमक के हर कार्यान्वयन या तो पासवर्ड के अंत में नमक जोड़ता है, या शुरू होता है:

hashed_Password = sha1(s + password )
hashed_Password = sha1(password + s)

इसके बाद, एक हैकर से एक शब्दकोश हमला जो उसके नमक (हे हा) के लायक है, ऊपर सूचीबद्ध सामान्य संयोजनों में संग्रहित नमक के खिलाफ प्रत्येक कीवर्ड को चलाएगा।

निश्चित रूप से ऊपर वर्णित कार्यान्वयन वास्तव में अंतर्निहित मुद्दे को हल किए बिना हैकर के लिए एक और कदम जोड़ता है? इस मुद्दे के आसपास कदम उठाने के लिए क्या विकल्प हैं, या क्या मैं समस्या को गलत समझ रहा हूं?

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

मुझे एक उदाहरण दें कि मैं एक हैकर का प्रस्ताव कैसे करता हूं, उपयोगकर्ता डेटाबेस को पासवर्ड और हैश की सूची के साथ हैक करता है:

हमारे हैक किए गए डेटाबेस से डेटा:

RawPassword (not stored)  |  Hashed   |     Salt
--------------------------------------------------------
letmein                       WEFLS...       WEFOJFOFO...

सामान्य पासवर्ड शब्दकोश:

   Common Password
   --------------
   letmein
   12345
   ...

प्रत्येक उपयोगकर्ता रिकॉर्ड के लिए, सामान्य पासवर्ड लूप करें और उन्हें हैश करें:

for each user in hacked_DB

    salt = users_salt
    hashed_pw = users_hashed_password

    for each common_password

        testhash = sha1(common_password + salt)
        if testhash = hashed_pw then
           //Match!  Users password = common_password
           //Lets visit the webpage and login now.
        end if

    next

next

मुझे उम्मीद है कि यह मेरे बिंदु को बहुत बेहतर दिखाता है।

10,000 आम पासवर्ड और 10,000 उपयोगकर्ता रिकॉर्ड दिए गए, हमें जितना संभव हो उतने उपयोगकर्ता पासवर्ड खोजने के लिए 100,000,000 हैंश की गणना करने की आवश्यकता होगी। इसमें कुछ घंटे लग सकते हैं, लेकिन यह वास्तव में एक मुद्दा नहीं है।

क्रैकिंग थ्योरी पर अपडेट करें

हम मान लेंगे कि हम एक भ्रष्ट वेबहोस्ट हैं, जिनके पास एसएलए 1 हैश और लवण के डेटाबेस तक पहुंच है, साथ ही उन्हें जोड़ने के लिए आपके एल्गोरिदम के साथ। डेटाबेस में 10,000 उपयोगकर्ता रिकॉर्ड हैं।

यह साइट GPU का उपयोग करके प्रति सेकंड 2,300,000,000 SHA1 हैश की गणना करने में सक्षम होने का दावा करती है। (असली दुनिया की स्थिति में शायद धीमा हो जाएगा, लेकिन अभी के लिए हम उस उद्धृत आंकड़े का उपयोग करेंगे)।

(((95 ^ 4) / 2300000000) / 2) * 10000 = 177 सेकेंड

95 प्रिंट करने योग्य ASCII वर्णों की पूरी श्रृंखला को देखते हुए, अधिकतम 4 वर्णों की लंबाई के साथ, गणना (परिवर्तनीय) की दर से विभाजित, 2 से विभाजित (मानने के लिए औसत समय को क्रमशः 50% क्रमपरिवर्तन की आवश्यकता होती है) 10,000 के लिए उपयोगकर्ता सभी उपयोगकर्ताओं के पासवर्ड को काम करने के लिए 177 सेकंड लेते हैं जहां लंबाई <= 4 है।

आइए इसे यथार्थवाद के लिए थोड़ा सा समायोजित करें।

(((36 ^ 7) / 1000000000) / 2) * 10000 = 2 दिन

पासवर्ड की लंबाई <= 7, केवल अल्फान्यूमेरिक वर्णों के साथ गैर केस संवेदनशीलता मानते हुए, 10,000 उपयोगकर्ता रिकॉर्ड के लिए हल करने में 4 दिन लगेंगे, और मैंने ओवरहेड और गैर आदर्श परिस्थिति को प्रतिबिंबित करने के लिए एल्गोरिदम की गति को कम कर दिया है।

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

इस कार्य को अधिक संगणकीय रूप से महंगा बनाने के लिए 1000 बार बार-बार पासवर्ड दर्ज करने के मामले को देखते हुए:

(((36 ^ 7) / 1 000 000 000) / 2) * 1000 सेकंड = 10.8839117 घंटे

यह एक उपयोगकर्ता के उद्धृत आंकड़े से आधा गति निष्पादन से कम, 7 अल्फा-न्यूमेरिक वर्णों की अधिकतम लंबाई का प्रतिनिधित्व करता है।

रिक्त रूप से 1,000 बार प्रभावी ढंग से एक कंबल हमले को अवरुद्ध कर देता है, लेकिन उपयोगकर्ता डेटा पर लक्षित हमले अभी भी कमजोर हैं।


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

तो आइए कहें कि हम एसएचए 1 के साथ काम कर रहे हैं, इस अहंकार के साथ हालिया शोषण का लाभ उठा रहे हैं, और कहते हैं कि हमारे पास 1,000,000 हैश / सेकेंड पर चलने वाला कंप्यूटर है, टक्कर खोजने के लिए 5.3 मिलियन मिलियन मिलियन वर्ष लगेंगे , तो हाँ PHP 300 एक दूसरे काम कर सकते हैं, बड़ा woop, वास्तव में कोई फर्क नहीं पड़ता। कारण हम नमक हैं क्योंकि अगर किसी ने सभी सामान्य शब्दकोश वाक्यांशों को उत्पन्न करने के लिए परेशान किया है, (2 ^ 160 लोग, 2007 युग शोषण में आपका स्वागत है)।

तो यहां एक वास्तविक डेटाबेस है, जिसमें 2 उपयोगकर्ता परीक्षण और व्यवस्थापक उद्देश्यों के लिए उपयोग करते हैं।

RegistrationTime        UserName        UserPass    
1280185359.365591       briang      a50b63e927b3aebfc20cd783e0fc5321b0e5e8b5
1281546174.065087       test        5872548f2abfef8cb729cac14bc979462798d023

वास्तव में, लवण योजना आपकी sha1 (पंजीकरण समय + उपयोगकर्ता नाम) है। आगे बढ़ो, मुझे अपना पासवर्ड बताएं, ये उत्पादन में असली पासवर्ड हैं। आप वहां भी बैठ सकते हैं और php में एक शब्द सूची हैश। जंगली बनो।

मैं पागल नहीं हूँ, मुझे बस पता है कि यह सुरक्षित है। मजेदार खातिर, परीक्षण का पासवर्ड testsha1(sha1(1281546174.065087 + test) + test) = 5872548f2abfef8cb729cac14bc979462798d023

आपको इस उपयोगकर्ता के लिए 27662aee8eee1cb5ab4917b09bdba31d091ab732 के साथ एक संपूर्ण इंद्रधनुष तालिका उत्पन्न करने की आवश्यकता होगी। इसका मतलब है कि मैं वास्तव में अपने पासवर्ड को एक इंद्रधनुष तालिका से समझौता नहीं कर सकता हूं, हैकर को 27662aee8eee1cb5ab4917b09bdba31d091ab732 के लिए परीक्षण के लिए एक संपूर्ण इंद्रधनुष तालिका उत्पन्न करने की आवश्यकता है, और फिर f3f7735311217529f2e020468004a2aa5b3dee7f ब्रायन के लिए। सभी हैंश के लिए 5.3 मिलियन मिलियन मिलियन वर्ष वापस सोचें। केवल 2 ^ 80 हैश (जो 20 yottabytes से अधिक है) को संग्रहित करने के आकार के बारे में सोचें, ऐसा नहीं होने वाला है।

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


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

नमक के साथ, शब्दकोश को स्टोर करने के लिए आवश्यक स्थान तेजी से बढ़ता है ... इतनी तेजी से, कि पासवर्ड शब्दकोष को पूर्व-गणना करने का प्रयास जल्द ही व्यर्थ हो जाता है।

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

नमक सिर्फ "हमलावर के काम को और अधिक परेशान करने से ज्यादा करता है।" यह हमले की एक पूरी कक्षा को समाप्त करता है-प्रीकंप्यूटेड शब्दकोशों का उपयोग।

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

बहुत से लोग पीबीकेडीएफ 2 का उपयोग करते हैं, एक प्रमुख व्युत्पन्न समारोह, जो हजारों बार हैश फ़ंक्शन पर वापस परिणाम खिलाता है। धीमा होने वाला एक पुनरावृत्ति कुंजी व्युत्पन्न का उपयोग करके "bcrypt" एल्गोरिदम समान है।

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

टिप्पणियाँ

नीचे दिए गए टिप्पणियां मैंने प्रश्न पर बनाई हैं।

नमक के बिना, एक हमलावर "अद्यतन 2" में प्रदर्शित विधि का उपयोग नहीं करेगा। वह बस एक पूर्व-गणना तालिका में एक लुकअप करेगा और ओ (1) या ओ (लॉग एन) समय में पासवर्ड प्राप्त करेगा (एन उम्मीदवार पासवर्ड की संख्या होने के नाते)। नमक वह है जो उसे रोकता है और उसे "अद्यतन 2" में दिखाए गए ओ (एन) दृष्टिकोण का उपयोग करने के लिए मजबूर करता है।

एक बार ओ (एन) हमले में कमी हो जाने के बाद, हमें यह विचार करना होगा कि प्रत्येक प्रयास कब तक चलता है। कुंजी-मजबूती से लूप में प्रत्येक प्रयास को पूरा सेकेंड ले सकता है, जिसका अर्थ है कि 10k उपयोगकर्ताओं पर 10k पासवर्ड का परीक्षण करने के लिए आवश्यक समय 3 दिन से 3 साल तक फैला होगा ... और केवल 10k पासवर्ड के साथ, आप शून्य को क्रैक करने की संभावना रखते हैं उस समय पासवर्ड।

आपको यह समझना होगा कि एक हमलावर सबसे तेज़ उपकरण का उपयोग करने जा रहा है, वह PHP नहीं, इसलिए 100 के बजाय हजारों पुनरावृत्तियों, कुंजी-मजबूती के लिए एक अच्छा पैरामीटर होगा। एक पासवर्ड के लिए हैश की गणना करने के लिए इसे एक सेकंड का बड़ा अंश लेना चाहिए।

कुंजी-मजबूती मानक कुंजी व्युत्पन्न एल्गोरिदम पीबीकेडीएफ 1 और पीबीकेडीएफ 2 का हिस्सा है, जो पीकेसीएस # 5 से है, जो महान पासवर्ड obfuscation एल्गोरिदम बनाते हैं ("व्युत्पन्न कुंजी" "हैश" है)।

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

बेशक आप मानते हैं कि हमलावर में सबकुछ है: नमक, हैश, उपयोगकर्ता का नाम। मान लें कि हमलावर एक भ्रष्ट होस्टिंग कंपनी कर्मचारी है जिसने आपकी myprettypony.com fansite पर उपयोगकर्ता तालिका को छोड़ दिया है। वह इन पासवर्ड को पुनर्प्राप्त करने का प्रयास कर रहा है क्योंकि वह घूमने जा रहा है और देख सकता है कि क्या आपके टट्टू प्रशंसकों ने अपने citibank.com खातों पर एक ही पासवर्ड इस्तेमाल किया है।

एक अच्छी तरह से डिज़ाइन की गई पासवर्ड योजना के साथ, इस लड़के के लिए किसी भी पासवर्ड को पुनर्प्राप्त करना असंभव होगा।


नमक इंद्रधनुष तालिका के हमलों को और अधिक कठिन बनाता है क्योंकि यह एक पासवर्ड हैश को क्रैक करने में बहुत कठिन बनाता है। कल्पना करें कि आपके पास केवल नंबर 1 का एक डरावना पासवर्ड है। इंद्रधनुष तालिका का हमला तुरंत इसे क्रैक करेगा।

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

तो मान लें कि आपका नमक कुछ सुरक्षित और यादृच्छिक है, कहें ()% ISLDGHASKLU ( % #% #, हैकर की इंद्रधनुष तालिका को 1 * ()% ISLDGHASKLU (*% #% # के लिए प्रविष्टि की आवश्यकता होगी। अब इंद्रधनुष तालिका का उपयोग करना यहां तक ​​कि यह सरल पासवर्ड अब व्यावहारिक नहीं है।


यह शब्दकोश हमलों को रोक नहीं है।

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

आखिरकार, यह क्रूर-मजबूर हो सकता है, यद्यपि। उस भाग का जवाब आपके उपयोगकर्ताओं को शब्दकोष शब्दों को पासवर्ड के रूप में उपयोग करने के लिए मजबूर करना है (उदाहरण के लिए कम से कम एक संख्या या विशेष वर्ण की न्यूनतम आवश्यकताओं)।

अपडेट करें :

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

मुझे एक तथ्य के लिए पता है कि एसएचए -256 और एसएचए -512 के लिए समर्थन जीएनयू क्रिप्ट के नए संस्करणों में जोड़ा गया था।


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

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


सलाम का मुद्दा हमलावर के प्रयासों के परिशोधन को रोकने के लिए है।

बिना नमक के, प्रीकंपुटेड हैश-पासवर्ड प्रविष्टियों की एक तालिका (जैसे सभी अल्फान्यूमेरिक 5 कैरेक्टर स्ट्रिंग्स का एमडी 5, ऑनलाइन ढूंढना आसान है) दुनिया के हर डेटाबेस में प्रत्येक उपयोगकर्ता पर इस्तेमाल किया जा सकता है।

साइट-विशिष्ट नमक के साथ, हमलावर को तालिका को स्वयं गणना करना होता है और फिर साइट के सभी उपयोगकर्ताओं पर इसका उपयोग कर सकते हैं।

प्रति उपयोगकर्ता नमक के साथ, हमलावर को प्रत्येक उपयोगकर्ता के लिए अलग-अलग प्रयासों को खर्च करना पड़ता है।

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


हां, आपको sha1 (नमक | पासवर्ड) के लिए केवल 3 दिन की आवश्यकता है। यही कारण है कि अच्छा पासवर्ड स्टोरेज एल्गोरिदम 1000-पुनरावृत्ति हैशिंग का उपयोग करता है: आपको 8 साल की आवश्यकता होगी।







dictionary-attack