पासवर्ड फ़ील्ड को हशिंग और सलाम करना

Question

मैं कुछ समय के लिए अपने डीबी में पासवर्ड कैसे स्टोर करना है, इस सवाल के आसपास फेंक रहा हूं। वेब लॉगिन के साथ एक सुरक्षित एप्लिकेशन बनाने में यह मेरा पहला समय है, इसलिए मैं कुछ अच्छे प्रथाओं को स्थापित करना चाहता था।

सबसे पहले, मैंने हैशिंग और नमकीन पर पढ़ा। ऐसा लगता है कि विचार है ...

2. हैशिंग एल्गोरिथ्म हो जाओ उपयोगकर्ता से पासवर्ड प्राप्त
3. जोड़े 'नमक' सादा पाठ पासवर्ड के लिए उपयोगकर्ता से पूरे पासवर्ड (नमक सहित)
4. हैश
5. स्टोर DB में नमक, ताकि आप

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

तब मुझे एक विचार था। क्या होगा यदि आपने अपने नमक को शेड पासवर्ड फ़ील्ड के अंदर संग्रहीत किया है।

xxxxxsaltvaluexxxxxxxxxxxxxxxx

जहां x टुकड़ों में बंटी स्ट्रिंग मान है: तो चरणों 1-4 (बेतरतीब ढंग से नमक पैदा करने), तो चरण 5 में, पासवर्ड कहीं पासवर्ड व्याख्या वर्ग या सेवा के द्वारा जाना जाता है में नमक डालने का पालन करें । क्या कोई इस के साथ कोई समस्या देख सकता है? क्या यह सिर्फ पूरी तरह से अनावश्यक है?

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

धन्यवाद के लिए एक विश्वसनीय लाइब्रेरी नहीं मिल सका!
टीटीडी

Answer 1

एक सुरक्षा के दृष्टिकोण है कि जरूरी नहीं है जब तक आप केवल टुकड़ों में बांटा पासवर्ड (कभी दुकान क्लियर पासवर्ड!) प्लस नमक की दुकान से ...नमक जानने के लिए एक हमलावर "अनुमत" है - आपकी सुरक्षा को इस तरह से डिजाइन किया जाना चाहिए कि नमक के ज्ञान के साथ भी यह अभी भी सुरक्षित है।

नमक क्या करता है?

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

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

आप आगे सुरक्षा को मजबूत करना चाहते हैं
आप कई बार हैश गणना कर सकते हैं (हैश हैश आदि) - यह आप ज्यादा खर्च नहीं करना पड़ता, लेकिन यह की गणना एक जानवर बल हमले में आता है/"इंद्रधनुष-टेबल" और भी महंगा ... कृपया स्वयं का आविष्कार न करें - ऐसा करने के लिए सिद्ध मानक तरीके हैं, उदाहरण के लिए देखें http://en.wikipedia.org/wiki/PBKDF2 और http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx

Answer 2

आप खरगोश छेद में गिरने वाले हैं। Use bcrypt।

Answer 3

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

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

पढ़ें this