सबसे अच्छा लगता है कि पहिया को सुदृढ़ नहीं करना है। लेकिन, मैं समझता हूं, PHP की दुनिया में एक उच्च गुणवत्ता वाले घटक को खोजना मुश्किल हो सकता है जो पहले से ही करता है (यहां तक कि मुझे पूरा यकीन है कि ऐसी चीजें लागू होती हैं और उनके कार्यान्वयन पहले से ही परीक्षण किए गए, ठोस, कोड-समीक्षा आदि हैं) )
यदि, कुछ कारणों से, आप एक रूपरेखा का उपयोग नहीं कर सकते हैं, तो यहां कुछ सुझाव दिए गए हैं:
यदि आप कर सकते हैं तो PBKDF2 या Bcrypt का उपयोग करें । उसके लिए किया है।
औचित्य: दोनों एल्गोरिदम हैशिंग प्रक्रिया को मनमाने ढंग से धीमा कर सकते हैं, जो कि आप चाहते हैं कि जब हैशिंग पासवर्ड (तेज विकल्प आसान ब्रूट बल का मतलब हो)। आदर्श रूप से, आपको मापदंडों को समायोजित करना चाहिए ताकि प्रक्रिया एक ही हार्डवेयर पर समय के साथ धीमी और धीमी हो जाए, जबकि नया, तेज हार्डवेयर जारी किया जाता है।
यदि आप नहीं कर सकते हैं, तो कम से कम MD5 / SHA1 का उपयोग न करें। कभी नहीँ। इसके बारे में भूल जाओ । उदाहरण के लिए, इसके बजाय SHA512 का उपयोग करें। नमक का भी प्रयोग करें।
तर्क: MD5 और SHA1 बहुत तेज हैं। यदि हमलावर के पास हैश युक्त आपके डेटाबेस तक पहुंच है और उसके पास (विशेष रूप से भी नहीं) शक्तिशाली मशीन है, तो पासवर्ड के लिए ब्रूट-फोर्सिंग तेज और आसान है। यदि कोई लवण नहीं हैं, तो संभावना है कि हमलावर को वास्तविक पासवर्ड बढ़ जाता है (जो पासवर्ड को कहीं और फिर से उपयोग किए जाने पर अतिरिक्त नुकसान पहुंचा सकता है)।
PHP में 5.5.0 और बाद में, का उपयोग करें password_hashऔर password_verify।
Rationale: फ्रेमवर्क द्वारा प्रदान किए गए फ़ंक्शन को कॉल करना आसान है, इसलिए गलती करने का जोखिम कम हो जाता है। उन दो कार्यों के साथ, आपको हैश जैसे विभिन्न मापदंडों के बारे में सोचने की ज़रूरत नहीं है। पहला फ़ंक्शन एक एकल स्ट्रिंग देता है जिसे तब डेटाबेस में संग्रहीत किया जा सकता है। दूसरा फ़ंक्शन पासवर्ड सत्यापन के लिए इस स्ट्रिंग का उपयोग करता है।
अपने आप को क्रूर बल से सुरक्षित रखें । अगर उपयोगकर्ता 0.01 सेकंड पहले एक और गलत पासवर्ड सबमिट करने पर गलत पासवर्ड सबमिट करता है, तो इसे ब्लॉक करने का एक अच्छा कारण है। मनुष्य तेज़ी से टाइप कर सकते हैं, वे शायद नहीं हो सकता है कि तेजी से।
प्रति घंटे की विफलताओं की सीमा निर्धारित करने के लिए एक और सुरक्षा होगी। यदि उपयोगकर्ता ने एक घंटे में 3600 गलत पासवर्ड दिए हैं, तो 1 पासवर्ड प्रति सेकंड, यह विश्वास करना मुश्किल है कि यह एक वैध उपयोगकर्ता है।
Rationale: यदि आपके पासवर्ड असुरक्षित तरीके से हैंश किए गए हैं, तो brute force बहुत प्रभावी हो सकता है। यदि पासवर्ड सुरक्षित रूप से संग्रहीत किए जाते हैं, तो ब्रूट बल अभी भी आपके सर्वर के संसाधनों और नेटवर्क बैंडविड्थ को बर्बाद कर रहा है, जिससे वैध उपयोगकर्ताओं के लिए कम प्रदर्शन होता है। ब्रूट फोर्स डिटेक्शन को विकसित करना और सही करना आसान नहीं है, लेकिन किसी भी लेकिन छोटे सिस्टम के लिए, यह पूरी तरह से इसके लायक है।
हर चार सप्ताह में अपने उपयोगकर्ताओं से अपने पासवर्ड बदलने के लिए न कहें। यह अत्यंत कष्टप्रद है और सुरक्षा कम हो जाती है, क्योंकि यह पोस्ट-इट-आधारित सुरक्षा को प्रोत्साहित करती है।
Rationale: यह विचार कि पासवर्ड को हर n सप्ताह में बदलने के लिए मजबूर करना सिस्टम को क्रूर बल से बचाता है, गलत है। ब्रूट बल के हमले आमतौर पर सेकंड, मिनट, घंटे या दिनों के भीतर सफल होते हैं, जो मासिक पासवर्ड परिवर्तन को अप्रासंगिक बनाता है। दूसरी ओर, उपयोगकर्ता पासवर्ड याद रखने में बुरे हैं। यदि, इसके अलावा, उन्हें बदलने की आवश्यकता है, तो वे या तो बहुत ही सरल पासवर्ड का उपयोग करने का प्रयास करेंगे या बस इसके बाद अपने पासवर्ड को नोट करेंगे।
हर बार, सबका ऑडिट करें। लॉगऑन स्टोर करें, लेकिन ऑडिट लॉग में पासवर्ड स्टोर न करें। सुनिश्चित करें कि ऑडिट लॉग को संशोधित नहीं किया जा सकता है (यानी आप अंत में डेटा जोड़ सकते हैं, लेकिन मौजूदा डेटा को संशोधित नहीं कर सकते हैं)। सुनिश्चित करें कि ऑडिट लॉग नियमित बैकअप के अधीन हैं। आदर्श रूप से, लॉग्स को एक समर्पित सर्वर पर बहुत प्रतिबंधक एक्सेस के साथ संग्रहीत किया जाना चाहिए: यदि किसी अन्य सर्वर को हैक किया जाता है, तो हमलावर अपनी उपस्थिति (और हमले के दौरान लिए गए पथ) को छिपाने के लिए लॉग्स को मिटा नहीं पाएगा।
कुकीज में उपयोगकर्ता क्रेडेंशियल याद न रखें, जब तक कि उपयोगकर्ता इसे करने के लिए नहीं कहता ("मुझे याद रखें" चेक बॉक्स को मानवीय त्रुटि से बचने के लिए डिफ़ॉल्ट रूप से अनियंत्रित होना चाहिए)।