डेटाबेस में पासवर्ड स्टोर करने के बारे में

आज हम देखेंगे कि किसी डेटाबेस में पासवर्ड को कैसे स्टोर किया जाए और जाने-माने प्लेटफॉर्म इस समस्या को कैसे हल करें।

प्लेन

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

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

एन्क्रिप्शन हाशिंग

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

1. श्रम इनपुट। एन्क्रिप्शन में अधिक समय लगता है, और इससे कोई फर्क नहीं पड़ता कि हम कौन सा रूपांतरण चुनते हैं, यह हर पासवर्ड की जाँच के साथ करना होगा। हैश कार्यों के लिए आवश्यकताओं में से एक निष्पादन की गति है।
2. आउटपुट मान की लंबाई। एन्क्रिप्शन परिणाम लंबाई में परिवर्तनशील है, हैश परिणाम हमेशा समान होता है, और डेटाबेस में एक समान डेटा संग्रहीत करना बहुत सुविधाजनक होता है। इस तथ्य का उल्लेख नहीं करने के लिए कि एन्क्रिप्टेड रूप में पासवर्ड की लंबाई मूल पासवर्ड की लंबाई के बारे में कुछ जानकारी देगी। एक ही लंबाई, हालांकि, टकराव की संभावना की ओर जाता है, लेकिन इसके नीचे और अधिक।
3. प्रमुख प्रबंधन। एन्क्रिप्शन के लिए एक कुंजी की आवश्यकता होती है, जिसे कहीं न कहीं संग्रहीत करना होगा और आशा है कि कोई भी इसे नहीं पाएगा। किसी भी मामले में, मुख्य पीढ़ी और प्रबंधन एक अलग कहानी है (उन्हें कमजोर नहीं होना चाहिए, उन्हें नियमित रूप से बदलने की आवश्यकता है, और इसी तरह)।
4. संघर्ष की संभावना। एन्क्रिप्ट करते समय, विभिन्न इनपुट डेटा से आउटपुट हमेशा अलग होगा। हैशिंग के साथ, यह हमेशा ऐसा नहीं होता है। एक निरंतर हैश लंबाई का मतलब है कि हैश फ़ंक्शन के आउटपुट मानों का सेट सीमित है, जिससे टकराव की संभावना होती है। यही है, मान लें कि उपयोगकर्ता वास्तव में भ्रमित हो गया है और वास्तव में एक शांत लंबे पासवर्ड के साथ आया है, जिसमें निचले और ऊपरी मामले में विशेष वर्ण, संख्या और अक्षर हैं। हमलावर पासवर्ड फ़ील्ड में कोई कम कूल पासवर्ड "व्यवस्थापक" दर्ज नहीं करता है। सर्वर ने हैश की जाँच और तुलना के लिए इसे हैशड किया। हैश मेल हुआ। यह शर्म की बात है।

इस प्रकार, 3: 1 के स्कोर के साथ, हैशिंग जीत जाता है। लेकिन क्या वहां रुकना संभव है?
जवाब है नहीं।

पासवर्ड अटैच किए गए

इसलिए, हमलावर को उपयोगकर्ता नाम और पासवर्ड के साथ हमारी तालिका मिली। पासवर्ड अब हैश किए गए हैं, लेकिन यह हमारे हमलावर को नहीं रोकता है, और वह गंभीरता से उन्हें ठीक करने का इरादा रखता है। उनके संभावित कार्य:

• डिक्शनरी बल: यदि हमलावर प्रशासक के मास्टर पासवर्ड के साथ सफल नहीं होता है, तो वह लोकप्रिय पासवर्डों के शब्दकोश में बदल जाएगा और अपने हैश के साथ अपनी किस्मत आज़माएगा;
• इंद्रधनुष सारणी: सामान्य तौर पर, शायद उसे कुछ भी गणना करने और शब्दकोश के माध्यम से क्रमबद्ध करने की आवश्यकता नहीं होगी। यह नेटवर्क पर पड़े इंद्रधनुष तालिकाओं को चालू करने के लिए पर्याप्त होगा। इंद्रधनुष सारणी में पहले से ही किसी के द्वारा गणना की गई हैश मूल्य और उनके संबंधित इनपुट डेटा शामिल हैं। यह ध्यान रखना महत्वपूर्ण है कि टकराव के कारण, इंद्रधनुष तालिका की पेशकश करने वाला पासवर्ड जरूरी नहीं होगा कि उपयोगकर्ता उपयोग करता है। परिकलित मान MD5, SHA1, SHA256, SHA512 के साथ-साथ उनके संशोधनों और कुछ अन्य लोगों के लिए पहले से ही हैं। आप हैश को उलटने की कोशिश कर सकते हैं, उदाहरण के लिए, यहाँ ;
• संपूर्ण खोज: यदि यह मदद नहीं करता है, तो आपको एक पंक्ति में सभी संभावित पासवर्ड के माध्यम से ब्रूट बल का सहारा लेना होगा और गणना करनी होगी जब तक कि गणना की गई हैश मैच न हो जाए।

