नमक, पासवर्ड और सुरक्षा

Question

मैंने इस बारे में SO पर कई प्रश्नों के माध्यम से पढ़ा है, लेकिन कई उत्तरों एक-दूसरे से विरोधाभास करते हैं या मुझे समझ में नहीं आता है।

आपको हमेशा एक हैश के रूप में एक पासवर्ड स्टोर करना चाहिए, कभी सादा पाठ के रूप में नहीं। लेकिन क्या आपको डेटाबेस में नमक पासवर्ड + नमक के बगल में नमक (प्रत्येक उपयोगकर्ता के लिए अद्वितीय) स्टोर करना चाहिए। यह मेरे लिए बहुत चालाक प्रतीत नहीं होता है क्योंकि किसी को डेटाबेस तक पहुंच नहीं मिल सकती है, व्यवस्थापक कहलाता है या कहां से पासवर्ड का काम करता है?

Answer 1

बहुत से लोग इंद्रधनुष तालिकाओं को रोकने के बिना "इंद्रधनुष तालिकाओं को रोकने के लिए" कह रहे हैं यह उन्हें रोकता है।

इंद्रधनुष सारणी बड़ी संख्या में हैश की प्रीकंप्यूटिंग करने का एक चालाक तरीका है और उन्हें कम स्मृति में कम से कम स्मृति में संग्रहीत करने की एक चालाक तरीका है, और आप उन्हें एक हैश को बहुत तेज़ करने के लिए उपयोग कर सकते हैं। hash = md5(password) और hash = sha1(password) जैसे नंगे कार्यों के लिए टेबल्स आम हैं।

हालांकि, उन्हें किसी भी हैश फ़ंक्शन के लिए जेनरेट किया जा सकता है जिसे output = f(input) के रूप में वर्णित किया जा सकता है। यदि आप सभी उपयोगकर्ता पासवर्ड के लिए साइट-व्यापी नमक का उपयोग करते हैं, उदाहरण के लिए hash = md5(salt+password), तो आप एक फ़ंक्शन f, f(password) = md5(salt+password) बना सकते हैं। इसलिए आप इस फ़ंक्शन के लिए इंद्रधनुष सारणी उत्पन्न कर सकते हैं, जिसमें काफी समय लगेगा, लेकिन फिर आपको डेटाबेस में हर पासवर्ड को तेज़ी से क्रैक करने देगा।

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

इसे पूरा करने के कई तरीके हैं।लोकप्रिय तरीकों में शामिल हैं:

• प्रत्येक उपयोगकर्ता, डेटाबेस में उनके अन्य विवरण के साथ संग्रहीत के लिए एक अलग नमक: hash = hashfunction(salt + password)
• एक वैश्विक नमक और प्रति उपयोगकर्ता कुछ अद्वितीय मूल्य: उदाहरण के लिए hash = hashfunction(salt + password + user_id)
• एक वैश्विक नमक और प्रति-उपयोगकर्ता नमक: hash = hashfunction(global_salt + user_salt + password)

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

अंत में, अपने वास्तविक सवाल का जवाब देने:

उपयोगकर्ता डेटा के बगल में नमक भंडारण हैश को कमजोर नहीं है। हैश फ़ंक्शन एक-तरफा हैं: पासवर्ड के हैश को देखते हुए, यहां तक ​​कि एक अनसुलझा भी, पासवर्ड को ढूंढना बहुत मुश्किल है। सलाम के पीछे प्रेरणा एक व्यक्तिगत हैश को अधिक सुरक्षित नहीं बनाना है, बल्कि कई हैंश का संग्रह अधिक सुरक्षित बनाना है। वहाँ अनसाल्टेड हैश का एक संग्रह के लिए हमले के कई वैक्टर हैं:

• इंद्रधनुष तालिकाओं
• आम पासवर्ड (123, password, god) Hashing और देख अगर किसी भी डेटाबेस में मौजूद है, और फिर उन खातों से छेड़छाड़
• डेटाबेस में समान हैश की तलाश करें, जिसका अर्थ है समान पासवर्ड (संभवतः)

Answer 2

नमक मौजूदा इंद्रधनुष को परेशान करने के लिए है। नमक को जानने के लिए यह कोई सुरक्षा खतरा नहीं है। यदि आप नमक जानते हैं, तो आपको अभी भी पासवर्ड जानना होगा।

Answer 3

