2012-11-15 16 views
9

मान्य करें मैं सी # के लिए नया हूं और यह मेरा पहला प्रश्न है इसलिए मैं किसी भी गलत पैस के लिए पहले से माफ़ी मांगता हूं।नमकीन हैश

प्रसंग:

जब कोई उपयोगकर्ता रजिस्टरों मैं CreateSaltedHash() विधि कॉल और पाठ क्षेत्र से यह उपयोगकर्ता इनपुट पासवर्ड गुजरती हैं। यह विधि मेरी उपयोगकर्ता तालिका के पासवर्ड कॉलम में संग्रहीत करने से पहले पासवर्ड को लेट और हश करती है।

प्रश्न:

मैं कैसे पासवर्ड सत्यापित करना चाहिए एक उपयोगकर्ता में लॉग इन करने का प्रयास करते समय?

यदि मैं फिर से CreateSaltedHash() विधि को कॉल करता हूं तो यह यादृच्छिक नमक के कारण मेल नहीं खाएगा।

क्या मुझे एक अलग कॉलम में लवण संग्रहित करना चाहिए? क्या मुझे नमकीन हैश उत्पन्न करते समय एक डिलीमीटर का उपयोग करना चाहिए? नमकीन और धोए गए पासवर्ड के खिलाफ इनपुट पासवर्ड को सत्यापित करने का सबसे सुरक्षित तरीका क्या है?

कोड: यह मेरे पास अब तक है।

public class PasswordHash 
{ 
    public const int SALT_BYTES = 32; 

    /* 
    * Method to create a salted hash 
    */ 
    public static byte[] CreateSaltedHash(string password) 
    { 
     RNGCryptoServiceProvider randromNumberGenerator = new RNGCryptoServiceProvider(); 
     byte[] salt = new byte[SALT_BYTES]; 
     randromNumberGenerator.GetBytes(salt); 
     HashAlgorithm hashAlgorithm = new SHA256Managed(); 
     byte[] passwordByteArray = Encoding.UTF8.GetBytes(password); 
     byte[] passwordAndSalt = new byte[passwordByteArray.Length + SALT_BYTES]; 
     for (int i = 0; i < passwordByteArray.Length; i++) 
     { 
      passwordAndSalt[i] = passwordByteArray[i]; 
     } 
     for (int i = 0; i < salt.Length; i++) 
     { 
      passwordAndSalt[passwordByteArray.Length + i] = salt[i]; 
     } 
     return hashAlgorithm.ComputeHash(passwordAndSalt); 
    } 

    public static bool OkPassword(string password) 
    { 
     //This is where I want to validate the password before logging in. 
    } 
} 


रजिस्टर कक्षा में विधि कॉलिंग। भविष्य तुलना के लिए फिर से उपयोग फिर उसी नमक -

User user= new User(); 
user.password = PasswordHash.CreateSaltedHash(TextBoxUserPassword.Text); 
+0

'क्या मुझे एक अलग कॉलम में लवण संग्रहित करना चाहिए' - हां। फिर उस पर संदर्भित किया। – TheGeekZn

+0

आप समझते हैं कि आपकी हैशिंग विधि के साथ कोई गंभीर समस्या है? पासवर्ड को सुरक्षित करने के लिए आपको वास्तव में एक हैशिंग एल्गोरिदम डिज़ाइन का उपयोग करना चाहिए, आपकी वर्तमान पसंद एक अच्छी पसंद नहीं है। –

+0

मैंने आपका शीर्षक संपादित किया है। कृपया देखें, "[प्रश्नों में उनके शीर्षक में" टैग "शामिल होना चाहिए?] (Http://meta.stackexchange.com/questions/19190/)", जहां आम सहमति है "नहीं, उन्हें नहीं करना चाहिए"। –

उत्तर

1

जब आप पहली बार हैश तैयार करते हैं तो दोनों नमक और अंतिम हैश स्टोर करने के लिए की जरूरत है।

तो आप अपना CreateSaltedHash पासवर्ड और नमक लेने के लिए विधि बदल देंगे, और एक नया CreateSalt विधि को नमक उत्पन्न करने के लिए लिखते हैं जब अंतिम हैश के साथ संग्रहीत किया जाता है।

0

क्या मुझे एक अलग कॉलम में लवण संग्रहित करना चाहिए?

हां।

क्या मुझे नमकीन हैश उत्पन्न करते समय एक डिलीमीटर का उपयोग करना चाहिए?

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

नमकीन और धोए गए पासवर्ड के खिलाफ इनपुट पासवर्ड को सत्यापित करने का सबसे सुरक्षित तरीका क्या है?

SHA512, SHA-2 या -3 SHA256 से अधिक सुरक्षित होंगे, लेकिन क्या आपको और अधिक सुरक्षा की आवश्यकता है?

0

आप या तो नमक स्टोर कर सकते हैं, या एक ही नमक हर बार का उपयोग करें:

कुछ पृष्ठभूमि जानकारी प्राप्त करने के लिए इस लेख का संदर्भ लें। मैं नमक भंडारण की सलाह देता हूं क्योंकि यह सभी उपयोगकर्ताओं में एक ही नमक का उपयोग करने से अधिक सुरक्षित है।

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

