सर्वोत्तम प्रथाएँ: पासवर्डों को नमस्कार करना और उनकी नकल करना?

Question

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

hash_function($salt.hash_function($pepper.$password)) [multiple iterations]

चुने गए हैश एल्गोरिथ्म को अनदेखा करना (मैं चाहता हूं कि यह लवण और मिर्च की चर्चा हो और विशिष्ट एल्गोरिदम नहीं, लेकिन मैं एक सुरक्षित उपयोग कर रहा हूं), क्या यह एक सुरक्षित विकल्प है या मुझे कुछ अलग करना चाहिए? शर्तों से अपरिचित लोगों के लिए:

• एक नमक एक बेतरतीब ढंग से उत्पन्न मूल्य है जिसे आमतौर पर डेटाबेस में स्ट्रिंग के साथ संग्रहीत किया जाता है ताकि पासवर्ड को क्रैक करने के लिए हैश टेबल का उपयोग करना असंभव हो। जैसा कि प्रत्येक पासवर्ड का अपना नमक होता है, उन्हें क्रैक करने के लिए सभी को व्यक्तिगत रूप से क्रूर होना चाहिए; हालाँकि, जैसा कि नमक को पासवर्ड हैश के साथ डेटाबेस में संग्रहीत किया जाता है, डेटाबेस समझौता का मतलब दोनों को खोना है।

• एक काली मिर्च एक साइट चौड़ा स्थिर डेटाबेस (आमतौर पर आवेदन के स्रोत कोड में हार्ड-कोडेड) जो गुप्त में किया जाता है से अलग से संग्रहीत मूल्य है। इसका उपयोग इसलिए किया जाता है ताकि डेटाबेस का एक समझौता पूरे एप्लिकेशन की पासवर्ड तालिका को ब्रूट-फॉरसेबल न बना दे।

क्या ऐसा कुछ है जो मुझे याद आ रहा है और मेरे उपयोगकर्ता की सुरक्षा की रक्षा करने के लिए मेरे पासवर्ड को सबसे अच्छा विकल्प नमस्कार और पेप्परिंग कर रहा है? क्या इस तरह से करने के लिए कोई संभावित सुरक्षा दोष है?

नोट: चर्चा के उद्देश्य के लिए मान लें कि एप्लिकेशन और डेटाबेस अलग-अलग मशीनों पर संग्रहीत हैं, पासवर्ड आदि साझा न करें, इसलिए डेटाबेस सर्वर का उल्लंघन स्वचालित रूप से एप्लिकेशन सर्वर का उल्लंघन नहीं करता है।

Comments

नहीं काफी एक नकली है, लेकिन अत्यंत संबंधित: stackoverflow.com/questions/16594613/...

— ircmaxell

क्रॉस साइट डुप्लिकेट: Security.stackexchange.com/q/3272/2113

— जैको जूल

Answer 1

ठीक। देखकर रूप में मैं इस बारे में लिखने की जरूरत से अधिक और अधिक , मैं अकेला काली मिर्च पर एक आखिरी विहित जवाब कर देंगे।

मिर्च का अपसेंट

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

इसलिए इतने सारे लोग मानते हैं कि मिर्च एक अच्छा विचार है। यह समझ में आता है"।

मिर्च की वास्तविकता

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

और मिर्च न तो साबित करने योग्य और न ही बनाए रखने योग्य मॉडल ...

मिर्च के साथ सैद्धांतिक समस्याएं

अब जब हमने स्टेज सेट कर लिया है, तो आइए देखें कि क्या गलतियाँ होती हैं।

