security पासवर्ड हैश के लिए गैर यादृच्छिक नमक




authentication hash (8)

मैं दोनों का उपयोग करना चाहूंगा: एक उच्च-एंट्रोपी यादृच्छिक प्रति रिकॉर्ड नमक, साथ ही रिकॉर्ड की अद्वितीय आईडी।

यद्यपि यह शब्दकोशों के हमले, आदि के प्रति सुरक्षा में ज्यादा नहीं जोड़ता है, यह फ्रिंज केस को निकालता है जहां कोई व्यक्ति अपने नमूनों और हैश को अपने खुद के साथ पासवर्ड बदलने के इरादे से दूसरे रिकॉर्ड में कॉपी करता है

(बेशक यह एक ऐसी परिस्थिति के बारे में सोचना कठिन है जहां यह लागू होता है, लेकिन जब सुरक्षा की बात आती है तो मुझे बेल्ट और ब्रेसिज़ में कोई नुकसान नहीं दिखाई दे सकता।)

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

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

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

नोट, मैं एक एकल स्थिर हैश (नहीं), या किस तरह का हैश फ़ंक्शन का उपयोग करने के लिए नमक का उपयोग करने के बारे में नहीं कह रहा हूं, इसे कैसे सुरक्षित करना है (इसे होने की आवश्यकता नहीं है)
सिर्फ नमक की जरूरत है एंट्रपी या नहीं।

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

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


पारंपरिक रूप से नमक पासवर्ड के लिए उपसर्ग के रूप में संग्रहीत किया जाता है यह पहले से ही पासवर्ड हैश तक पहुंच के साथ किसी भी हमलावर को ज्ञात करता है। यूजरनेम के रूप में नमक का प्रयोग करना या उस ज्ञान को प्रभावित नहीं करता है और इसलिए, एकल सिस्टम सुरक्षा पर इसका कोई असर नहीं होगा।

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

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

इन दोनों दोषों को प्रभावी ढंग से दूसरी नमक मूल्य (या तो तय और छुपी हुई है या मानक नमक की तरह उजागर किया जा सकता है) को पासवर्ड से पहले प्रभावी ढंग से संबोधित किया जा सकता है, लेकिन, उस समय, आप मानक एंट्रोपिक नमक का उपयोग कर सकते हैं इसमें यूज़रनेम काम करने की

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

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

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

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


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

नमक में जितना संभव हो उतना एन्ट्रोपी के साथ कभी-बदलते नमक मूल्यों का उपयोग करना सुनिश्चित करेगा कि हिसिंग की संभावना (जैसे, पासवर्ड + नमक) पूरी तरह से अलग हैश मूल्यों का उत्पादन करेगी।

नमक में कम एंट्रोपी, एक ही नमक मूल्य पैदा करने का अधिक मौका है, इस प्रकार इस प्रकार आपके पास एक ही हैश वैल्यू पैदा करने का अधिक मौका है।

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


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

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


एक हैश फ़ंक्शन की ताकत इसके इनपुट से निर्धारित नहीं होती है!

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

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

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

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


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

अद्वितीय लवण का प्रयोग बल्क शब्दकोश हमलों की कठिनाई को बढ़ाता है।

अद्वितीय, क्रिप्टोग्राफ़िक रूप से मजबूत नमक मान होने पर आदर्श होगा।


यह सच है कि अकेले उपयोगकर्ता केवल समस्याग्रस्त हो सकता है क्योंकि लोग अलग-अलग वेबसाइट के बीच उपयोगकर्ता नाम साझा कर सकते हैं। लेकिन उपयोगकर्ताओं को प्रत्येक वेबसाइट पर एक अलग नाम मिला है, लेकिन यह बजाय unproblematic किया जाना चाहिए। तो क्यों न केवल प्रत्येक वेबसाइट पर इसे अद्वितीय बनाएं इस तरह कुछ हद तक पासवर्ड हंस लें

hashfunction ( "www.yourpage.com /" + उपयोगकर्ता नाम + "/" + पासवर्ड)

इससे समस्या हल हो जानी चाहिए। मैं क्रिप्टैनालिसिस का मास्टर नहीं हूं, लेकिन मुझे संदेह है कि यह सच है कि हम उच्च एन्ट्रापी का उपयोग नहीं करते हैं, जो कि किसी भी कमजोर को हैश करेंगे।


पासवर्ड को सुरक्षित रूप से स्टोर करने के लिए उच्च एंट्रोपी नमक का उपयोग करना जरूरी है

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

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

वे 12-बिट नमक करते थे । 12 बिट 4096 विभिन्न संयोजन हैं। यह पर्याप्त सुरक्षित नहीं था क्योंकि यह जानकारी आजकल आसानी से संग्रहीत की जा सकती है वही 4096 सबसे अधिक इस्तेमाल किया उपयोगकर्ता नामों के लिए लागू होता है। ऐसा लगता है कि आपके कुछ उपयोगकर्ता उपयोगकर्ता नाम चुनना होगा जो सबसे आम उपयोगकर्ता नामों से संबंधित है।

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





password-protection