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

Question

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

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

Comments

यू यूजर बेस 64 एनकोड कर सकते हैं

— एमएसएस

नहीं @MSS, आपको नहीं करना चाहिए क्योंकि base64 एन्कोडिंग है , एन्क्रिप्ट या हैशिंग नहीं । पासवर्ड हमेशा हैशेड होना चाहिए ।

— जे। ब्लैंचर्ड

मेरा मतलब हैश से पहले;)

— एमएसएस

आपको हैशिंग से पहले ऐसा नहीं करना चाहिए और न ही करना चाहिए। इससे आपको अनावश्यक अतिरिक्त कोड @MSS

— Jay Blanchard

Answer 1

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

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

Comments

यदि उन्होंने अपना पासवर्ड अनुगामी स्थानों के साथ बनाया है, जिसकी अनुमति है, तो उन्हें @ @anBracuk

— Jay Blanchard

कैसे इतना @DanBracuk? यदि हम उपयोगकर्ता को पासवर्ड बदलने की अनुमति देते हैं, तो वह प्रमुख / अनुगामी स्थानों सहित इच्छाओं को पूरा करता है?

— जे। ब्लैंचर्ड

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

— मैंने एक बार एक भालू को कुश्ती दी।

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

— डेविड एसपी

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

— स्टीव जेसप

Answer 2

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

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

तथा:

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

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

Comments

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

— मार्गरेट ब्लूम

जिंगोस्टिक लगता है। :-) हालांकि धन्यवाद।

— डेविड एसपी

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

— बरखा

@JayBlanchard क्योंकि जब आप एक मशीन पर स्पेस बार दबाते हैं और जब आप इसे किसी अन्य मशीन पर दबाते हैं तो आपको दो अलग-अलग यूनिकोड कोड पॉइंट मिल सकते हैं, और उनके पास दो अलग-अलग UTF-8 एनकोडिंग होंगे, बिना उपयोगकर्ता को कुछ भी पता चले। यह तर्क दिया जा सकता है कि यह एक ऐसी समस्या है जिसे आप नजरअंदाज करना चाहते हैं, लेकिन RFC 7613 ऐसे वास्तविक जीवन के मुद्दों से पैदा हुआ था, यह एक काम की सिफारिश नहीं है।

— मोनिका

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

— मोनिका