• एक हैश को दूसरे में खिलाना खतरनाक हो सकता है।

  अपने उदाहरण में, आप करते हैं hash_function($salt . hash_function($pepper . $password))।

  हम पिछले अनुभव से जानते हैं कि "हैश" करने से एक और हैश फ़ंक्शन में एक हैश परिणाम समग्र सुरक्षा को कम कर सकता है। कारण यह है कि दोनों हैश फ़ंक्शन हमले का लक्ष्य बन सकते हैं।

  यही कारण है कि PBKDF2 जैसे एल्गोरिदम उन्हें संयोजित करने के लिए विशेष ऑपरेशन का उपयोग करते हैं (उस मामले में एचएमएसी)।

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

  हालांकि यह विशुद्ध रूप से सैद्धांतिक लग सकता है, यह वास्तव में नहीं है। उदाहरण के लिए, Bcrypt मनमाना पासवर्ड स्वीकार नहीं कर सकता । तो पासिंग bcrypt(hash(pw), salt)वास्तव में एक कमजोर हैश की तुलना में परिणाम दे सकती है bcrypt(pw, salt)अगर hash()एक बाइनरी स्ट्रिंग लौटाता है।

• डिजाइन के खिलाफ काम करना

  जिस तरह से bcrypt (और अन्य पासवर्ड हैशिंग एल्गोरिदम) डिजाइन किए गए थे, वह एक नमक के साथ काम करना है। एक मिर्च की अवधारणा को कभी पेश नहीं किया गया था। यह एक तुच्छता जैसा लग सकता है, लेकिन ऐसा नहीं है। कारण यह है कि एक नमक एक रहस्य नहीं है। यह सिर्फ एक मूल्य है जो एक हमलावर को जाना जा सकता है। दूसरी ओर एक काली मिर्च, बहुत परिभाषा के द्वारा एक गुप्त रहस्य है।

  वर्तमान पासवर्ड हैशिंग एल्गोरिदम (bcrypt, pbkdf2, आदि) सभी को केवल एक गुप्त मूल्य (पासवर्ड) में लेने के लिए डिज़ाइन किया गया है। एल्गोरिथ्म में एक और रहस्य जोड़ना सभी में अध्ययन नहीं किया गया है।

  इसका मतलब यह नहीं है कि यह सुरक्षित नहीं है। इसका मतलब है कि हम नहीं जानते कि यह सुरक्षित है। और सुरक्षा और क्रिप्टोग्राफी के साथ सामान्य अनुशंसा यह है कि यदि हम नहीं जानते हैं, तो यह नहीं है।

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

• जटिलता सुरक्षा का दुश्मन है

  मानो या न मानो, जटिलता सुरक्षा का दुश्मन है । एक एल्गोरिथ्म बनाना जो जटिल दिखता है वह सुरक्षित हो सकता है, या यह नहीं हो सकता है। लेकिन संभावना काफी महत्वपूर्ण है कि यह सुरक्षित नहीं है।

मिर्च के साथ महत्वपूर्ण समस्याएं

• यह मेंटेनेंस योग्य नहीं है

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

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

  और आपके वर्तमान काली मिर्च के दृष्टिकोण की आवश्यकता होगी कि प्रत्येक उपयोगकर्ता को या तो अपना पासवर्ड पूरी तरह से रोटेशन द्वारा अमान्य कर दिया जाए, या प्रतीक्षा करें कि उनके अगले लॉगिन को घुमाए जाने तक (जो कभी नहीं हो सकता) ...

  जो मूल रूप से आपके दृष्टिकोण को तत्काल नो-गो बनाता है।

• यह आप अपनी खुद की क्रिप्टो रोल करने की आवश्यकता है

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

  कोई भी, सबसे क्लूलेस शौकिया से सर्वश्रेष्ठ क्रिप्टोग्राफर तक, एक एल्गोरिथ्म बना सकता है जिसे वह खुद नहीं तोड़ सकता।

  • ब्रूस श्नीयर

  कभी भी अपनी खुद की क्रिप्टो रोल ...

बेहतर तरीका है

इसलिए, उपरोक्त सभी समस्याओं में से, स्थिति को संभालने के दो तरीके हैं।

