2009-08-12 9 views
5

में पासवर्ड स्टोर करने का सबसे अच्छा तरीका सादा पाठ में संग्रहीत किया गया है जो स्पष्ट रूप से अच्छा नहीं है। तो मैं सिर्फ यह जानना चाहता हूं कि पासवर्ड एन्क्रिप्ट करने और SQL सर्वर में संग्रहीत करने का सबसे अच्छा तरीका क्या है। मैंने पढ़ा है कि हैश + नमक का उपयोग करना बेहतर है। लेकिन मुझे लगता है कि "एन्क्रिप्टेड बायपासफ्रेज़", "डिक्रिप्ट बायपासफ्रेज़" एसक्यूएल 2005 में नई सुविधा का उपयोग करना बेहतर है क्योंकि आप SQL सर्वर से सब कुछ संभालने वाले हैं और मुझे लगता है कि यह ट्रिपल डीईएस का उपयोग करता है। क्या कोई सुझाव दे सकता है कि इसका इस्तेमाल करना अच्छा लगे?मेरे मौजूदा सी # विंडोज़ एप्लिकेशन पासवर्ड में एसक्यूएल

+0

आपके उत्तरों के लिए बहुत कुछ है। मुझे लगता है कि नमक शड के साथ sha1 या sha256 का उपयोग अच्छा हो। केवल drwabck है कि मैं इसे decrpyt नहीं कर सकता। लेकिन फिर भी यह समझ में आता है। लेकिन मुझे बीसीआरईपीटी के बारे में भी पता चला जो मुझे अच्छा लग रहा है, लेकिन मेरे प्रोजेक्ट के लिए यह एसएचए का उपयोग करने के लिए पर्याप्त है। अगर कोई एबीटी बीसीआरपीटी जानना चाहता है तो chk ths link- http://derekslager.com/blog/posts/2007/10/bcrypt-dotnet-strong-password-hashing-for-dotnet-and-mono.ashx –

उत्तर

3

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

+0

हां हैश एल्गोरिदम एक अच्छी पसंद है। अंतिम पैराग्राफ के बारे में – adatapost

2

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

यह सब महत्वपूर्ण प्रबंधन के लिए आता है और आप इसे कैसे करना चाहते हैं।

5

क्या आपको मूल पासवर्ड तक पहुंचने की आवश्यकता है, या आप बस डेटाबेस में किसी एक के खिलाफ दर्ज पासवर्ड की कोशिश करने और तुलना करने जा रहे हैं?

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

यदि आप जो भी कर रहे हैं वह डेटाबेस में एक पासवर्ड संग्रहीत कर रहा है ताकि आप इसे बाद में ज्ञात इनपुट मान के विरुद्ध देख सकें, फिर नमक के साथ एक हैश काम करेगा।

याद रखें कि जब ग्राहक प्रमाणित होने के लिए प्रमाण पत्र भेज रहा है, तो आप स्पष्ट टेक्स्ट में पासवर्ड नहीं भेजना चाहते हैं!

+0

। आप पासवर्ड कैसे भेजते हैं? क्या आपने इसे क्लाइंट साइड है और हैश भेज दिया है? यदि ऐसा है, तो क्या क्लाइंट एल्गोरिदम का उपयोग करने में सक्षम नहीं होगा? –

+0

@ मिपरनीसरी इससे कोई फर्क नहीं पड़ता कि क्या उन्हें पता है कि हैशिंग एल्गोरिदम का उपयोग किया जाता है - एक तरफा हैश का बिंदु यह है कि आउटपुट दिया जाता है, इनपुट को ढूंढना बहुत मुश्किल होता है। [इंद्रधनुष तालिकाओं] के खिलाफ सहायता लड़ाई (https://en.wikipedia.org/wiki/Rainbow_table) आपको इसे बनाने के लिए नमक (बोनस अंक: प्रति उपयोगकर्ता एक अलग नमक का उपयोग करें) का उपयोग करना चाहिए ताकि यदि कोई बुरा अभिनेता समाप्त हो जाए अपने पासवर्ड हैश की पूरी प्रतिलिपि के साथ, उन्हें अपने सभी पासवर्डों को बलपूर्वक बल देने के लिए इंद्रधनुष तालिकाओं का एक गुच्छा गणना करना होगा। – scwagner

0

अधिकांश प्रश्नों के साथ सबसे अच्छा जवाब आपकी स्थिति के संदर्भ पर निर्भर करता है। कोई अच्छा समाधान नहीं है।

कुछ विकल्प:

  1. सादा पाठ या reversably एन्क्रिप्ट में पासवर्ड छोड़ दें। RDBMS स्तर पर महत्वपूर्ण फ़ील्ड एन्क्रिप्ट करने के लिए SQLServer सुविधाओं का उपयोग करें या समान एन्क्रिप्शन फ़ंक्शंस का उपयोग करें और उम्मीद करें कि एमएस ने उचित कुंजी प्रबंधन लागू किया है और चाबियाँ आपके उद्देश्यों के लिए उचित रूप से सुरक्षित हैं। प्रैक्टिस में सभी एन्क्रिप्शन एक बड़े रहस्य के भंडारण में बहुत सारे छोटे रहस्यों का भंडारण भंडारण होता है .. इससे समस्या अधिक मनोरंजक हो सकती है लेकिन समस्या स्वयं कभी नहीं जाती है।

  2. एक हैशिंग एल्गोरिदम या कुछ प्रकार के क्रिप्ट() का उपयोग करके पासवर्ड को "एन्क्रिप्ट" करें। उपलब्ध हमले वैक्टरों के आधार पर यह विधि सादा टेक्स्ट स्टोरेज पर सुरक्षा के वास्तविक सुधार के तरीके में ज्यादा प्रदान नहीं कर सकती है।

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

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

। कुछ मामलों में पासवर्ड हैश का ज्ञान सिस्टम पहुंच के संदर्भ में पासवर्ड को जानना उतना ही बुरा हो सकता है।

0

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

अन्यथा, आपको एन्क्रिप्टेड पासवर्ड स्टोर करना होगा क्योंकि हैश पासवर्ड हैश से जुड़े प्रमाणीकरण के साथ काम नहीं कर सकता है। एन्क्रिप्शन के लिए, मेरे पास निम्नलिखित सुझाव हैं,

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