hash अपना पासवर्ड नमस्कार: सर्वोत्तम व्यवहार?




cryptography passwords (7)

मैं हमेशा उत्सुक रहा हूं ... हैशिंग के लिए पासवर्ड लेटने पर कौन सा बेहतर है: उपसर्ग, या पोस्टफिक्स? क्यूं कर? या इससे कोई फर्क पड़ता है, जब तक आप नमक करते हैं?

व्याख्या करने के लिए: हम सभी (उम्मीद है) अब तक जानते हैं कि हमें डेटाबेस में भंडारण के लिए इसे हश करने से पहले एक पासवर्ड salt करना चाहिए [ संपादित करें: तो आप हाल ही में जेफ एटवुड के साथ क्या हुआ उससे बच सकते हैं]। आम तौर पर यह हैशिंग एल्गोरिदम के माध्यम से इसे पास करने से पहले पासवर्ड के साथ नमक को जोड़कर किया जाता है। लेकिन उदाहरण अलग-अलग हैं ... कुछ उदाहरण पासवर्ड से पहले नमक तैयार करते हैं। कुछ उदाहरण पासवर्ड के बाद नमक जोड़ते हैं। मैंने कुछ ऐसे लोगों को भी देखा है जो नमक को बीच में डालने का प्रयास करते हैं।

तो कौन सी बेहतर विधि है, और क्यों? क्या ऐसी कोई विधि है जो हैश टक्कर का मौका कम करती है? माई गुगलिंग ने इस विषय पर एक सभ्य विश्लेषण नहीं किया है।

संपादित करें: महान जवाब लोग! मुझे खेद है कि मैं केवल एक जवाब चुन सकता हूं। :)


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

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


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


उपसर्ग या प्रत्यय अप्रासंगिक है, यह केवल पासवर्ड में कुछ एन्ट्रॉपी और लंबाई जोड़ने के बारे में है।

आपको उन तीन चीजों पर विचार करना चाहिए:

  1. आपके द्वारा संग्रहीत हर पासवर्ड के लिए नमक अलग होना चाहिए। (यह काफी आम गलतफहमी है।)
  2. एक क्रिप्टोग्राफिक रूप से सुरक्षित यादृच्छिक संख्या जेनरेटर का प्रयोग करें।
  3. एक लंबा पर्याप्त नमक चुनें। जन्मदिन की समस्या के बारे में सोचें।

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


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


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

आपको हैश के बारे में चिंतित होना चाहिए लुकअप टेबल, इंद्रधनुष या अन्यथा।

@ Onebyone.livejournal.com:

हमलावर में 'इंद्रधनुष सारणी' होती है जिसमें शब्द शब्दों के हैंश की नहीं है, बल्कि हैश गणना को अंतिम रूप देने से पहले हैश गणना की स्थिति है।

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

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

इसके अलावा पासवर्ड हैशिंग एल्गोरिदम जैसे कि पीबीकेडीएफ ने अपने हैश फ़ंक्शन को कई बार लिखें (पीबीकेडीएफ -2 को कम से कम 1000 बार पुनरावृत्ति करने की अनुशंसा की जाती है, प्रत्येक पुनरावृत्ति SHA-1 को दो बार लागू करती है) इस हमले को दोगुना अव्यवहारिक बनाते हैं।


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

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

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


मुझे लगता है कि यह सभी अर्थशास्त्र है। इसे पहले या बाद में रखना किसी भी विशिष्ट खतरे के मॉडल को छोड़कर कोई फर्क नहीं पड़ता।

तथ्य यह है कि इंद्रधनुष सारणी को हराने के लिए माना जाता है।

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

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

जैसा मैंने कहा। यह अर्थशास्त्र है। प्रति पासवर्ड एक अलग नमक चुनें, एक लंबा नमक, और इसमें विषम पात्रों जैसे प्रतीक और ASCII कोड शामिल करें: © ¡¡





salt