क्या कोई तरीका है (HTTP प्रमाणीकरण के अलावा, जिसे मैं इकट्ठा करता हूं इंटरनेट पर स्वाभाविक रूप से असुरक्षित है?) सत्र कुकीज़ का उपयोग करके पारंपरिक तरीके से लॉग इन और प्रमाणीकरण को संभालने के लिए "वास्तविक जीवन" वेबसाइट के लिए?क्या "क्लासिक" कुकी प्रमाणीकरण के लिए कोई व्यवहार्य विकल्प हैं?
HTTP digest authentication (जो HTTP मूल प्रमाणीकरण से काफी अलग जानवर है) सीधे HTTP पर काफी सुरक्षित है, और सर्वर पर लागू करना मुश्किल नहीं है। तार पर कुछ भी नहीं भेजा गया है जो बता सकता है कि पासवर्ड क्या है, केवल वह जानकारी जो क्लाइंट को सर्वर पर प्रदर्शित करने की अनुमति देती है कि उनके पास सही पासवर्ड है।
आप कैसे लागू करने के लिए HTTP आपके आवेदन, Paul James has an excellent article on it में प्रमाणीकरण को पचाने की एक सभ्य स्पष्टीकरण चाहते हैं।
HTTP प्रमाणीकरण के साथ ही वास्तविक समस्या ब्राउज़र को अपने आप में है: यूआई भयानक है, लेकिन उस overcome with some Javascript हो सकता है।
HTTP प्रमाणीकरण HTTP HTTP का उपयोग करते समय असुरक्षित नहीं है।
एसएसएल (https: //) वेबसाइट के साथ उपयोग किए जाने पर HTTP मूल प्रमाणीकरण पूरी तरह सुरक्षित है क्योंकि क्रेडेंशियल्स समेत सभी HTTP ट्रैफिक एन्क्रिप्ट किए जाएंगे। एक व्यक्तिपरक दोष हालांकि इस विधि का उपयोग करते समय आपके उपयोगकर्ताओं को आपकी साइट पर लॉग इन करने के लिए अपने ब्राउज़र के प्रमाणीकरण पॉपअप से बातचीत करने की आवश्यकता होगी।
तो संभवतः प्रमुख वेबसाइटें HTTP ऑथ का उपयोग नहीं करती हैं क्योंकि एसएसएल दोनों सिरों पर संसाधन गहन है? प्रमाणीकरण पॉपअप के साथ बातचीत करने में सक्षम होने वाला उपयोगकर्ता एक समस्या क्यों हो सकता है? अगर उनके पास विकलांगता है तो क्या इस समस्या को दूर करने के लिए उनके पास पहले से ही तंत्र नहीं होंगे? –
एसएसएल के बिना, वेब प्रमाणीकरण का कोई भी रूप कम सुरक्षित है, इसलिए निर्णय में लॉगिन की आवश्यकता सुरक्षा के स्तर के साथ निर्णय लेने के लिए और कम से कम प्रमाणीकरण किस प्रकार के प्रमाणीकरण के साथ किया जाता है। ब्राउजर पॉपअप चिंता ज्यादातर साइट डिज़ाइन के बारे में है क्योंकि यह जगह से बाहर निकल सकती है और उपयोगकर्ताओं को झुकाव कर सकती है –
जब आप https का उपयोग कर रहे हों, तो आप अपने क्लाइंट के ब्राउज़र में प्रमाणपत्र भी इंस्टॉल कर सकते हैं और उसे सत्यापित कर सकते हैं। myopenid इसे अपने ओपनआईडी खातों के लिए प्रदान करता है। मेरे पास एक है और यह वास्तव में अच्छी तरह से काम करता है (क्लाइंट-साइड पॉइंट व्यू से)।
स्पष्ट होने के लिए, ऐसा करने का एकमात्र असली तरीका HTTPS के माध्यम से है।
लेकिन, के बाद से मुझे लगता है यह एक विकल्प नहीं है, और मैं भी आप एक "पूरी तरह से प्रबंधित लॉगिन" प्रणाली के लिए देख रहे हैं मान, मैं जारी:
अन्य HTTPS की तुलना में यह जावास्क्रिप्ट का उपयोग करने के लिए संभव है क्लाइंट साइड पर पासवर्ड की सुरक्षित हैशिंग करने के लिए, तारों के सादे पाठ पासवर्ड को प्रकट करने से रोकने के लिए, लेकिन यह केवल आधा समाधान है।
इस दृष्टिकोण के साथ समस्याओं कर रहे हैं:
एक और दृष्टिकोण एक अधिक जटिल चुनौती/प्रतिक्रिया तंत्र है।
और उस के साथ समस्या:
अब, निष्पक्ष होना करने के लिए, समस्या # 2 नहीं एक खतरा के रूप में यह लग रहा है के रूप में बड़ा है। असल में जब आप HASH प्रमाणीकरण का उपयोग करते हैं, तो हैश स्वयं को "कुंजी" के स्तर तक बढ़ाया जाता है।
इस बिंदु यह काफी यादृच्छिक रूप से जनरेट लॉगिन ReferrenceID, उनके सत्र आईडी के समान स्टोर करने के लिए एक कुकी उपयोग करने के लिए सुरक्षित है पर, लेकिन सर्वर चतुर्थ या करने के लिए कुंजी के हिस्से के रूप जिक्र IP का उपयोग एन्क्रिप्ट करने के लिए चाहते हो सकता है अन्य उपयोगकर्ताओं को रेफरेंस आईडी को हाइजैक करने से रोकें।
फिर भी, मुझे आशा है कि अपने डिजाइन के रास्ते में दिशा का एक छोटा सा प्रदान करता है।
HttpOnly Cookies के साथ संयोजन में एन्क्रिप्शन के लिए SSL का उपयोग करने XSS रोकने में मदद करने के लिए कुकीज़ का उपयोग कर अपने सबसे अच्छे शर्त है। मैं यह नहीं कहूंगा कि यह बुलेट प्रूफ है, यद्यपि।
यह एक्सएसएस के खिलाफ सुरक्षा नहीं करेगा, इससे इसे कठिन शोषण मिलेगा। –
लेकिन यह अभी भी एक इंटरैक्टिव एक्सएसएस चैनल के साथ शोषक है। बीईएफ, ब्राउजरराइडर, एक्सएसएस शैल और एक्सएसएस टनलिंग –
पर एक नज़र डालें टिप्पणी के लिए धन्यवाद। मैंने अपना जवाब अपडेट किया। –
सबसे पहले, HTTP प्रमाणीकरण एसएसएल तथ्य यह है कि आप एक सच्चे "लॉगआउट" कार्यक्षमता लागू नहीं कर सकते के अलावा अन्य से अधिक सुरक्षित है। उपयोगकर्ता को अपने ब्राउज़र को बंद करने की आवश्यकता है, जो बहुत खराब है।
दूसरा, इसे सुरक्षित बनाने के लिए आपको सभी मामलों में HTTPS का उपयोग करने की आवश्यकता है, उसके बाद आपको मूल एथ जैसे "डाइजेस्ट" और "एनटीएलएम ऑथ" मिलते हैं।
सुधार: एचटीटीपीएस का उपयोग करते समय HTTP एथ एसएसएल सत्र के रूप में सुरक्षित है। – Randolpho
आप मूल प्रमाणीकरण में लॉगआउट कार्यक्षमता लागू नहीं कर सकते, यह बहुत बकवास है :) –
फ़ायरफ़ॉक्स के लिए, ये कीड़े देखें: https://bugzilla.mozilla.org/show_bug.cgi?id=55181 और https: //bugzilla.mozilla .org/show_bug.cgi? id = 287957। लेकिन हाँ, मैं सहमत हूं। –