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




hash salt (9)

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

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

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

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

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

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

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

टिप्पणियाँ

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

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

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

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

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

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

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

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

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

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

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

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

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


सरल शब्दों में: बिना नमस्कार के, प्रत्येक उम्मीदवार पासवर्ड को केवल "ज्ञात ब्रह्मांड" (समझौता डेटाबेस का संग्रह) में कहीं भी, हर उपयोगकर्ता के खिलाफ जांचने के लिए धोया जाना चाहिए, जिसका पासवर्ड उसी एल्गोरिदम के माध्यम से धोया जाता है। नमक के साथ, यदि संभावित नमक मूल्यों की संख्या "ज्ञात ब्रह्मांड" में उपयोगकर्ताओं की संख्या से काफी अधिक है, तो प्रत्येक उम्मीदवार के पासवर्ड को प्रत्येक उपयोगकर्ता के लिए अलग से धोया जाना चाहिए जिसके खिलाफ इसका परीक्षण किया जाएगा।


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

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

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

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

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


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

यदि आप हैश गुप्त को आज़माकर रखते हैं तो हमलावर भी हैश को सत्यापित नहीं कर सकता है।

संपादित करें- बस ध्यान दिया गया है कि उपरोक्त टिप्पणी में मुख्य बिंदु बनाया गया था।


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

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


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

तो आइए कहें कि हम एसएचए 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 से अधिक है) को संग्रहित करने के आकार के बारे में सोचें, ऐसा नहीं होने वाला है।

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


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

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

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

अपडेट करें :

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

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





dictionary-attack