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


89

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


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

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


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


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


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


मुझे कहना होगा कि मैं नीचे दिए गए कई उत्तरों से भ्रमित हूं। नमक का उपयोग करने का मुख्य बिंदु बस इंद्रधनुष तालिका हमले को रोकने के लिए है ताकि उपयोगकर्ता को कुछ भी अनोखा करना चाहिए क्योंकि यह हमलावर को प्रत्येक नमक के लिए इंद्रधनुष तालिका को फिर से बनाने के लिए मजबूर करता है। मेरे 2 सी।
गोरान

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

@ मद्जिक, नमक का उद्देश्य आरटी के हमलों को रोकना और विभिन्न उपयोगकर्ताओं के लिए समान पासवर्ड को अलग करना है। उपयोगकर्ता नाम के साथ भी यह एक दिया गया है।
AviD

@ एवीडी: यह सच है। लेकिन अगर मैं अपने पास के लिए अपना हैश जानता हूं, और मुझे पता है कि नमक मेरा उपयोगकर्ता नाम है तो मैं आसानी से किसी भी शब्दकोश शब्द के लिए हैश पास मान बना सकता हूं, और इसकी तुलना किसी और पास हैश से कर सकता हूं। इसीलिए यूजरनेम से समय बेहतर है।
dmajkic

1
बस पीएचपी सुरक्षा कंसोर्टियम वेबसाइट पर एक लेख में पाया गया कि इसके उदाहरण का उपयोग करता है में एक md5 हैश यादृच्छिक नमक के रूप में संख्या phpsec.org/articles/2005/password-hashing.html
helloworlder

जवाबों:


156

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

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

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

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

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

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

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

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


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

मैं क्रॉस-सिस्टम सुरक्षा पर आपकी बात की सराहना करता हूं। इसके अलावा, मुझे लगता है कि भविष्य में इसके उपयोगकर्ता-विशिष्ट इंद्रधनुष तालिकाओं को देखने की संभावना नहीं है ...
AviD

@ एवीडी: आपको ऐसा लगता है? यह काफी विशिष्ट हमला वेक्टर है।
डेविड ग्रांट

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

