PHP पासवर्ड के लिए सुरक्षित हैश और नमक




security passwords (10)

अस्वीकरण : यह उत्तर 2008 में लिखा गया था।

तब से, PHP ने हमें php.net/manual/en/function.password-hash.php और password_verify दिया है और, उनके परिचय के बाद, वे अनुशंसित पासवर्ड हैशिंग और जांच विधि हैं।

हालांकि उत्तर का सिद्धांत अभी भी एक अच्छा पढ़ा है।

टी एल; डॉ

क्या न करें

  • पासवर्ड के लिए उपयोगकर्ता कौन से अक्षर दर्ज कर सकते हैं सीमित न करें। केवल बेवकूफ यह करते हैं।
  • पासवर्ड की लंबाई सीमित न करें। यदि आपके उपयोगकर्ता supercalifragilisticexpialidocious के साथ एक वाक्य चाहते हैं, तो उन्हें इसका उपयोग करने से रोकें।
  • सादे-पाठ में अपने उपयोगकर्ता का पासवर्ड कभी भी स्टोर न करें।
  • अपने उपयोगकर्ता को पासवर्ड कभी भी ईमेल न करें, सिवाय इसके कि जब उन्होंने अपना खो दिया है, और आपने एक अस्थायी भेजा है।
  • किसी भी तरह से पासवर्ड कभी भी लॉग न करें।
  • SHA1 या MD5 या यहां तक ​​कि SHA256 के साथ कभी हैश पासवर्ड नहीं! आधुनिक क्रैकर्स 60 और 180 अरब हैश / सेकेंड (क्रमशः) से अधिक हो सकते हैं।
  • Bcrypt और हैश () के कच्चे आउटपुट के साथ मिश्रण न करें, या तो हेक्स आउटपुट या base64_encode का उपयोग करें। (यह किसी भी इनपुट पर लागू होता है जिसमें इसमें एक दुष्ट \0 हो सकता है, जो सुरक्षा को गंभीर रूप से कमजोर कर सकता है।)

डॉस

  • जब आप कर सकते हैं स्क्रिप का प्रयोग करें; यदि आप नहीं कर सकते तो bcrypt।
  • यदि आप SHA2 हैश के साथ या तो bcrypt या scrypt का उपयोग नहीं कर सकते हैं तो PBKDF2 का उपयोग करें।
  • जब डेटाबेस से समझौता किया जाता है तो सभी के पासवर्ड रीसेट करें।
  • उचित 8-10 वर्ण न्यूनतम लंबाई लागू करें, साथ ही कम से कम 1 ऊपरी केस लेटर, 1 लोअर केस लेटर, एक नंबर और एक प्रतीक की आवश्यकता होती है। इससे पासवर्ड की एन्ट्रॉपी में सुधार होगा, जिससे बदले में इसे क्रैक करना मुश्किल हो जाएगा। (कुछ बहस के लिए "क्या अच्छा पासवर्ड बनाता है?" अनुभाग देखें।)

वैसे भी हैश पासवर्ड क्यों?

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

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

व्हाईटहाट सिक्योरिटी के सीटीओ यिर्मयाह ग्रॉसमैन ने हाल ही में पासवर्ड रिकवरी के बाद अपने ब्लॉग पर कहा कि उनके पासवर्ड सुरक्षा के क्रूर बल को तोड़ने की आवश्यकता है:

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

(जोर मेरा।)

क्या वैसे भी एक अच्छा पासवर्ड बनाता है?

Entropy (ऐसा नहीं है कि मैं पूरी तरह से रैंडल के दृष्टिकोण की सदस्यता लेता हूं।)

संक्षेप में, एन्ट्रॉपी यह है कि पासवर्ड के भीतर कितनी भिन्नता है। जब पासवर्ड केवल लोअर अक्षरों को कम करता है, तो यह केवल 26 वर्ण हैं। यह बहुत भिन्नता नहीं है। अल्फा-न्यूमेरिक पासवर्ड 36 वर्णों के साथ बेहतर होते हैं। लेकिन प्रतीकों के साथ, ऊपरी और निचले मामले की अनुमति, लगभग 96 वर्ण है। यह सिर्फ अक्षरों से बहुत बेहतर है। एक समस्या यह है कि, हमारे पासवर्ड यादगार बनाने के लिए हम पैटर्न डालते हैं-जो एन्ट्रॉपी को कम करता है। ऊप्स!