सबसे सामान्य मामले में, एक हमलावर को पासवर्ड क्रैक करना होगा। और यहां इसकी सफलता अन्य चीजों के बीच, हैश फ़ंक्शन की गणना की गति पर निर्भर करेगी। हैश के समय की तुलना यहां की जा सकती है । उदाहरण के लिए, जावा-कार्यान्वित हैश में 64-बिट विंडोज 10 पर 1 कोर इंटेल i7 2.60GHz और 16GB रैम के साथ 36-वर्ण हैश की गणना करने के लिए एक लाख बार चलाया गया था। उन्होंने निम्नलिखित परिणाम दिखाए:

एमडी 5 - 627 एमएस
SHA-1 - 604 मि
SHA-256 - 739 एमएस
SHA-512 - 1056 एमएस

लेकिन आज bruteforce को समानांतर किया जा सकता है और GPU (साथ ही APU, DSP और FPG3) पर कई बार तेजी से चलाया जा सकता है। हालांकि, एक लंबा एल्गोरिथ्म और एक लंबा आउटपुट चुनने के अलावा, आप कुछ और कर सकते हैं।

हैश हैश

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

"

स्वादानुसार नमक डालें

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

1. नमस्कार के सिद्धांत के अनुसार:

• प्रत्येक उपयोगकर्ता के लिए एक अद्वितीय नमक: प्रत्येक उपयोगकर्ता के लिए अलग - इस तरह, यदि नमक हमलावर को ज्ञात हो जाता है, तो प्रत्येक पासवर्ड को व्यवस्थित करना होगा। और इसके अलावा, भले ही दो उपयोगकर्ता एक ही तरह से सोचते हैं और समान पासवर्ड के साथ आते हैं, फिर भी आउटपुट में हैश अलग होगा;
• वैश्विक नमक: सभी के लिए समान, सभी हैश के लिए उपयोग किया जाता है;
• दोनों कि, और एक और।

2. नमक के भंडारण की विधि के अनुसार:

• डेटाबेस में: एक नियम के रूप में, व्यक्तिगत लवण को पासवर्ड हैश के रूप में उसी डेटाबेस में संग्रहीत किया जाता है; अक्सर एक ही पंक्ति पर भी;
• कोड में (पढ़ें: कॉन्फ़िगरेशन में): वैश्विक नमक आमतौर पर डेटाबेस में संग्रहीत नहीं किया जाता है, लेकिन, उदाहरण के लिए, कॉन्फ़िगरेशन में, ताकि उल्लंघनकर्ता को इसके चयन पर समय बिताना पड़े।

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

1. वह वैश्विक नमक को नहीं जानता है, इसलिए इसे क्रूर बनाना होगा।
2. वह उपयोगकर्ताओं के लवण जानता है, लेकिन उसने इन लवणों के साथ तालिकाओं को तैयार नहीं किया है, इसलिए उसे पासवर्ड दरार करने होंगे।
3. इस प्रक्रिया को इस तथ्य के कारण और भी अधिक समय लगेगा कि आपको n हैश को कई बार हैश करना होगा।

पासवर्ड विभिन्न CMS को कैसे स्टोर करते हैं

Wordpress

संस्करण 3.x से पहले, पासवर्ड एमडी 5 के साथ बस हैशेड थे। अब फॉग लाइब्रेरी का उपयोग किया जाता है। डिफ़ॉल्ट रूप से, नमक सामने पासवर्ड को सौंपा गया है और परिणामस्वरूप स्ट्रिंग को MD5 2 ^ 8 बार हैश किया गया है।

जूमला

संस्करण 1.0.12 से पहले, बस एमडी 5 का उपयोग किया गया था। फॉग लाइब्रेरी का उपयोग डिफ़ॉल्ट रूप से नमक और 2 ^ 10 पुनरावृत्ति के साथ किया जाता है।

Drupal

बिना नमक के संस्करण 6 md5 तक। फॉग लाइब्रेरी का उपयोग किया जाता है। डिफ़ॉल्ट 2 ^ 16 repetitions के साथ sha512 नमकीन है।

Silverstripe

2 ^ 10 प्रतिनिधि के साथ नमकीन ब्लोफिश का उपयोग करता है।

Umbraco

नमक के साथ HMACSHA256 का उपयोग करता है। कॉन्फ़िगरेशन में निर्दिष्ट दूसरे वैश्विक नमक का उपयोग करता है।