0

और अब उत्तर के लिए - है

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

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

तो, आपको डेटाबेस में एन्क्रिप्टेड पासवर्ड, साथ ही साथ संबंधित हैश को स्टोर करने की आवश्यकता होगी।

यह पासवर्ड सत्यापित करने के लिए आवश्यक सभी जानकारी एकत्र करने का तरीका होगा।

0

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

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

+1

यदि आपके पास प्रत्येक पासवर्ड के लिए एक अलग, अद्वितीय नमक है, तो हैकर के लिए कई पासारों को क्रैक करना अधिक कठिन हो जाता है। – Polyfun

+0

हां, लेकिन यदि आप डेटाबेस पर हैं तो आपको अद्वितीय लवण को स्टोर करने की आवश्यकता है, तो हैकर उन्हें इतना तथ्य देगा कि वे अलग हैं तो अप्रासंगिक है। –

+3

ऐसा नहीं है, क्योंकि यदि लवण अद्वितीय हैं, तो यह कई पासवर्ड क्रैक करने के लिए और अधिक महंगा हो जाता है, खासकर बीसीआरपीटी जैसे कुछ का उपयोग करना - कृपया देखें http://www.codinghorror.com/blog/2012/04/speed-hashing.html । – Polyfun

1

अन्य उत्तरों के अनुसार राज्य; हां आपको नमक को स्टोर करना चाहिए या उदाहरण के लिए उपयोगकर्ता नाम प्राप्त करना चाहिए।

आपको इसे और अधिक सुरक्षित बनाने के लिए Rfc2898DeriveBytes का भी उपयोग करना चाहिए।

यहाँ उस विषय पर एक अच्छा लेख है: Password salt and hashing in C#

3

आप Bcrypt.Net इस्तेमाल कर सकते हैं; वास्तव में सुरक्षित होने के लिए इसमें बहुत सी सिफारिशें हैं, साथ ही इसका उपयोग करना बहुत आसान है।जैसा कि मैं इसे समझता हूं, जब आप पासवर्ड बनाते हैं तो यह स्वचालित रूप से आपके लिए एक अद्वितीय नमक उत्पन्न करता है, जिसे बाद में हैश पासवर्ड स्ट्रिंग में संग्रहीत किया जाता है; इसलिए आप नमक को अलग से स्टोर नहीं करते हैं, लेकिन उसी क्षेत्र में हैश पासवर्ड के रूप में। बिंदु यह है कि प्रत्येक पासवर्ड में इसका नमक होता है, जो एक हैकर के लिए कई पासवर्ड क्रैक करने में अधिक कठिन (समय लेने वाला) बनाता है। एल्गोरिदम बीक्रिप्ट का उपयोग भी सीपीयू गहन है, इसलिए इसे क्रैक करने के लिए बहुत सी कम्प्यूटेशनल पावर (= पैसा) की आवश्यकता होती है।

जेफ एटवुड (स्टैक ओवरफ्लो मॉडरेटर) recommends Bcrypt

0

आपको पाचन और नमक को बचाया जाना चाहिए। पुनरावृत्तियों और पाचन लम्बाई मान आपके आवेदन में स्थिरांक हो सकते हैं।

byte[] getNewSalt(Int32 size) 
{ 
    RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider(); 
    byte[] salt = new byte[size]; 
    rng.GetBytes(salt); 
    return salt; 
} 


byte[] getPasswordDigest(byte[] value, byte[] salt, Int32 iterations, Int32 digestLength) 
{ 
    Rfc2898DeriveBytes deriveBytes = new Rfc2898DeriveBytes(value, salt, iterations); 
    return deriveBytes.GetBytes(digestLength); 
} 

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

1

मैं आपको सर्विसस्टैक के सॉल्टेडशैश का उपयोग करने का सुझाव देता हूं जिसे आप इसे अपने Nuget से इंस्टॉल कर सकते हैं। बस अपने Nuget कंसोल में Install-Package ServiceStack दर्ज करें, तो आप अपने कोड में निम्नलिखित आयात का उपयोग करने में सक्षम होंगे।

using ServiceStack.ServiceInterface.Auth; 

और फिर आप अपने नमक और हैश इतना आसान और पूरी तरह से तेजी से पहले की तुलना में उत्पन्न होगा। बस निम्नलिखित कोड दर्ज करें:

class Security 
{ 
    ... 
    public void generate(string Password) 
    { 
    string hash, salt; 
    new SaltedHash().GetHashAndSaltString(Password,out hash,out salt); 
    //Store the hash and salt 
    } 
    ... 
} 

और हाँ, आप चाहिए दुकान हैश और नमक अपने OkPassword विधि को चलाने के लिए सक्षम होने के लिए।

public bool OkPassword(string Password) 
{ 
    var hash = //getStoredHash 
    var salt = //getStoredSalt 
    bool verify = new SaltedHash().VerifyHashString(Password, hash , salt); 
    return verify ; 
} 
संबंधित मुद्दे