पासवर्ड एन्ट्रॉपी आसानी से approximated है। एएससीआई वर्णों की पूरी श्रृंखला (लगभग 96 टाइप करने योग्य पात्र) का उपयोग करके प्रति चरित्र 6.6 की एंट्रॉपी उत्पन्न होती है, जो भविष्य में सुरक्षा के लिए पासवर्ड के लिए 8 वर्णों पर अभी भी बहुत कम है (एंट्रॉपी के 52.679 बिट्स)। लेकिन अच्छी खबर यह है: लंबे पासवर्ड, और यूनिकोड वर्णों के साथ पासवर्ड, वास्तव में पासवर्ड की एन्ट्रॉपी बढ़ाते हैं और इसे क्रैक करना कठिन बनाते हैं।

Crypto StackExchange साइट पर पासवर्ड एन्ट्रॉपी की लंबी चर्चा है। एक अच्छी Google खोज भी बहुत सारे परिणाम बदलेगी।

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

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

सर्वोत्तम प्रथाएं

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

मैं अत्यधिक क्रिप्ट फ़ंक्शन के लिए प्रलेखन पढ़ने का सुझाव देता हूं यदि आप समझना चाहते हैं कि bcrypt का उपयोग कैसे करें, या स्वयं को एक good wrapper openwall.com/phpass या अधिक विरासत कार्यान्वयन के लिए openwall.com/phpass जैसे कुछ का उपयोग करें। मैं कम से कम 12 राउंड की सिफारिश करता हूं, अगर 15 से 18 नहीं।

मैंने bcrypt का उपयोग करने के बारे में अपना मन बदल दिया जब मैंने सीखा कि bcrypt केवल परिवर्तनीय लागत तंत्र के साथ blowfish के मुख्य शेड्यूल का उपयोग करता है। उत्तरार्द्ध आपको ब्लाफिश के पहले से महंगे कुंजी शेड्यूल को बढ़ाकर पासवर्ड को ब्रूट-फोर्स करने की लागत बढ़ाने देता है।

औसत प्रथाओं

मैं लगभग इस स्थिति की कल्पना नहीं कर सकता। openwall.com/phpass PHP 3.0.18 से 5.3 का समर्थन करता है, इसलिए यह लगभग हर इंस्टॉलेशन को कल्पना करने योग्य है-और यदि आप निश्चित रूप से यह नहीं जानते कि आपका पर्यावरण bcrypt का समर्थन करता है तो इसका उपयोग किया जाना चाहिए।

लेकिन मान लीजिए कि आप bcrypt या PHPASS का उपयोग नहीं कर सकते हैं। फिर क्या?

PDKBF2 कार्यान्वयन का प्रयास करें जिसमें आपके पर्यावरण / एप्लिकेशन / उपयोगकर्ता-धारणा बर्दाश्त कर सकते हैं। सबसे कम संख्या में मैं अनुशंसा करता हूं 2500 दौर है। साथ ही, hash_hmac() का उपयोग करना सुनिश्चित करें यदि यह ऑपरेशन को पुन: उत्पन्न करने के लिए कठिन बनाने के लिए उपलब्ध है।

भविष्य के व्यवहार

PHP 5.5 में आ रहा एक पूर्ण पासवर्ड सुरक्षा लाइब्रेरी है जो bcrypt के साथ काम करने के किसी भी दर्द को दूर करता है। जबकि हम में से ज्यादातर सबसे आम वातावरण में PHP 5.2 और 5.3 के साथ फंस गए हैं, विशेष रूप से साझा मेजबान, @ircmaxell ने आने वाले एपीआई के लिए एक संगतता परत बनाई है जो PHP 5.3.7 के लिए पिछड़ा संगत है।

क्रिप्टोग्राफी रिकैप और डिसक्लेमर

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

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

अंत में: मैं एक क्रिप्टोग्राफर नहीं हूँ। जो भी मैंने कहा है वह मेरी राय है, लेकिन मुझे लगता है कि यह अच्छा ओल 'सामान्य ज्ञान ... और बहुत सी पढ़ाई पर आधारित है। याद रखें, जितना संभव हो उतना पागल हो, चीजों को यथासंभव घुसपैठ करना मुश्किल हो, और फिर, यदि आप अभी भी चिंतित हैं, तो एक सफेद-टोपी हैकर या क्रिप्टोग्राफर से संपर्क करें ताकि वे आपके कोड / सिस्टम के बारे में क्या कह सकें।

