पर सादा पाठ पासवर्ड मैं वर्तमान में एक PHP ओपनआईडी प्रदाता पर काम कर रहा हूं जो HTTPS (इसलिए एसएसएल एन्क्रिप्टेड) पर काम करेगा।
क्या यह गलत है जो मुझे पासवर्ड को सादे पाठ के रूप में प्रेषित करने के लिए है? सिद्धांत में एचटीटीपीएस को अवरुद्ध नहीं किया जा सकता है, इसलिए मुझे कुछ भी गलत नहीं दिख रहा है। या यह कुछ स्तर पर असुरक्षित है और मैं इसे देखने में असफल रहा हूं?HTTPS
यह सुरक्षित है। इस तरह पूरा वेब काम करता है। रूपों में सभी पासवर्ड हमेशा सादे पाठ में भेजे जाते हैं, इसलिए इसे सुरक्षित करने के लिए HTTPS तक।
यदि HTTP अक्षम है, और आप केवल HTTPS का उपयोग करते हैं, तो आप वास्तव में पासवर्ड को सादा पाठ के रूप में प्रेषित नहीं कर रहे हैं।
आपको अभी भी यह सुनिश्चित करना होगा कि आप इसे POST अनुरोध के माध्यम से भेजें, प्राप्त न करें। यदि आप इसे GET अनुरोध के माध्यम से भेजते हैं, तो इसे उपयोगकर्ता के ब्राउज़र इतिहास लॉग या वेबसर्वर के एक्सेस लॉग में सादे टेक्स्ट में सहेजा जा सकता है।
हां, मुझे यह पता था, लेकिन यहां आने वाले अन्य लोगों के पीछे छोड़ना अभी भी एक अच्छी टिप्पणी है। :) – WhyNotHugo
अन्य पोस्टर सही हैं। अब जब कि तुम पासवर्ड की संचरण एन्क्रिप्ट करने के लिए SSL का उपयोग कर रहे हैं, सुनिश्चित करें कि आप एक अच्छा एल्गोरिथ्म और नमक के साथ यह hashing रहे हैं तो यह संरक्षित है जब यह भी बाकी पर है ...
हां, मुझे यह एहसास है, धन्यवाद, मैं केवल यहां ट्रांसमिशन का जिक्र कर रहा था। – WhyNotHugo
हैश ग्राहक पक्ष। क्यूं कर? मुझे आपको थोड़ा प्रयोग के बारे में बताना है। कंपनी कैफेटेरिया में कंप्यूटर तक चलें। कंपनी वेब साइट लॉगिन पेज (https) पर ब्राउज़र खोलें। प्रेस एफ 12, नेटवर्क टैब पर क्लिक करें, लगातार लॉग ऑफ करें, कंसोल को कम करें लेकिन लॉगिन पेज पर वेब पेज खोलें। बैठ जाओ और दोपहर का खाना खाएं। कंपनी के वेबसाइट पर कर्मचारी लॉग ऑन करने के बाद कर्मचारी के रूप में देखें और एक अच्छा छोटा कार्यकर्ता होने पर लॉग आउट होने पर लॉग आउट करें। दोपहर का भोजन समाप्त करें, कंप्यूटर पर बैठें नेटवर्क टैब लाएं और फ़ॉर्म बॉडी में सादा पाठ में प्रत्येक उपयोगकर्ता नाम और पासवर्ड देखें।
कोई विशेष उपकरण नहीं, कोई विशेष ज्ञान नहीं, कोई फैंसी हैकिंग हार्डवेयर नहीं, कोई कीलॉगर्स बस पुराना पुराना F12 नहीं है।
लेकिन हे, एसएसएल की जरूरत है, सोचते रहें। बुरे लोग इसके लिए आपको प्यार करेंगे।
आपकी कैफेटेरिया टिप्पणी कोई समझ नहीं लेती है, इससे कोई फर्क नहीं पड़ता कि मैं इसे कितना पढ़ता हूं। लोग सिर्फ कंप्यूटर पर क्यों चलेंगे और उनके प्रमाण पत्र टाइप करेंगे? आप क्या साबित करना चाहते हैं? इसके अलावा, हैशिंग इस * अधिक * असुरक्षित, किसी भी तरह से नहीं बनायेगी। 200 9 में यह प्रश्न लिखा गया था, यह हैश पासवर्ड के लिए यह एक आम बात थी और उन्हें सादे-पाठ HTTP पर प्रसारित किया गया था। – WhyNotHugo
मैंने इन दोनों को उखाड़ फेंक दिया क्योंकि, हाँ, स्वीकृत उत्तर _is_ कई सालों बाद पढ़ा जा रहा है। यह अच्छा होगा अगर @ कोडडॉग कृपया कुछ शमन रणनीति को इंगित करे। और हाँ, लोग बस यादृच्छिक पीसी तक चलेंगे, उदाहरण के लिए, स्थानीय पुस्तकालय में, और उनके विवरण दर्ज करें! – JoeAC
मैं एक सार्वजनिक कुंजी के साथ पासवर्ड क्लाइंट पक्ष एन्क्रिप्ट करता हूं, फिर फॉर्म में केवल एन्क्रिप्टेड पासवर्ड पोस्ट करता हूं। यह एक विषम कुंजी है इसलिए क्लाइंट साइड सार्वजनिक कुंजी हमलावरों के लिए बेकार है। प्रत्येक लॉग यह एक नई कुंजी जोड़ी उत्पन्न करता है ताकि रीप्ले हमले काम न करें। महत्वपूर्ण प्रयासों में असफल लॉग पर भी कुंजी बदलती है। उपयोगकर्ताओं को लॉग इन स्क्रीन पर आने पर मुख्य जोड़े सर्वर पक्ष उत्पन्न होते हैं। क्लाइंट साइड कोड पर केवल सार्वजनिक कुंजी प्रदान की जाती है। – CodeDog
माइनर नाइटपिक: कुछ लॉगिन फॉर्म इसे सादा पाठ भेजने के बजाय पासवर्ड को हैश करने के लिए जावास्क्रिप्ट का उपयोग करते हैं। – Thorarin
@ थोरिनिन अगर वे वास्तव में हैश करते हैं, तो इसका मतलब है कि सर्वर सादा पाठ में पासवर्ड संग्रहीत कर रहा है ताकि यह सत्यापित करने के लिए उसी नमक के साथ हैश हो सके। Ick! एसएसएल लिपटे पाठ में पासवर्ड भेजना बेहतर है, क्योंकि सर्वर को पासवर्ड को सादे पाठ में स्टोर करने की आवश्यकता नहीं होती है। – DGM
@ डीजीएम: डबल हैशिंग भी एक विकल्प है, इसलिए सादे पाठ पासवर्ड कड़ाई से जरूरी नहीं हैं। – Thorarin