php उपयोगकर्ता पासवर्ड साफ़ कर रहा है




sql pdo (2)

पासवर्ड को हैश करने से पहले, आपको इसे सामान्य करना चाहिए जैसा कि RFC 7613 की धारा 4 में वर्णित है। विशेष रूप से:

  1. अतिरिक्त मानचित्रण नियम: गैर-एएससीआईआई अंतरिक्ष के किसी भी उदाहरण को एएससीआईआई अंतरिक्ष (यू + 0020) में मैप किया जाना चाहिए; एक गैर- ASCII स्थान यूनिकोड कोड है, जिसमें "Zs" (यू + 0020 के अपवाद के साथ) की यूनिकोड सामान्य श्रेणी है।

तथा:

  1. सामान्यीकरण नियम: यूनिकोड सामान्यकरण प्रपत्र C (NFC) सभी वर्णों पर लागू होना चाहिए।

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

इससे पहले कि मैं उन्हें हैश करके अपने डेटाबेस में संग्रहीत करूँ, उपयोगकर्ता-प्रदान किए गए पासवर्डों से कैसे बचूँ या शुद्ध करूँ?

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


आपको पासवर्ड पर किसी भी अन्य सफाई तंत्र से बचना, ट्रिम या उपयोग नहीं करना चाहिए। आप कई कारणों से PHP के password_hash() के साथ हैशिंग होंगे, इसका सबसे बड़ा कारण यह है कि पासवर्ड की अतिरिक्त सफाई करने के लिए अनावश्यक अतिरिक्त कोड की आवश्यकता होती है।

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

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

यदि आप उपयोगकर्ताओं को उन पासवर्डों / वाक्यांशों का उपयोग करने की अनुमति देने के मंत्रों का पालन करते हैं जो वे चाहते हैं और आप पासवर्ड को सीमित नहीं करते हैं , तो किसी भी लम्बाई, किसी भी स्थान और किसी भी विशेष वर्ण हैशिंग की अनुमति देता है पासवर्ड / पासफ़्रेज़ को सुरक्षित रखता है कोई बात नहीं है पासवर्ड। फिलहाल सबसे आम हैश (डिफ़ॉल्ट), PASSWORD_BCRYPT , पासवर्ड को एक 60 कैरेक्टर चौड़े स्ट्रिंग में बदल देता है जिसमें रैंडम सॉल्ट के साथ रैंडम सॉल्ट की जानकारी और एक कॉस्ट (हैश बनाने की एल्गोरिथमिक कॉस्ट) शामिल है:

PASSWORD_BCRYPT का उपयोग CRYPT_BLOWFISH एल्गोरिथ्म का उपयोग करके नया पासवर्ड हैश बनाने के लिए किया जाता है। यह हमेशा "$ 2y $" क्रिप्ट प्रारूप का उपयोग करके एक हैश में होगा, जो हमेशा 60 वर्ण चौड़ा होता है।

हैश को संचय करने के लिए स्थान की आवश्यकताएं परिवर्तन के अधीन हैं क्योंकि विभिन्न हैशिंग विधियों को फ़ंक्शन में जोड़ा जाता है, इसलिए संग्रहीत हैश के लिए स्तंभ प्रकार पर बड़ा जाना हमेशा बेहतर होता है, जैसे VARCHAR(255) या TEXT

आप अपने पासवर्ड के रूप में एक पूरी SQL क्वेरी का उपयोग कर सकते हैं और इसे हैश किया जाएगा, जिससे यह SQL इंजन द्वारा अप्राप्य हो जाएगा, जैसे

SELECT * FROM `users`;

$2y$10$1tOKcWUWBW5gBka04tGMO.BH7gs/qjAHZsC5wyG0zmI2C.KgaqU5G

आइए देखें कि अलग-अलग सैनिटाइज़िंग तरीके पासवर्ड को कैसे प्रभावित करते हैं -

पासवर्ड I'm a "dessert topping" & a <floor wax>! (पासवर्ड के अंत में 5 स्थान हैं जो यहां प्रदर्शित नहीं हैं।)

जब हम ट्रिमिंग के निम्नलिखित तरीकों को लागू करते हैं तो हमें कुछ अलग-अलग परिणाम मिलते हैं:

var_dump(trim($_POST['upassword']));
var_dump(htmlentities($_POST['upassword']));
var_dump(htmlspecialchars($_POST['upassword']));
var_dump(addslashes($_POST['upassword']));
var_dump(strip_tags($_POST['upassword']));

परिणाम:

string(40) "I'm a "dessert topping" & a <floor wax>!" // spaces at the end are missing
string(65) "I'm a &quot;dessert topping&quot; &amp; a &lt;floor wax&gt;!     " // double quotes, ampersand and braces have been changed
string(65) "I'm a &quot;dessert topping&quot; &amp; a &lt;floor wax&gt;!     " // same here
string(48) "I\'m a \"dessert topping\" & a <floor wax>!     " // escape characters have been added
string(34) "I'm a "dessert topping" & a !     " // looks like we have something missing

जब हम इन्हें password_hash() भेजते हैं तो क्या होता है? जैसा कि क्वेरी ऊपर किया गया था, वे सभी हैशेड हो जाते हैं। समस्या तब आती है जब आप पासवर्ड को सत्यापित करने का प्रयास करते हैं। यदि हम इनमें से एक या एक से अधिक तरीकों को नियोजित करते हैं, तो हमें पासवर्ड_वरिफ़ password_verify() साथ तुलना करने से पहले उन्हें पुनः नियोजित करना होगा। निम्नलिखित विफल होगा:

password_verify($_POST['upassword'], $hashed_password); // where $hashed_password comes from a database query

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

5.5 से कम PHP संस्करण का उपयोग करना? आप password_hash() संगतता पैक का उपयोग कर सकते हैं।

आपको वास्तव में MD5 पासवर्ड हैश का उपयोग नहीं करना चाहिए।





hash