https://code.i-harness.com

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

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

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

  1. हैशिंग तंत्र PHP में उपलब्ध होना चाहिए
  2. यह सुरक्षित होना चाहिए
  3. यह नमक का उपयोग कर सकता है (इस मामले में, सभी नमक समान रूप से अच्छे हैं? क्या अच्छा लवण उत्पन्न करने का कोई तरीका है?)

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

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

संबंधित प्रश्न जो मेरे प्रश्न को काफी कवर नहीं करते हैं:

PHP में एसएचए और एमडी 5 के बीच क्या अंतर है
सरल पासवर्ड एन्क्रिप्शन
कुंजी भंडारण के सुरक्षित तरीके, asp.net के लिए पासवर्ड
आप टोमकैट 5.5 में नमकीन पासवर्ड कैसे कार्यान्वित करेंगे


Google का कहना है कि SHA256 PHP के लिए उपलब्ध है।

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


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


एक बहुत छोटा और सुरक्षित जवाब - अपना पासवर्ड तंत्र बिल्कुल लिखें , एक कोशिश की और परीक्षण तंत्र का उपयोग करें।

  • PHP 5.5 या उच्चतर: php.net/manual/en/function.password-hash.php अच्छी गुणवत्ता और PHP कोर का हिस्सा है।
  • पुराने PHP संस्करण: openwall.com/phpass की openwall.com/phpass लाइब्रेरी अधिकांश कस्टम कोड से कहीं अधिक बेहतर है - वर्डप्रेस, ड्रूपल इत्यादि में उपयोग की जाती है।

अधिकतर प्रोग्रामर के पास कमजोरियों को पेश किए बिना क्रिप्टो से संबंधित कोड को सुरक्षित रूप से लिखने की विशेषज्ञता नहीं है।

त्वरित स्व-परीक्षण: पासवर्ड क्या खींच रहा है और आप कितने पुनरावृत्तियों का उपयोग करना चाहिए? यदि आपको उत्तर नहीं पता है, तो आपको password_hash() उपयोग करना चाहिए, क्योंकि पासवर्ड खींचने से अब बहुत तेज CPUs और जीपीयू और एफपीजीए के उपयोग के कारण पासवर्ड तंत्र की एक महत्वपूर्ण विशेषता है, प्रति सेकेंड अनुमानों की दर से पासवर्ड को क्रैक करने के लिए (जीपीयू के साथ)।

उदाहरण के लिए, आप 5 डेस्कटॉप पीसी में स्थापित 25 जीपीयू का उपयोग करके 6 घंटे में सभी 8-वर्ण विंडोज पासवर्ड को क्रैक कर सकते हैं। यह ब्रूट-फोर्सिंग है यानी विशेष वर्णों सहित प्रत्येक 8-वर्ण वाले विंडोज पासवर्ड की गणना और जांच करना, और एक शब्दकोश हमला नहीं है। 2012 में, 2018 तक आप कम जीपीयू का उपयोग कर सकते थे, या 25 जीपीयू के साथ तेजी से क्रैक कर सकते थे।

विंडोज सीपीयू पर कई इंद्रधनुष टेबल हमले भी हैं जो साधारण सीपीयू पर चलते हैं और बहुत तेज़ होते हैं। यह सब इसलिए है क्योंकि विंडोज़ अभी भी विंडोज़ 10 में भी अपने पासवर्ड को नमक या खिंचाव नहीं करता है - माइक्रोसॉफ्ट की तरह ही गलती मत करो!

यह भी देखें:

  • password_hash() या phpass जाने का सबसे अच्छा तरीका क्यों है इसके बारे में अधिक जानकारी के साथ उत्कृष्ट उत्तर
  • अच्छा ब्लॉग आलेख bcrypt, scrypt और PBKDF2 सहित मुख्य एल्गोरिदम के लिए अनुशंसित 'कार्य कारक' (पुनरावृत्तियों की संख्या) प्रदान करता है।

मैं openwall.com/phpass का उपयोग कर रहा हूं जो एक साधारण एक-फ़ाइल PHP क्लास है जिसे लगभग हर PHP प्रोजेक्ट में बहुत आसानी से कार्यान्वित किया जा सकता है। एच भी देखें।

