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




security passwords (12)

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

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

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

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

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

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

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

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


मैं बस यह इंगित करना चाहता हूं कि PHP 5.5 में पासवर्ड हैशिंग एपीआई शामिल है जो crypt() चारों ओर एक रैपर प्रदान करती है। यह एपीआई हैशिंग, सत्यापन और पासवर्ड हैश को रीहाश करने के कार्य को काफी सरल बनाता है। लेखक ने PHP 5.3.7 और बाद वाले लोगों के लिए एक संगतता पैक भी जारी किया है (एक पासवर्ड.एफ़.पी. फ़ाइल के रूप में जिसे आप बस उपयोग करने की require है), और अभी इसका उपयोग करना चाहते हैं।

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

एपीआई चार कार्यों का खुलासा करता है:

  • password_get_info() - दिए गए हैश के बारे में जानकारी देता है
  • password_hash() - एक पासवर्ड हैश बनाता है
  • password_needs_rehash() - चेक दिया गया है कि दिया गया हैश दिए गए विकल्पों से मेल खाता है या नहीं। यह जांचने के लिए उपयोगी है कि हैश आपकी वर्तमान तकनीक / लागत योजना के अनुरूप है या नहीं, यदि आवश्यक हो तो आपको फिर से रिहा करने की अनुमति मिलती है
  • password_verify() - सत्यापित करता है कि एक पासवर्ड हैश से मेल खाता है

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

संपादित करें: मुझे अभी एहसास हुआ कि रॉबर्ट के जवाब में संक्षेप में इसका उल्लेख किया गया है। मैं यह जवाब यहां छोड़ दूंगा क्योंकि मुझे लगता है कि यह कैसे काम करता है और यह उपयोग की आसानी के बारे में कुछ और जानकारी प्रदान करता है जो सुरक्षा को नहीं जानते हैं।


अस्वीकरण : यह उत्तर 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 जैसी महंगी योजनाएं बहुत महत्वपूर्ण हैं।

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

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


मैं 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);

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...


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

अधिक स्पष्टीकरण उपलब्ध है- 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 बिलियन) पुनरावृत्तियों की आवश्यकता होगी।


याद रखने वाली चीज़ें

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

सर्वर

बंदरगाहों

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

उपयोगकर्ता नाम

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

पारण शब्द

आप अपने उपयोगकर्ताओं को हैक करने से बचने के लिए अच्छे पासवर्ड बनाने के लिए कहते हैं, वही करें। जब आपके पास पिछवाड़े के खुले खुले होते हैं तो अपने सामने वाले दरवाजे को लॉक करने के सभी प्रयासों के माध्यम से जाने का क्या मतलब है।

डेटाबेस

सर्वर

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

उपयोगकर्ता

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

फिर आपके लिए एक अलग उपयोगकर्ता खाता है जो सर्वर पर कहीं भी संग्रहीत नहीं है, एप्लिकेशन में भी नहीं।

हमेशा की तरह इस रूट या कुछ समान मत बनाओ।

पारण शब्द

सभी अच्छे पासवर्ड के साथ समान दिशानिर्देशों का पालन करें। उसी सिस्टम पर किसी भी सर्वर या डीबी खातों पर एक ही पासवर्ड का पुन: उपयोग न करें।

पीएचपी

पारण शब्द

कभी भी अपने डीबी में पासवर्ड स्टोर न करें, इसके बजाय हैश और अद्वितीय नमक को स्टोर करें, मैं बाद में क्यों समझाऊंगा।

हैशिंग

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

वहां बहुत अच्छे हैंशिंग फ़ंक्शन हैं ( password_hash , hash , इत्यादि ...) लेकिन हैश के प्रभावी होने के लिए आपको एक अच्छा एल्गोरिदम चुनना होगा। (bcrypt और इसके समान वाले सभ्य एल्गोरिदम हैं।)

जब हैशिंग गति कुंजी है, तो धीमी गति से बलपूर्वक बल के हमलों के लिए अधिक प्रतिरोधी।

