2010-06-17 15 views
5

मैं किसी भी सुरक्षा विशेषज्ञ या यहां तक ​​कि एक नौसिखिया नहीं हूं। मैं सुरक्षा पर एक नौसिखिया हूँ।तालिका में पासवर्ड फ़ील्ड के लिए मुझे क्या उपयोग करना चाहिए; एमडी 5 या एसएचए 1?

किसी ने सुझाव दिया कि मैं MD5 के बजाय SHA1 का उपयोग करता हूं - मैं दूसरे पर एक क्यों चुनूं? क्या एक और सुरक्षित है?

+2

"कार्गो पंथ" उत्तरों से सावधान रहें कि दावा है कि एक हैश एल्गोरिदम "टूटा हुआ" या "दोषपूर्ण" है, जिसके बिना एल्गोरिदम दोषपूर्ण है। यदि आप किसी डेटाबेस में पासवर्ड के सादे SHA-1 हैंश स्टोर करते हैं, तो आपका दृष्टिकोण MD5 के साथ त्रुटिपूर्ण है (http://en.wikipedia.org/wiki/Rainbow_table देखें)। मेरा मानना ​​है कि हैश टकराव उत्पन्न करने के लिए आवश्यक बकाया डेटाबेस में उपयोगकर्ता के पासवर्ड सुरक्षित रूप से संग्रहीत करने के उपयोग के मामले में बहुत महत्वपूर्ण नहीं है। सही जवाब नमक, चाबी हैश, पीबीकेडीएफ 2, आदि का उपयोग करने के साथ होता है – dtb

+0

+1 - यह एक छोटे से छोटे प्रश्न का एक बड़ा उदाहरण है जो सतह पर पूरी तरह से निर्दोष लगता है लेकिन वास्तव में एक शानदार प्रवेश बिंदु है बहुत बड़ा, बहुत अस्पष्ट और बहुत महत्वपूर्ण खानभूमि। –

उत्तर

10

मैं कम से कम SHA2 (256) का प्रयोग करेंगे - लेकिन:

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

Password Stretching का उपयोग करने के लिए एक बेहतर समाधान है जो एक यादृच्छिक नमक के साथ-साथ यादृच्छिक (उच्च) संख्याओं का उपयोग करता है ताकि प्रत्येक पासवर्ड के खिलाफ एक क्रूर-बल हमले का प्रयास करने में काफी समय लगे और इसलिए यह सभी को क्रैक करने के लिए शारीरिक रूप से कठिन हो जाता है पासवर्ड

मुझे विश्वास है। नेट में यह पीबीकेडीएफ का उपयोग करके हासिल किया जा सकता है - लेकिन मैंने इसे एक लिंक गलत बताया है (किसी ने मुझे एक प्रश्न के उत्तर में मुझे उत्तर दिया है)। संपादित करें- .NET: Rfc2898DeriveBytes Class के लिए लिंक मिला।

MD5 पर

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

+0

+1। यह एकमात्र उत्तर है जिसे अभी तक सही मिला है। – dtb

+0

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

+0

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

0

MD5 "टूटे" किया गया है, और सुरक्षा के उच्च स्तर अब SHA-2 की आवश्यकता होती है, वास्तव में। यह http://en.wikipedia.org/wiki/MD5 पर काफी दिलचस्प पढ़ा गया है।

संपादित करें: 9 सेकंड देर :)

1

जो भी आप उपयोग करते हैं, नमकीन हैश का उपयोग करें।

शुभकामनाएं।

1

भंडारण सस्ता है और प्रोसेसर तेज़ हैं। SHA-512 के साथ 1 किलोबाइट नमक का उपयोग करें।

3

एमडी 5 और एसएचए 1 दोनों को असुरक्षित माना जाता है, एसएचए -1 बेहतर होने के साथ। हालांकि, वहाँ 2 चीजें हैं जो आप विचार करना चाहिए:

  1. द्वारा "असुरक्षित", वे कहते हैं कि यह गणितीय पूर्व टुकड़ों में बांटा मूल्य निर्धारित करने के लिए जानवर बल की तुलना में आसान है कहने के लिए मतलब है। कभी-कभी इसका मतलब है कि वे इसे एक अरब गणना से 900 मिलियन तक काट सकते हैं, दूसरी बार यह काफी कम है। यह मेरे बिंदु # 2 के रूप में असुरक्षित के रूप में कहीं भी नहीं है।

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

उदाहरण के लिए, बहुत से लोग अपने पासवर्ड के रूप में "पासवर्ड" और "जॉन" का उपयोग करते हैं। MD5 में, इन दो पासवर्ड हमेशा उत्पन्न करने के लिए: पासवर्ड: 5f4dcc3b5aa765d61d8327deb882cf99 जॉन: 527bd5b5d689e2c32ae974c6229ff785

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

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

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

डीबी कॉलम: उपयोगकर्ता नाम | पासवर्ड | नमक

यह किसी भी सुरक्षित प्रणाली का सबसे सुरक्षित सिस्टम नहीं है, लेकिन यह आपके लिए काम करेगा।

+2

आप उपयोगकर्ता नाम के साथ हैश भी कर सकते हैं, जो उपयोगकर्ता में सबसे अधिक अद्वितीय होगा डेटाबेस, यानी एक "यादृच्छिक नमक"। – Patrick

+0

हाँ, आप जो कुछ भी चाहते थे वह बहुत काम करेगा यदि आपको वास्तव में यादृच्छिक होने की आवश्यकता नहीं है। निश्चित रूप से यादृच्छिक संख्या जेनरेटर हैं जिन्हें आप वास्तव में परवाह करते हैं तो आप हैश कर सकते हैं। – Jordan

+0

+1 हालांकि सुरक्षा समुदाय की नजर में हैश कई * असुरक्षित * बन सकता है; वह उनमें से एक है। चाहे ज्ञात भेद्यताएं वर्तमान में आपके आवेदन को प्रभावित करती हैं, बिंदु के बगल में है: ** सैद्धांतिक रूप से सुरक्षित एक का उपयोग करते समय सैद्धांतिक रूप से असुरक्षित हैश का उपयोग करना इतना आसान क्यों है? ** इसके अलावा, माफ की तुलना में बेहतर-सुरक्षित, क्योंकि ब्रूस शनीयर हमेशा कहते हैं , * * हमले केवल बेहतर हो जाते हैं, कभी भी बदतर नहीं! "* :) –

संबंधित मुद्दे