डिफ़ॉल्ट रूप से यह सबसे मजबूत उपलब्ध एन्क्रिप्शन का उपयोग करता है जिसे फ़ैस में कार्यान्वित किया जाता है, जो कि bcrypt और वर्डप्रेस जैसे ढांचे को पिछड़ा संगतता प्रदान करने के लिए एमडी 5 तक अन्य एन्क्रिप्शन पर वापस आ जाता है।

लौटा हैश डेटाबेस में संग्रहीत किया जा सकता है। हैश उत्पन्न करने के लिए नमूना उपयोग है:

$t_hasher = new PasswordHash(8, FALSE);
$hash = $t_hasher->HashPassword($password);

पासवर्ड सत्यापित करने के लिए, कोई भी उपयोग कर सकता है:

$t_hasher = new PasswordHash(8, FALSE);
$check = $t_hasher->CheckPassword($password, $hash);

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


हालांकि सवाल का उत्तर दिया गया है, मैं सिर्फ दोहराना चाहता हूं कि हैशिंग के लिए उपयोग किए गए लवण यादृच्छिक होना चाहिए और ईमेल पते की तरह पहले जवाब में सुझाव नहीं दिया जाना चाहिए।

अधिक स्पष्टीकरण उपलब्ध है- http://www.pivotalsecurity.com/blog/password-hashing-salt-should-it-be-random/

हाल ही में मैंने एक चर्चा की थी कि क्या यादृच्छिक बिट्स के साथ नमकीन पासवर्ड हैश अनुमानित या ज्ञात नमक के साथ नमकीन से अधिक सुरक्षित है। चलो देखते हैं: यदि सिस्टम को संग्रहीत करने वाला सिस्टम समझौता किया गया है और साथ ही सिस्टम जो यादृच्छिक नमक को स्टोर करता है, हमलावर के पास हैश और नमक तक पहुंच होगी, इसलिए नमक यादृच्छिक है या नहीं, इससे कोई फर्क नहीं पड़ता। हमलावर हैश को दरकिनार करने के लिए पूर्व-गणना इंद्रधनुष सारणी उत्पन्न कर सकता है। यहां दिलचस्प हिस्सा आता है- प्री-कंप्यूटेड टेबल जेनरेट करना इतना छोटा नहीं है। आइए हम डब्ल्यूपीए सुरक्षा मॉडल का उदाहरण लें। आपका WPA पासवर्ड वास्तव में वायरलेस एक्सेस पॉइंट पर कभी नहीं भेजा जाता है। इसके बजाए, यह आपके एसएसआईडी (नेटवर्क नाम- जैसे Linksys, Dlink आदि) के साथ धोया गया है। यह कैसे काम करता है इसका एक बहुत अच्छा स्पष्टीकरण यहां है। हैश से पासवर्ड पुनर्प्राप्त करने के लिए, आपको पासवर्ड और नमक (नेटवर्क नाम) को जानना होगा। वाईफ़ाई चर्च पहले से ही पहले से गणना की हैश सारणी है जिसमें शीर्ष 1000 एसएसआईडी और लगभग 1 मिलियन पासवर्ड हैं। सभी टेबलों का आकार लगभग 40 जीबी है। जैसा कि आप अपनी साइट पर पढ़ सकते हैं, किसी ने इन टेबलों को उत्पन्न करने के लिए 3 दिनों के लिए 15 एफजीपीए सरणी का उपयोग किया। पीड़ित मानते हैं कि एसएसआईडी "ए387csf3" और पासवर्ड "123456" के रूप में उपयोग कर रहा है, क्या यह उन तालिकाओं द्वारा क्रैक किया जाएगा? नहीं! .. यह नहीं कर सकते। यहां तक ​​कि यदि पासवर्ड कमजोर है, तो टेबल में SSID a387csf3 के लिए हैश नहीं है। यह यादृच्छिक नमक होने की सुंदरता है। यह क्रैकर्स को रोक देगा जो प्री-कंप्यूटेड टेबल पर बढ़ते हैं। क्या यह एक निर्धारित हैकर को रोक सकता है? शायद ऩही। लेकिन यादृच्छिक लवण का उपयोग रक्षा की अतिरिक्त परत प्रदान करता है। जबकि हम इस विषय पर हैं, आइए हम एक अलग सिस्टम पर यादृच्छिक लवण को संग्रहीत करने के अतिरिक्त लाभ पर चर्चा करें। परिदृश्य # 1: पासवर्ड एक्स को सिस्टम एक्स पर संग्रहीत किया जाता है और हैशिंग के लिए उपयोग किए जाने वाले नमक मान सिस्टम वाई पर संग्रहीत होते हैं। ये नमक मान अनुमानित या ज्ञात हैं (उदाहरण के लिए उपयोगकर्ता नाम) परिदृश्य # 2: पासवर्ड हैश सिस्टम एक्स और नमक मानों पर संग्रहीत हैं हैशिंग सिस्टम वाई पर संग्रहीत हैं। ये नमक मूल्य यादृच्छिक हैं। यदि सिस्टम एक्स से समझौता किया गया है, जैसा कि आप अनुमान लगा सकते हैं, तो एक अलग सिस्टम (परिदृश्य # 2) पर यादृच्छिक नमक का उपयोग करने का एक बड़ा फायदा है। हमलावर को हैश क्रैक करने में सक्षम होने के लिए अतिरिक्त मूल्यों का अनुमान लगाने की आवश्यकता होगी। यदि 32 बिट नमक का उपयोग किया जाता है, तो प्रत्येक पासवर्ड अनुमानित 2 ^ 32 = 4,294,967,296 (लगभग 4.2 बिलियन) पुनरावृत्तियों की आवश्यकता होगी।