• जैसे ही वे मौजूद हैं एल्गोरिदम का उपयोग करें

  यदि आप सही तरीके से (उच्च लागत के साथ) bcrypt या scrypt का उपयोग करते हैं, तो सभी कमजोर शब्दकोश पासवर्ड सांख्यिकीय रूप से सुरक्षित होने चाहिए। 5 की लागत पर हैशिंग बिक्रिप का मौजूदा रिकॉर्ड 71k हैशेज है। उस दर पर भी एक 6 वर्ण यादृच्छिक पासवर्ड को क्रैक होने में वर्षों लगेंगे। और मेरी न्यूनतम अनुशंसित लागत 10 है, जो कि 32 के कारक से प्रति सेकंड हैश को कम करती है। इसलिए हम केवल 2200 हैश प्रति सेकंड के बारे में बात करेंगे। उस दर पर, यहां तक ​​कि कुछ शब्दकोश वाक्यांश या मापक भी सुरक्षित हो सकते हैं।

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

• संग्रहण से पहले आउटपुट हैश को एन्क्रिप्ट करें

  सुरक्षा क्षेत्र में एक एल्गोरिथ्म मौजूद है जिसे हमने ऊपर बताई गई हर चीज़ को संभालने के लिए डिज़ाइन किया है। यह एक ब्लॉक सिफर है। यह अच्छा है, क्योंकि यह प्रतिवर्ती है, इसलिए हम कुंजियों को घुमा सकते हैं (याय! रखरखाव!)। यह अच्छा है क्योंकि इसे डिजाइन के रूप में इस्तेमाल किया जा रहा है। यह अच्छा है क्योंकि यह उपयोगकर्ता को कोई जानकारी नहीं देता है।

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

टीएल / डॉ

मिर्च का उपयोग न करें। उनके साथ समस्याओं की एक मेजबान है, और दो बेहतर तरीके हैं: किसी भी सर्वर-साइड सीक्रेट का उपयोग नहीं करना (हाँ, यह ठीक है) और स्टोरेज से पहले एक ब्लॉक सिफर का उपयोग करके आउटपुट हैश को एन्क्रिप्ट करना।

Comments

