मैं वर्तमान में एक PHP OpenID प्रदाता पर काम कर रहा हूं जो HTTPS (इसलिए SSL एन्क्रिप्टेड) पर काम करेगा।
क्या मेरे लिए सादे पाठ के रूप में पासवर्ड संचारित करना गलत है ? सिद्धांत में HTTPS को इंटरसेप्ट नहीं किया जा सकता है, इसलिए मुझे कुछ भी गलत नहीं दिखता है। या यह किसी स्तर पर असुरक्षित है और मैं इसे देखने में असफल रहा हूं?
जवाबों:
यह सुरक्षित है। पूरी वेब कैसे काम करती है। फ़ॉर्म में सभी पासवर्ड हमेशा सादे पाठ में भेजे जाते हैं, इसलिए इसे सुरक्षित करने के लिए HTTPS तक।
आपको अभी भी यह सुनिश्चित करने की आवश्यकता है कि आप इसे पोस्ट अनुरोध के माध्यम से भेजते हैं, जीईटी नहीं। यदि आप इसे GET अनुरोध के माध्यम से भेजते हैं, तो इसे उपयोगकर्ता के ब्राउज़र इतिहास लॉग या वेबसर्वर के एक्सेस लॉग में प्लेनटेक्स्ट में सहेजा जा सकता है।
यदि HTTP अक्षम है, और आप केवल HTTPS का उपयोग करते हैं, तो आप वास्तव में पासवर्ड को सादे पाठ के रूप में वैसे भी प्रसारित नहीं कर रहे हैं।
हैश क्लाइंट पक्ष। क्यों? मैं आपको एक छोटे से प्रयोग के बारे में बताता हूं। कंपनी कैफेटेरिया में कंप्यूटर तक चलो। कंपनी वेब साइट लॉगिन पेज (https) के लिए ब्राउज़र खोलें। F12 दबाएं, नेटवर्क टैब पर क्लिक करें, लॉग लॉग जारी रखें, कंसोल को कम करें लेकिन वेब पेज को लॉगिन पेज पर छोड़ दें। बैठ कर दोपहर का भोजन करो। कंपनी वेब साइट पर कर्मचारी लॉग के बाद कर्मचारी के रूप में देखें और जब किया जाता है तो एक अच्छा छोटा कार्यकर्ता लॉग आउट होता है। दोपहर का भोजन समाप्त करें, कंप्यूटर पर बैठकर नेटवर्क टैब लाएं और फॉर्म बॉडी में सादे पाठ में प्रत्येक उपयोगकर्ता नाम और पासवर्ड देखें।
कोई विशेष उपकरण नहीं, कोई विशेष ज्ञान नहीं, कोई फैंसी हैकिंग हार्डवेयर नहीं, कोई भी keylogger सिर्फ अच्छा पुराना F12 नहीं।
लेकिन हे, तुम सब की जरूरत है सोच रखने के लिए SSL है बुरे लोग आपको इसके लिए प्यार करेंगे।
चलिए पिछले जवाबों के लिए कुछ नोट्स बनाते हैं।
सबसे पहले, हैश एल्गोरिदम क्लाइंट साइड का उपयोग करना सबसे अच्छा विचार नहीं है। यदि आपका पासवर्ड सर्वर की ओर से नमकीन है, तो आप हैश की तुलना करने में सक्षम नहीं होंगे (कम से कम नहीं अगर आप डेटाबेस में क्लाइंट हैश को पासवर्ड से हैशिंग लेयर्स में से एक में स्टोर नहीं करते हैं, जो समान है या और भी बुरा)। और आप क्लाइंट की ओर से डेटाबेस द्वारा उपयोग किए गए हैशिंग एल्गोरिथ्म को लागू नहीं करना चाहते हैं, यह मूर्खतापूर्ण होगा।
दूसरा, क्रिप्टोग्राफिक कुंजी से व्यापार करना आदर्श भी नहीं है। MITM सैद्धांतिक रूप से (यह मानते हुए कि उसके पास क्लाइंट पर एक रूट सर्टिफिकेट है) क्रिप्टोग्राफिक कुंजियों को बदल सकता है, और अपनी स्वयं की कुंजी के साथ बदल सकता है:
मूल कनेक्शन (tls पर विचार नहीं) एक सैद्धांतिक सर्वर से जो कि चाबियों का आदान-प्रदान करता है:
ग्राहक अनुरोध सार्वजनिक कुंजी> सर्वर निजी कुंजी रखता है, ग्राहक के लिए सार्वजनिक कुंजी उत्पन्न करता है> सर्वर ग्राहक को सार्वजनिक कुंजी भेजता है
अब, एक सैद्धांतिक MITM दरार में:
ग्राहक अनुरोध सार्वजनिक कुंजी> MITM नकली निजी कुंजी बनाता है > सर्वर निजी कुंजी रखता है, ग्राहक के लिए सार्वजनिक कुंजी उत्पन्न करता है > MITM मूल सर्वर से सार्वजनिक कुंजी प्राप्त करता है, अब, हम ग्राहक को अपनी नकली सार्वजनिक कुंजी भेजने के लिए स्वतंत्र हैं, और जब भी क्लाइंट से कोई अनुरोध आता है, तो हम क्लाइंट डेटा को नकली कुंजियों के साथ डिक्रिप्ट करेंगे, पेलोड को बदलेंगे (या इसे पढ़ें) और मूल सार्वजनिक कुंजी के साथ एन्क्रिप्ट करें > MITM क्लाइंट को नकली सार्वजनिक कुंजी भेजता है।
टीएलएस में विश्वसनीय सीए प्रमाणपत्र होने की बात है, और यह है कि यदि प्रमाण पत्र मान्य नहीं है तो आपको ब्राउज़र चेतावनी से एक संदेश कैसे प्राप्त होगा।
ओपी के जवाब में: मेरी विनम्र राय में आप ऐसा नहीं कर सकते, क्योंकि जितनी जल्दी या बाद में, कोई आपकी सेवा से उपयोगकर्ता पर हमला करना चाहेगा और आपके प्रोटोकॉल को तोड़ने की कोशिश करेगा।
हालांकि, आप क्या कर सकते हैं, 2FA को लागू करने के लिए लोगों को एक ही पासवर्ड के साथ लॉगिन करने की कोशिश करने से रोकने के लिए। फिर से खेलना हमलों के खबरदार।
मैं क्रिप्टोग्राफी के साथ महान नहीं हूं, अगर मैं गलत हूं तो कृपया मुझे सही करें।
अन्य पोस्टर सही हैं। अब जब आप पासवर्ड के संचरण को एन्क्रिप्ट करने के लिए एसएसएल का उपयोग कर रहे हैं, तो सुनिश्चित करें कि आप इसे एक अच्छे एल्गोरिथ्म और नमक के साथ हैशट कर रहे हैं, इसलिए जब यह आराम से हो , तो यह सुरक्षित है ...
@ कोडडॉग उदाहरण में मुद्दे हैं ..
हां, मैं विश्वास कर सकता हूं कि उपयोगकर्ता कैफेटेरिया बॉक्स में प्रवेश करेंगे। यदि आप एक कॉर्पोरेट कैफेटेरिया से लॉग कैप्चर कर रहे हैं, तो आप सुरक्षा उल्लंघन हैं। कॉर्पोरेट कैफेटेरिया बक्से को अक्षम किया जाना चाहिए, जैसे कोई शब्द नहीं, कोई लॉगर, कोई रिमोट एक्सेस नहीं, आदि, ताकि आप को रोकने के लिए, अंदर के हैकर।
उदाहरण कंप्यूटर एक्सेस सुरक्षा का एक अच्छा है, और वास्तव में नेटवर्क सुरक्षा से संबंधित नहीं है। इसे क्लाइंट साइड हैशिंग के औचित्य के रूप में प्रदान किया गया है, लेकिन यदि आपके पास कंप्यूटर का उपयोग है तो आप सिर्फ कीस्ट्रोके लकड़हारा और बायपास का उपयोग कर सकते हैं। ग्राहक पक्ष हैश फिर अप्रासंगिक है। @CodeDog द्वारा उदाहरण एक कंप्यूटर एक्सेस हैक है और इसके लिए नेटवर्क लेयर हैक से भिन्न तकनीकों की आवश्यकता होती है।
इसके अलावा, एक सार्वजनिक कंप्यूटर हैक प्रणाली को खतरों से अपंग करके सुरक्षित है, जैसा कि ऊपर उल्लेख किया गया है। जैसे सार्वजनिक कैफेटेरिया कंप्यूटर के लिए क्रोमबुक का उपयोग करें। लेकिन वह एक भौतिक हैक द्वारा दरकिनार किया जाता है । ऑफ घंटे के दौरान, कैफ़ेटेरिया पर जाएं और उपयोगकर्ताओं द्वारा कीबोर्ड प्रेस रिकॉर्ड करने के लिए एक गुप्त कैमरा सेटअप करें। फिर यह मायने नहीं रखता कि अगर कैफेटेरिया कंप्यूटर अपंग है, या किस प्रकार के एन्क्रिप्शन का उपयोग किया जाता है।
भौतिक परत -> कंप्यूटर परत -> ग्राहक परत -> नेटवर्क परत -> सर्वर परत
नेटवर्किंग के लिए, यदि आपके पास क्लाइंट की तरफ हैश है तो कोई बात नहीं क्योंकि https / ssl लेयर प्लेन पासवार्ड को एन्क्रिप्ट करेगा। तो जैसा कि अन्य उल्लेख करते हैं कि ग्राहक हैशिंग यदि टीएलएस सुरक्षित है, तो अनावश्यक है।