हैशिंग में सबसे आम गलतियों में से एक यह है कि हैश उपयोगकर्ताओं के लिए अद्वितीय नहीं हैं। यह मुख्य रूप से इसलिए है क्योंकि लवण विशिष्ट रूप से उत्पन्न नहीं होते हैं।

रेह

पासवर्ड को हमेशा धोने से पहले नमकीन होना चाहिए। सल्टिंग पासवर्ड में एक यादृच्छिक स्ट्रिंग जोड़ता है, इसलिए समान पासवर्ड डीबी में समान दिखाई नहीं देते हैं। हालांकि अगर नमक प्रत्येक उपयोगकर्ता के लिए अद्वितीय नहीं है (यानी: आप एक हार्ड कोडेड नमक का उपयोग करते हैं) तो आप ने अपने नमक को बेकार बना दिया है। क्योंकि एक बार जब हमलावर एक पासवर्ड नमक का आंकड़ा करता है तो उसके पास उन सभी के लिए नमक होता है।

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

पासवर्ड बनाने वाले उपयोगकर्ता

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

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

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

यहां एक PHP वर्ग है जो आसानी से पासवर्ड के लिए हैश और नमक बनाता है

http://git.io/mSJqpw


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.


मुझे यहां इस मामले पर सही विषय मिला: https://crackstation.net/hashing-security.htm , मैं चाहता था कि आप इससे लाभ प्राप्त करें, यहां स्रोत कोड भी है जो समय-आधारित हमले के खिलाफ रोकथाम प्रदान करता है।

<?php
/*
 * Password hashing with PBKDF2.
 * Author: havoc AT defuse.ca
 * www: https://defuse.ca/php-pbkdf2.htm
 */

// These constants may be changed without breaking existing hashes.
define("PBKDF2_HASH_ALGORITHM", "sha256");
define("PBKDF2_ITERATIONS", 1000);
define("PBKDF2_SALT_BYTES", 24);
define("PBKDF2_HASH_BYTES", 24);

define("HASH_SECTIONS", 4);
define("HASH_ALGORITHM_INDEX", 0);
define("HASH_ITERATION_INDEX", 1);
define("HASH_SALT_INDEX", 2);
define("HASH_PBKDF2_INDEX", 3);

function create_hash($password)
{
    // format: algorithm:iterations:salt:hash
    $salt = base64_encode(mcrypt_create_iv(PBKDF2_SALT_BYTES, MCRYPT_DEV_URANDOM));
    return PBKDF2_HASH_ALGORITHM . ":" . PBKDF2_ITERATIONS . ":" .  $salt . ":" . 
        base64_encode(pbkdf2(
            PBKDF2_HASH_ALGORITHM,
            $password,
            $salt,
            PBKDF2_ITERATIONS,
            PBKDF2_HASH_BYTES,
            true
        ));
}

function validate_password($password, $good_hash)
{
    $params = explode(":", $good_hash);
    if(count($params) < HASH_SECTIONS)
       return false; 
    $pbkdf2 = base64_decode($params[HASH_PBKDF2_INDEX]);
    return slow_equals(
        $pbkdf2,
        pbkdf2(
            $params[HASH_ALGORITHM_INDEX],
            $password,
            $params[HASH_SALT_INDEX],
            (int)$params[HASH_ITERATION_INDEX],
            strlen($pbkdf2),
            true
        )
    );
}

// Compares two strings $a and $b in length-constant time.
function slow_equals($a, $b)
{
    $diff = strlen($a) ^ strlen($b);
    for($i = 0; $i < strlen($a) && $i < strlen($b); $i++)
    {
        $diff |= ord($a[$i]) ^ ord($b[$i]);
    }
    return $diff === 0; 
}