हैश-मान एन्क्रिप्ट करने के उस अंतिम भाग को शामिल करने के लिए धन्यवाद, यह एक ऐसा उत्तर है जिससे मैं पूरी तरह सहमत हो सकता हूं। यदि एन्क्रिप्शन आपके पासवर्ड एपीआई का हिस्सा बन जाएगा, तो इसका उपयोग न करने का कोई कारण नहीं होगा, इसलिए हो सकता है ... (मैं इसके लिए दस्तावेज लिखना पसंद

— करूंगा

@martinstoeckli: मैं सरल हैशिंग एपीआई में एन्क्रिप्शन कदम जोड़ने के लिए सहमत नहीं होगा। कारण यह है कि रहस्यों (चाबियों) का भंडारण लोगों को एहसास होने से बहुत कठिन है, और अपने आप को पैर में गोली मारना काफी आसान है। 99.9% उपयोगकर्ताओं के लिए, कच्चे bcrypt सभी के लिए पर्याप्त है, लेकिन सबसे सरल पासवर्ड ...

— ircmaxell

@ सिरमाक्सेल - दूसरी तरफ, आप कुछ भी नहीं करेंगे। सबसे खराब स्थिति में, जब कुंजी ज्ञात हो जाती है, तो एक हमलावर को अभी भी BCrypt हैश (बिना एन्क्रिप्शन के समान स्थिति) को क्रैक करना होगा। यह डेटा एन्क्रिप्ट करने के लिए एक कुंजी संग्रहीत करने के समान नहीं है, यह सर्वर-साइड रहस्य को जोड़ने के बारे में है। यहां तक ​​कि एक हार्डकोड कुंजी उन कमजोर पासवर्डों की रक्षा करेगी, जब तक कि हमलावर का सर्वर / कोड पर कोई नियंत्रण न हो। यह स्थिति असामान्य नहीं है: एसक्यूएल-इंजेक्शन से अलग, बैकअप को भी छोड़ दिया जाता है, सर्वर को छोड़ दिया जाता है ... इस स्थिति को जन्म दे सकता है। बहुत सारे PHP उपयोगकर्ता होस्ट किए गए सर्वर पर काम करते हैं।

— मार्टिंकॉकली

@martinstoeckli मुझे यहाँ ircmaxwell के साथ सहमत होना होगा, मुझे नहीं लगता कि एन्क्रिप्शन पासवर्ड एपीआई में है। यद्यपि, यह ध्यान दिया जा सकता है कि अधिकतम सुरक्षा के लिए आपके हैश को एन्क्रिप्ट करना एक अतिरिक्त प्रावधान है जिसका उपयोग किया जा सकता है।

— 19

मेरे पास स्टोरेज से पहले आउटपुट के एन्क्रिप्शन के बारे में एक सवाल है। यदि मैं गलत नहीं हूं, तो एन्क्रिप्शन कुंजियों का उपयोग आमतौर पर संदेशों को विशिष्ट रूप से या क्षणिक रूप से एन्क्रिप्ट करने के लिए किया जाता है। यदि आपके पास 200,000 उपयोगकर्ता पासवर्ड हैं जो सभी एक ही कुंजी के साथ एन्क्रिप्ट किए गए हैं और एक साथ संग्रहीत हैं, तो क्या यह कुंजी पर हमला करना आसान नहीं है? आपके पास अब 200,000 संदेश हैं, केवल 1 या 2 की तुलना में

— अगमलेकर

Answer 2

मुट्ठी हम एक काली मिर्च के सटीक लाभ के बारे में बात करनी चाहिए :

• काली मिर्च कमजोर पासवर्ड को डिक्शनरी अटैक से बचा सकती है, विशेष स्थिति में, जहाँ हमलावर डेटाबेस (हैश से युक्त) को पढ़ता है, लेकिन मिर्ची के साथ सोर्स कोड तक पहुँच नहीं रखता है।

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

• प्रति पासवर्ड एक अद्वितीय नमक
• एक धीमी गति से हैशिंग एल्गोरिथ्म जैसे बीसीक्रिप्ट

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

दूसरा सवाल यह है कि मिर्ची कैसे लगाई जाए ?

काली मिर्च लगाने का अक्सर अनुशंसित तरीका है, पासवर्ड और काली मिर्च को हैश फ़ंक्शन में जाने से पहले संयोजित करना:

$pepperedPassword = hash_hmac('sha512', $password, $pepper);
$passwordHash = bcrypt($pepperedPassword);

एक और भी बेहतर तरीका है, हालांकि:

$passwordHash = bcrypt($password);
$encryptedHash = encrypt($passwordHash, $serverSideKey);

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

Comments

तो आप कहेंगे कि एक काली मिर्च सिर्फ नमक पर सुरक्षा को कम कर देता है? कैसे लागू करने में मदद के लिए धन्यवाद।

— ग्लिच डिज़ायर

@LightningDust - हाँ, यह कमजोर पासवर्ड के लिए करता है, जब तक काली मिर्च गुप्त रहती है। यह कुछ अच्छी तरह से परिभाषित प्रकार के खतरों को कम करता है।

— मार्टिंस्टेकली

@martinstoeckli निश्चित रूप से इसे लागू करने का एक अच्छा तरीका है। यह देखने के लिए अच्छा है कि कुछ सुरक्षा अनुभव वाला कोई व्यक्ति इस पद्धति का समर्थन करता है। क्या MySQL AES_ENCRYPT($passwordHash, $serverSideKey)कॉल भी इसे लागू करने का एक उचित तरीका होगा?

— foochow

@Foo_Chow - मुझे MySQL फ़ंक्शन के कार्यान्वयन का पता नहीं है, लेकिन ऐसा लगता है कि उन्होंने IV-वेक्टर से बचने के लिए ईबीसी मोड का उपयोग किया है। ज्ञात प्लेटेक्स्ट के साथ (हैश-वैल्यू हमेशा एक ही अक्षर से शुरू होते हैं), यह एक समस्या हो सकती है। मेरे होमपेज पर मैंने एक उदाहरण कार्यान्वयन प्रकाशित किया, जो इस एन्क्रिप्शन को संभालता है।

— मार्टिंकॉक्ली

@martinstoeckli दिलचस्प, अवधारणाओं से भी परिचित नहीं; हालांकि ऐसा लगता है कि IV सबसे मजबूत परिणामों के लिए वांछनीय होगा। जोड़ा लाभ के लिए अधिक उपरिशायी जोड़ने के लिए नहीं लगता है।

— फूचो

Answer 3

नमक और काली मिर्च का बिंदु एक पूर्व-गणना पासवर्ड देखने की लागत में वृद्धि करना है, जिसे इंद्रधनुष तालिका कहा जाता है।

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

एक काली मिर्च की बात यह है कि आपकी पासवर्ड सूची को अद्वितीय रूप से हैक करने के लिए आवश्यक इंद्रधनुष तालिका बनाना। इस प्रकार इंद्रधनुष तालिका के निर्माण के लिए हमलावर पर अधिक समय बर्बाद करना।

हालांकि नमक का बिंदु प्रत्येक उपयोगकर्ता के लिए इंद्रधनुष तालिका बनाना है जो उपयोगकर्ता के लिए अद्वितीय है, आगे हमले की जटिलता को बढ़ाता है।

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

Comments

तो क्या एक नमक + मिर्च सिर्फ एक नमक से ज्यादा सुरक्षा प्रदान करता है? या क्या मैं काली मिर्च को छोड़ना और स्क्रीप्ट के अधिक पुनरावृत्तियों को चलाना बेहतर होगा?

— ग्लिच डिज़ायर

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

— रिचर्ड

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

— एरन

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

— ग्लिच डिज़ायर

Answer 4

किसी भी सुरक्षा प्रासंगिकता के रूप में अपने स्रोत कोड में हार्डकोड मान संग्रहीत करने को नहीं देख सकते। यह अस्पष्टता के माध्यम से सुरक्षा है।

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

Comments

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

— एरन

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

— रिचर्ड

साल्ट एक तरह से कार्य हैं, यहां तक ​​कि एक पासवर्ड को सफलतापूर्वक संचालित करने के लिए भी आपको केवल उस पासवर्ड को देना होगा, और आपको काली मिर्च का मूल्य स्वयं प्राप्त करने में मदद नहीं करेगा।

— ग्लिच इच्छा

@LightningDust मुझे लगता है कि आप का मतलब है "हैश ट्रैफिक फ़ंक्शंस हैं"। हाँ अपने नमक और / या काली मिर्च का सुरक्षित हैश से पता लगाना असंभव है (वास्तव में यह सुरक्षित हैश की परिभाषा है)।

— एरन

@ एरॉन सिक्योरिटी थ्रू ऑब्सुरिटी रक्षा की एक परत के रूप में इस्तेमाल की जाने वाली एक वैध तकनीक हो सकती है। मुद्दा यह है कि इसे कभी भी एक रक्षा के रूप में भरोसा नहीं किया जाना चाहिए , बल्कि इसका उपयोग "एक हमलावर को धीमा" करने के लिए किया जाता है। अगर ऐसा नहीं होता तो हनीपोट जैसी चीज का इस्तेमाल नहीं किया जाता। इसके बजाय, हम धीमी गति से हमलावरों की मदद करने के लिए अस्पष्टता के माध्यम से सुरक्षा का प्रभावी उपयोग कर सकते हैं, जब तक कि हम अपने आवेदन की सुरक्षा के लिए उस पर निर्भर नहीं होते हैं।

— ircmaxell