SHA1 and a salt should suffice (depending, naturally, on whether you are coding something for Fort Knox or a login system for your shopping list) for the foreseeable future. If SHA1 isn't good enough for you, use SHA256 .

The idea of a salt is to throw the hashing results off balance, so to say. It is known, for example, that the MD5-hash of an empty string is d41d8cd98f00b204e9800998ecf8427e . So, if someone with good enough a memory would see that hash and know that it's the hash of an empty string. But if the string is salted (say, with the string " MY_PERSONAL_SALT "), the hash for the 'empty string' (ie " MY_PERSONAL_SALT ") becomes aeac2612626724592271634fb14d3ea6 , hence non-obvious to backtrace. What I'm trying to say, that it's better to use any salt, than not to. Therefore, it's not too much of an importance to know which salt to use.

There are actually websites that do just this - you can feed it a (md5) hash, and it spits out a known plaintext that generates that particular hash. If you would get access to a database that stores plain md5-hashes, it would be trivial for you to enter the hash for the admin to such a service, and log in. But, if the passwords were salted, such a service would become ineffective.

Also, double-hashing is generally regarded as bad method, because it diminishes the result space. All popular hashes are fixed-length. Thus, you can have only a finite values of this fixed length, and the results become less varied. This could be regarded as another form of salting, but I wouldn't recommend it.


I usually use SHA1 and salt with the user ID (or some other user-specific piece of information), and sometimes I additionally use a constant salt (so I have 2 parts to the salt).

SHA1 is now also considered somewhat compromised, but to a far lesser degree than MD5. By using a salt (any salt), you're preventing the use of a generic rainbow table to attack your hashes (some people have even had success using Google as a sort of rainbow table by searching for the hash). An attacker could conceivably generate a rainbow table using your salt, so that's why you should include a user-specific salt. That way, they will have to generate a rainbow table for each and every record in your system, not just one for your entire system! With that type of salting, even MD5 is decently secure.


ok in the fitsy we need salt salt must be unique so let generate it

   /**
     * Generating string
     * @param $size
     * @return string
     */
    function Uniwur_string($size){
        $text = md5(uniqid(rand(), TRUE));
        RETURN substr($text, 0, $size);
    }

also we need the hash I`m using sha512 it is the best and it is in php

   /**
     * Hashing string
     * @param $string
     * @return string
     */
    function hash($string){
        return hash('sha512', $string);
    }

so now we can use this functions to generate safe password

// generating unique password
$password = Uniwur_string(20); // or you can add manual password
// generating 32 character salt
$salt = Uniwur_string(32);
// now we can manipulate this informations

// hashin salt for safe
$hash_salt = hash($salt);
// hashing password
$hash_psw = hash($password.$hash_salt);

now we need to save in database our $hash_psw variable value and $salt variable

and for authorize we will use same steps...

it is the best way to safe our clients passwords...

Ps for last 2 steps you can use your own algorithm... but be sure that you can generate this hashed password in the future when you need to authorize user...





protection