/*
 * PBKDF2 key derivation function as defined by RSA's PKCS #5: https://www.ietf.org/rfc/rfc2898.txt
 * $algorithm - The hash algorithm to use. Recommended: SHA256
 * $password - The password.
 * $salt - A salt that is unique to the password.
 * $count - Iteration count. Higher is better, but slower. Recommended: At least 1000.
 * $key_length - The length of the derived key in bytes.
 * $raw_output - If true, the key is returned in raw binary format. Hex encoded otherwise.
 * Returns: A $key_length-byte key derived from the password and salt.
 *
 * Test vectors can be found here: https://www.ietf.org/rfc/rfc6070.txt
 *
 * This implementation of PBKDF2 was originally created by https://defuse.ca
 * With improvements by http://www.variations-of-shadow.com
 */
function pbkdf2($algorithm, $password, $salt, $count, $key_length, $raw_output = false)
{
    $algorithm = strtolower($algorithm);
    if(!in_array($algorithm, hash_algos(), true))
        die('PBKDF2 ERROR: Invalid hash algorithm.');
    if($count <= 0 || $key_length <= 0)
        die('PBKDF2 ERROR: Invalid parameters.');

    $hash_length = strlen(hash($algorithm, "", true));
    $block_count = ceil($key_length / $hash_length);

    $output = "";
    for($i = 1; $i <= $block_count; $i++) {
        // $i encoded as 4 bytes, big endian.
        $last = $salt . pack("N", $i);
        // first iteration
        $last = $xorsum = hash_hmac($algorithm, $last, $password, true);
        // perform the other $count - 1 iterations
        for ($j = 1; $j < $count; $j++) {
            $xorsum ^= ($last = hash_hmac($algorithm, $last, $password, true));
        }
        $output .= $xorsum;
    }

    if($raw_output)
        return substr($output, 0, $key_length);
    else
        return bin2hex(substr($output, 0, $key_length));
}
?>

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 सहित मुख्य एल्गोरिदम के लिए अनुशंसित 'कार्य कारक' (पुनरावृत्तियों की संख्या) प्रदान करता है।

PHP 5.5 के रूप में, PHP के पास हैशिंग और पासवर्ड सत्यापित करने के लिए सरल, सुरक्षित फ़ंक्शन हैं, php.net/manual/en/function.password-hash.php और password_verify

$password = 'anna';
$hash = password_hash($password, PASSWORD_DEFAULT);
$expensiveHash = password_hash($password, PASSWORD_DEFAULT, array('cost' => 20));

password_verify('anna', $hash); //Returns true
password_verify('anna', $expensiveHash); //Also returns true
password_verify('elsa', $hash); //Returns false

जब password_hash() का उपयोग किया जाता है, तो यह एक यादृच्छिक नमक उत्पन्न करता है और इसे आउटपुट किए गए हैश (उपयोग की password_verify() लागत और एल्गोरिदम के साथ) में शामिल करता है। password_verify() तब हैश पढ़ता है और नमक और एन्क्रिप्शन विधि का उपयोग करता है, और इसे सत्यापित करता है प्रदान किया गया सादा पाठ पासवर्ड।

PASSWORD_DEFAULT प्रदान करना PHP के स्थापित संस्करण के डिफ़ॉल्ट हैशिंग एल्गोरिदम का उपयोग करने के लिए PHP को निर्देश देता है। वास्तव में कौन सा एल्गोरिदम जिसका अर्थ भविष्य के संस्करणों में समय के साथ बदलना है, ताकि यह हमेशा सबसे मजबूत उपलब्ध एल्गोरिदम में से एक रहे।

बढ़ती लागत (जो 10 तक चूकती है) हैश को बलपूर्वक बल देने के लिए कठिन बनाता है, लेकिन इसका मतलब है कि हैश उत्पन्न करना और उनके खिलाफ पासवर्ड सत्यापित करना आपके सर्वर के सीपीयू के लिए अधिक काम करेगा।

ध्यान दें कि भले ही डिफ़ॉल्ट हैशिंग एल्गोरिदम बदल सकता है, पुराने हैंश ठीक से सत्यापित करना जारी रखेंगे क्योंकि उपयोग किए गए एल्गोरिदम को हैश और password_verify() में संग्रहीत किया जाता है।





protection