3
@ acidzombie24: सभी पासवर्डों के लिए एक एकल तय नमक (आमतौर पर "अनुभव में" नामक ") का उपयोग करना प्रत्येक पासवर्ड के लिए एक अद्वितीय यादृच्छिक नमक का उपयोग करने से कम सुरक्षित है, क्योंकि यह अभी भी एक हमलावर को दो या दो से अधिक शेयर निर्धारित करने की अनुमति देता है एक ही पासवर्ड। दूसरी ओर, गैर-डेटाबेस के बजाय संभवतः आपके कोड में संग्रहीत किया जाएगा, इसलिए एक हमलावर जिसके पास केवल आपका डेटाबेस है, उसके पास इसका उपयोग नहीं होगा; इस वजह से, सबसे सुरक्षित विकल्प सिस्टम-वाइड नॉन (कोड में संग्रहीत) और प्रति-पासवर्ड नमक (डेटाबेस में संग्रहीत) दोनों का उपयोग करना है।
डेव शेरोहमान

29

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

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

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

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

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


एक अच्छे बिंदु के लिए +1, हालांकि, आप संभावित बड़े पैमाने पर इंद्रधनुष तालिका के बारे में बात कर रहे हैं । GsMyPassword लंबाई (मिश्रित-केस अल्फ़ान्यूमेरिक मानकर) के सभी मूल्यों को कवर करने के लिए तालिका में 36 ^ 12 पंक्तियों की आवश्यकता होती है!
डेविड ग्रांट

एक अनुवर्ती के रूप में: वितरित इंद्रधनुष तालिका परियोजना में 63,970 फटा हुआ हैश है, लेकिन 36 ^ 12 4,738,381,338,321,616,896 है!
डेविड ग्रांट

धन्यवाद, और इसका कोई मतलब नहीं है - लेकिन जैसा कि Mr.PotatoHead ने बताया है, आप अभी भी RT के साथ क्रैकिंग के उचित व्यवसाय से परे अपने स्थान का विस्तार कर रहे हैं। इसके अलावा, यह मानते हुए कि मेरे उपयोगकर्ता नाम कम से कम 6-8 वर्ण हैं - एंट्रोपी क्या अतिरिक्त आवश्यक मूल्य प्रदान करता है?
AviD

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

3
नमक के रूप में उपयोगकर्ता नाम का उपयोग करना उन प्रणालियों के लिए भी एक बुरा विचार है जहां अनुमानित रूप से उच्च-विशेषाधिकार वाला खाता है: विंडोज पर "प्रशासक", * nix पर "रूट", MSSQL में "सा", आदि
कोई भी

8

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

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

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


मेरा मानना ​​है कि आप सही हैं कि यह पर्याप्त है। हालांकि, यह देखते हुए कि हैश एक जटिल गणितीय क्षेत्र है और यह बहुत अच्छी तरह से संभव है कि कम एंट्रॉपी लवण भविष्य में अनुमान लगाने के लिए हैश को अधिक आसानी से बनाते हैं, (विशेषकर हैश टूट जाते हैं), मैं सुरक्षा पर दांव नहीं लगाऊंगा, जब साबित हो जाएगा अधिक सुरक्षित समाधान अधिक महंगा नहीं है।
जॉर्ज शॉली 13

7

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

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

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


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

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

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

1
अच्छी बात। हम पाते हैं कि पहले उपयोगकर्ता को एक नए डेटाबेस में जोड़ना तेजी से मुश्किल हो जाता है: हमने प्रभावी रूप से हमारे एप्लिकेशन को इतना सुरक्षित बना दिया है कि हम उन्हें मुश्किल से खुद को हैक कर सकते हैं। [इसके अलावा, एक एप्लिकेशन-विशिष्ट नमक का उपयोग करें ताकि आप एक डेटाबेस से दूसरे में क्रेडेंशियल्स की नकल न कर सकें।]
Teedyay

अंत में मैंने किसी को यह कहते हुए पाया: नमक के लिए कुछ उपयोगकर्ता-विशिष्ट जोड़ना। यह एक घुसपैठिया को किसी अन्य उपयोगकर्ता के लिए कुछ क्रेडेंशियल्स की नकल करने से बचाता है, और किसी हैकर को किसी भी पासवर्ड का अनुमान लगाने से रोकता है, यदि वह तालिका में आपके हैश और नमक क्षेत्र तक पहुंचने का प्रबंधन करता है। एक और बात जो मुझे करना पसंद है: हैशिंग में पुनरावृत्तियों की एक संख्या का उपयोग नहीं करना। 10k या 20k के लिए मत जाओ, लेकिन 19835 की तरह कुछ।
एंड्रयू

3

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

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

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


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

1
एक स्थिर हैश कुछ भी नहीं है। एकल इंद्रधनुष-तालिका का उपयोग करके सभी पासवर्ड को क्रैक किया जा सकता है। नमक का उद्देश्य यह है कि इंद्रधनुष-तालिका बनाना असंभव है।
जॉर्ज शाओली

1
@gs - मैं यह नहीं देखता कि आप एक इंद्रधनुष तालिका क्यों नहीं बना सकते हैं जिसमें एक स्थिर नमक का प्रभाव "शामिल" है। हमले का स्थान (पासवर्ड) नहीं बदला है, इसलिए तालिका को बढ़ने की आवश्यकता नहीं है, बस पुनर्गणना की आवश्यकता है।
हुगहुगा

@ पोटाटो - ट्रेडऑफ पर निर्भर करता है। यदि आपकी कंपनी के 20k लॉगिन में एक ही निरंतर नमक के साथ सभी हैशेड थे, तो उन सभी पर व्यक्तिगत रूप से हमला करने की तुलना में एक ताजा इंद्रधनुष तालिका की गणना करना सस्ता हो सकता है। इसलिए "बल" का मेरा जोर।
हुगहुगाह

3

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

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


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

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

यह मेरी सोच भी थी - लेकिन मैं "शायद ठीक है" पर अटक गया। मैं अभी भी इस सिद्धांत को सिद्ध नहीं होता देख रहा हूं - या कम से कम सत्यापित किया गया है कि क्रिप्टोनालिसिस निहितार्थ नहीं हैं।
एवीडी

@onebyone: यदि नमक में उपयोगकर्ता नाम + निरंतर स्थानीय मूल्य (मैं अक्सर उपयोग करता हूं: ') होता है, तो वह अभी भी मानकीकृत आरटी को बर्बाद कर देता है, जब तक कि उनमें से कई प्रकार के आम उपयोगकर्ता नाम और सामान्य स्थिर नमक मान शामिल नहीं होते हैं। मुझे संदेह है कि ऐसा नहीं है।
nsayer

Nsayer के साथ। आप एक सिस्टम-वाइड निरंतर स्ट्रिंग का उपयोग कर सकते हैं, कि # के लिए # (D83d8, जैसे कि नमक के रूप में उपयोगकर्ता नाम के साथ एक pregenerated RT नहीं होगा, और यह किसी भी इंद्रधनुष तालिका हमलों को रोक देगा।
Kibbee

3

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

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

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

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

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


फ़ंक्शन की ताकत में बदलाव नहीं होता है, लेकिन आउटपुट निश्चित रूप से बदलता है। यदि इनपुट को प्रभावित या ज्ञात किया जा सकता है, तो शायद हैश मूल्य के बारे में कुछ काटा जा सकता है। यही जोखिम है।
मार्टिन कारपेंटर

@Martin: केवल एक चीज जो आपको हैश मूल्य से कम करने में सक्षम होना चाहिए, चाहे आपके पास मैच हो या न हो! एक हैश फ़ंक्शन में "रोटा" या "रूटब" (जहां "" ए "और" बी "पासवर्ड का प्रतिनिधित्व करते हैं) डालना आपको मौलिक रूप से अलग आउटपुट देगा।
डेविड ग्रांट

लवण इंद्रधनुष-तालिकाओं का उपयोग करके एक हमलावर को जाना जाता है।
जॉर्ज शॉर्ली

सर्वर को अनएन्क्रिप्टेड नमक (हैश के खिलाफ पासवर्ड की जाँच करने के लिए) को जानना होता है, इस प्रकार कोई भी यह मान सकता है कि किसी हमलावर के पास नमक है या वह बहुत आसानी से प्राप्त कर सकता है।
जॉर्ज Schölly

सही, ठीक है, एक दिया - अधिक विशिष्ट होने के लिए मेरा मतलब था कि समग्र क्रिप्टोसिस्टम (या -subsystem, wrt हैश) की ताकत।
एवीडी

1

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

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

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

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


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

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

-1

एन्ट्रॉपी नमक मूल्य का बिंदु है।

अगर नमक के पीछे कुछ सरल और प्रतिलिपि प्रस्तुत करने योग्य "गणित" है, तो यह उसी तरह है जैसे नमक नहीं है। बस समय मान जोड़ना ठीक होना चाहिए।


मुझे यह टिप्पणी समझ में नहीं आती। आप कहते हैं "एंट्रोपी का उपयोग करें", और फिर: "समय का उपयोग करें" ??
मार्टिन कारपेंटर

यदि उपयोगकर्ता नाम नमक के लिए उपयोग किया जाता है, तो यह पर्याप्त नहीं है। लेकिन अगर आप यूज़रनेम + करंट डेटाइम का उपयोग करते हैं - यह है, क्योंकि यह अनुमान लगाना कठिन है कि वास्तव में नमक कब बनाया गया था।
dmajkic

"एन्ट्रोपिक पर्याप्त" व्यक्तिपरक है; यह आपका मानक है। इस मूल्य को समय पर प्राप्त करना पर्याप्त नहीं हो सकता है।
मार्टिन कारपेंटर

"पूर्ण सत्य यादृच्छिकता" जैसी कोई चीज नहीं है। यह "अच्छा पर्याप्त" है, यह कहने के लिए हम पर है। अगर आपको लगता है कि इस मामले में समय पर्याप्त नहीं है, तो कुछ और उपयोग करें। stackoverflow.com/questions/84556/…
dmajkic

दरअसल, नमक का बिंदु प्रत्येक हैश परिणाम को अद्वितीय बनाने के लिए है - ताकि (ए) इंद्रधनुष तालिका हमलों को रोका जा सके, और (बी) समान पासवर्ड पहचान। सवाल यह है कि आखिर किस चीज के लिए एन्ट्रापी की जरूरत है?
एवीडी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.