सबसे पहले, नमक का प्राथमिक उद्देश्य पासवर्ड की ब्रूट-फोर्सिंग को अक्षम करना है, उदाहरण के लिए यह पासवर्ड के त्वरित समझौता के लिए इंद्रधनुष तालिकाओं के उपयोग को रोकता है।

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

$hashed_password = sha1($user_password . $user_salt . $static_salt); 

$user_salt डेटाबेस प्रत्येक उपयोगकर्ता के लिए अद्वितीय में नमक है, $static_salt नमक कहीं अपने कोड की सेटिंग्स में निर्दिष्ट है।

Answer 4

यदि आप नमक को स्टोर नहीं करते हैं, तो आप सही पासवर्ड प्रदान किए जाने पर कैसे जांचेंगे?

Answer 5

नमक का उपयोग उस समय को बढ़ाने के लिए किया जाता है जब किसी हमलावर को डेटाबेस में संग्रहीत हैश से मेल खाने वाला पासवर्ड ढूंढने के लिए खर्च करना पड़ता है। आम तौर पर इंद्रधनुष तालिका जैसे लुकअप टेबल (http://en.wikipedia.org/wiki/Rainbow_table देखें) इसे प्राप्त करने के लिए उपयोग किया जाता है।

लुकअप स्वयं की लागत का समय नहीं है, लेकिन इंद्रधनुष तालिका की गणना करने का समय क्या है। एक नमक जोड़ने से हमलावर को एक नई इंद्रधनुष तालिका को दोबारा लगाने के लिए मजबूर किया जाता है, भले ही यह हमलावर द्वारा ज्ञात हो, जो डेटाबेस

Answer 6

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

1. नमक क्यों?
2. क्यों नमक (पासवर्ड + नमक) के हैश के साथ नमक जमा किया जाता है।

मेरी समझ है।

1. हैकर्स के सभी शब्दकोश शब्दों के लिए इंद्रधनुष तालिका है जो उन्होंने महान प्रयास किए हैं। प्रत्येक इंद्रधनुष तालिका बनाने से हैकर से बाहर निकल जाता है। सरल शब्दों में यह बहुत कठिन है।
2. बिंदु 1 के अनुसार, यदि हम प्रत्येक उपयोगकर्ता के लिए हैकर गणना इंद्रधनुष तालिका बनाते हैं तो वह पासवर्ड जानता है जब तक वह बूढ़ा हो जाएगा। और यदि उपयोगकर्ता अक्सर पासवर्ड बदलता है, तो हैकर के भव्य बच्चे भी पासवर्ड को जानते समय पुराना हो जाएंगे।
3. ठीक है। तो प्रत्येक उपयोगकर्ता के लिए अलग नमक का उपयोग करें। यह हैकर हर उपयोगकर्ता के पासवर्ड को जानने के लिए अलग हमले का उपयोग करता है।
4. मुझे लगता है कि विभिन्न पाठकों ने बताया कि प्रत्येक उपयोगकर्ता पर सिर को धक्का देने के बजाय एक महान हैकर व्यवस्थापक खाते के प्रति अपना पूरा प्रयास करेगा और फिर वह किया जाएगा :)। तो इस मामले में, हम आगे एक कदम आगे बढ़ेंगे और फिर हैश की गणना करने के लिए कुछ अलग विधि का उपयोग करेंगे। आइए कहें कि नमक बिल्कुल ठीक नहीं है। यह वास्तविक हैश का आधा हो सकता है। दूसरा आधा किसी और तरीके से कहीं और संग्रहीत किया जाता है (किसी अन्य तरीके से गणना की जाती है)। यह सिर्फ एक अतिरिक्त सुरक्षा उपाय है। और हम वर्तमान समय में जानते हैं, कंप्यूटर की गणना शक्ति बढ़ रही है।तो नैतिक लोगों को पता है कि दुनिया के सबसे तेज़ सुपर कंप्यूटर में व्यवस्थापक पासवर्ड को तोड़ने के लिए 1 साल लगेंगे (केवल एक उदाहरण)। इसलिए वे एक नीति को मजबूर करते हैं जो हर 3 महीने में व्यवस्थापक पासवर्ड बदलता है। उस समय तक हैकर पुराने पासवर्ड को जानता है, नया प्रभाव प्रभावी है। या कहें कि डेटाबेस से समझौता किया गया है, तो अच्छे लोगों को उस समय तक पता चल जाता है जब हैकर पासवर्ड को दरकिनार करता है। और अच्छे लोगों को तब तक बातें changs (alogorithms ..sha1 SHA2 और अब sha3 के उन्नयन याद) .....

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

लें देखभाल ....