AJAX लॉगिन कॉल में जावास्क्रिप्ट हैशिंग, अधिक सुरक्षा?

Question

साइट पर मैंने कई पोस्ट देखी हैं, AJAX या पारंपरिक रूपों द्वारा किए गए लॉग इन एक दूसरे के समान सुरक्षित हैं। (पुन: Login/session cookies, Ajax and securityAjax login and javascript cookies, is this secure?)

मेरा प्रश्न (रों) है/हैं:

1. अगर मैं उपयोगकर्ता का पासवर्ड (क्लाइंट-साइड के माध्यम से/जावास्क्रिप्ट हैश पुस्तकालयों) इससे पहले कि मैं सर्वर पर भेज हैश , क्या मैं लोगों को आसानी से सुरक्षा बढ़ाता हूं?

2. यदि मैं एक फॉर्म टोकन (एक यादृच्छिक आधारित, एक और समय आधारित) डालता हूं, तो क्या यह सीएसआरएफ हमलों को कवर करता है?

3. क्या मेरे पास ये सभी आधार शामिल हैं? क्या यह फॉर्म सुरक्षित होगा?

Answer 1

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

रीप्ले हमले भी एक समस्या है। अगर मैं प्रमाणीकरण के दौरान हैश को स्नीफ करता हूं, तो मुझे प्रमाणित करने के अनुरोध को फिर से चलाने से मुझे क्या रोक रहा है?

प्रमाणीकरण के लिए संदेश पाचन कार्यों का उपयोग करने वाले प्रोटोकॉल क्लाइंट को एक गैर-युक्त प्रदान करते हैं, जिसे एक बार नमक के रूप में उपयोग किया जाता है। माइक्रोसॉफ्ट के एसएमबी एनटीएलएम प्रमाणीकरण एक अच्छा उदाहरण है, लेकिन इसमें a lot of problems है।

एसएसएल का उपयोग करें, न केवल लॉगिन के लिए। OWASP A9 बताता है कि सत्र आईडी को कभी भी असुरक्षित चैनल पर लीक नहीं किया जाना चाहिए। पासवर्ड के बारे में परवाह करने वाले सभी के बाद यदि आप वास्तविक प्रमाणीकरण प्रमाण-पत्रों को बाद में कुछ मिलीसेकंड बढ़ाते हैं।

अधिकांश लोग लॉगिन के लिए सीएसआरएफ सुरक्षा लागू नहीं करते हैं। सभी हमलावरों को पासवर्ड को पहले स्थान पर जानना होगा, इसलिए "सत्र सवारी" एक महत्वपूर्ण बिंदु है।

Answer 2

यदि हमलावर जानता है कि आप किस चीज का उपयोग कर रहे हैं तो वे इसे क्रैक कर सकते हैं। और यदि आप नमक जोड़ना चाहते हैं तो आपको इसे ब्राउज़र पर भेजना होगा और हमलावर इसे रोक सकता है। नमक के रूप में समय का उपयोग करना भी काम नहीं करेगा क्योंकि केवल अपेक्षाकृत कम समय होता है ताकि वे इसे भी हल कर सकें।

Answer 3

थोड़ा सा तरफ, लेकिन सवाल के जवाब में 3. नहीं! यह भी याद रखें कि AJAX और मानक रूप भी असुरक्षित एक दूसरे के रूप में हैं।

सुरक्षित प्रमाणीकरण लागू करना कठिन है। जब तक आप इसे अकादमिक अभ्यास के रूप में नहीं कर रहे हैं, तो मैं दृढ़ता से आपके ढांचे के द्वारा प्रदान की जाने वाली लाइब्रेरी का उपयोग करने की सलाह दूंगा, यदि आप भाग्यशाली हैं तो एक अच्छा होना पर्याप्त है।

आपको निम्न जैसे चीजों पर विचार करने की आवश्यकता होगी, और भी बहुत कुछ।

• सत्र कुकी में उपयोग के लिए एक उपयुक्त यादृच्छिक और अनुपयोगी सत्र आईडी लागू करें।
• सत्र आईडी को मजबूर करने की अनुमति न दें।
• जब अनुमतियां या प्रमाण-पत्र बदल दिए जाते हैं (उदा। क्योंकि उपयोगकर्ता अब लॉग इन या आउट हो गया है) तो तुरंत सत्र को अमान्य कर दें और एक नया प्रारंभ करें।
• लॉगआउट सुविधा प्रदान करें, और लॉगआउट पर सत्र को अमान्य करना सुनिश्चित करें।
• कुकी को Http पर सेट करें- केवल HTTPS की आवश्यकता है और कुकी को केवल सुरक्षित करने के लिए सेट करें।
• कुछ अन्य जानकारी की जांच करने के लिए सत्र वैधता को प्रतिबंधित करने पर विचार करें जो उपयोगकर्ता से मेल खाने में मदद करता है उदा। उपभोक्ता अभिकर्ता।
• गैर-उपयोग के बाद हमेशा सत्र समाप्त करें और उपयोगकर्ता को अपने पुराने http सत्र में पुन: कनेक्ट करके "मुझे लॉग इन रखें" लागू न करें।
• सुनिश्चित करें कि 2 सत्रों में एक ही समय में एक ही सत्र आईडी नहीं हो सकती है
• सुनिश्चित करें कि सत्र समाप्त होने पर सभी सत्र डेटा नष्ट हो जाएंगे। एक नया उपयोगकर्ता साथ आ रहा है, बस एक सत्र आईडी असाइन किया जा सकता है जिसका उपयोग पहले किया गया था। इस नए सत्र में सत्र डेटा तक पहुंच नहीं होनी चाहिए जिसे पहले उस सत्र आईडी के विरुद्ध सेट किया गया था।