2009-08-16 19 views
11

मैं वर्तमान में अपने वेब अनुप्रयोगों में से एक को फिर से फैक्टर कर रहा हूं और मैं अपनी सुरक्षा में सुधार करने के लिए कुछ सलाह की उम्मीद कर रहा था।कुकी आधारित प्रमाणीकरण को सुरक्षित करना

मुझे लगता है कि एप्लिकेशन एएसपीनेट में है और वर्तमान कार्यान्वयन मुझे एकीकृत प्रमाणीकरण का उपयोग करने से रोकता है। यह किसी भी तरह से एक आवेदन नहीं है जिसके लिए उच्च सुरक्षा की आवश्यकता है, मुझे बस अपने आधार कवर करना पसंद है।

अतीत में मैंने आईडी और टोकन संग्रहीत किया है। टोकन उपयोगकर्ता की आईडी का एक हैश है (उपयोगकर्ता की नमक (ऑथ जानकारी से मूल्य का पुन: उपयोग) जब कोई उपयोगकर्ता साइट पर जाता है तो आईडी टोकन के विरुद्ध चेक की जाती है और तदनुसार आ जाती है।

यह मेरे लिए होता है कि यहां एक बड़ा छेद है। सैद्धांतिक रूप से अगर किसी को नमक मूल्य पर अपना हाथ मिल गया तो उन्हें केवल हैश एल्गोरिदम का अनुमान लगाना चाहिए और जब तक वे अंदर नहीं आते हैं, तब तक संभव आईडी के माध्यम से पुन: प्रयास करें। मुझे ऐसा होने की उम्मीद नहीं है, लेकिन यह अभी भी एक गलती की तरह लगता है ।

उपयोगकर्ता कुकीज़ को ठीक से पुष्टि करने के तरीके पर कोई सलाह नहीं दी गई है?

+0

मैं उस परेशानी के उस हिस्से को जोड़ दूंगा जो मुझे परेशान करता है कि अगर किसी को साइट के लिए नमक मूल्य और पासवर्ड हैश प्राप्त करना होता है तो यह उन्हें शुद्ध पासवर्ड प्रमाणीकरण के साथ कुछ भी अच्छा नहीं करेगा। ऐसा लगता है कि कुकी प्रमाणीकरण की एक अच्छी विधि एक ही फैशन में काम करेगी। –

उत्तर

10

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

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

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

+0

कुकी प्रमाणीकरण का उपयोग करते समय आपको क्रॉस साइट स्क्रिप्ट जालसाजी (सीआरएसएफ) से सावधान रहना होगा। ब्राउज़र उपयोगकर्ता की तरफ से प्रमाण पत्र भेज रहा है और ब्राउजर को हमलावर के लिए भेजने में भी संभव है। लेकिन इसे एक nonce का उपयोग करके रोका/छोटा किया जा सकता है। अधिक जानकारी के लिए Google इसे। – thebiggestlebowski

2

दो तरीके:

  1. एक सममित एल्गोरिथ्म (एईएस) के साथ एन्क्रिप्ट यह।

यह अच्छा है क्योंकि यह आपको इसे डिक्रिप्ट करने देता है; लेकिन यह तर्क दिया जा सकता है कि आपको इसे डिक्रिप्ट करने की आवश्यकता नहीं है (आप जो भी स्टोर करते हैं उसके आधार पर)।

  1. हैश और पर हस्ताक्षर करें। फिर यह एक निजी कुंजी का उपयोग करता है, इसलिए यदि कोई सटीक सामग्री जानता है, तो भी वह हैश को पुन: उत्पन्न नहीं कर सकता है, क्योंकि उन्हें निजी कुंजी की आवश्यकता होती है।

मैं शायद (और पहले) विकल्प # 1 के साथ जाऊंगा।

0

क्यों न केवल कुकी में हैश स्टोर करें, या कोई अन्य छद्म यादृच्छिक संख्या? फिर उपयोगकर्ता आईडी प्राप्त करने के लिए डेटाबेस के खिलाफ जांचें।

अन्य चीजें: , केवल कुकी http बनाने यानी जावास्क्रिप्ट साथ सेट नहीं किया जा सकता है, तो यह एक विकल्प है, यह केवल https डेटा के साथ प्रेषित किया जा कर

4

कुकी मूल्य के रूप में सत्र आईडी को संग्रहीत करने का सबसे अच्छा तरीका है।

जब भी उपयोगकर्ता लॉग इन करता है, तो आप डेटाबेस या किसी अन्य सत्र स्टोर में एक यादृच्छिक सत्र आईडी के साथ एक रिकॉर्ड बनाते हैं। एक कुकी में आईडी रखो। जब आप कुकी को बाद में देखते हैं, तो आप डेटाबेस से सभी उपयोगकर्ता जानकारी पुनर्प्राप्त कर सकते हैं।

यह दृष्टिकोण निम्नलिखित है लाभ,

  1. यह बहुत सुरक्षित है। सत्र आईडी बस एक यादृच्छिक संख्या है। आपको समझौता कुंजी या नमक के बारे में चिंता करने की ज़रूरत नहीं है।
  2. कुकी को आसानी से सर्वर से निरस्त किया जा सकता है। आपको केवल सत्र रिकॉर्ड को हटाना है और यह आईडी बेकार है।
  3. कुकी मूल्य वास्तव में छोटा हो सकता है।

यदि यह आपके लिए काम नहीं करता है, तो एन्क्रिप्शन आज़माएं। हैश मेरी आखिरी पसंद होगी। हैश खुद बेकार है। आपको उपयोगकर्ता आईडी और अन्य जानकारी को एक अलग कुकी में स्पष्ट रूप से स्टोर करना होगा। आपने उपयोगकर्ता की जानकारी का पर्दाफाश समाप्त कर दिया।

+1

ज़ेड कोडर: जबकि यह सच है तो आपको उपयोगकर्ता आईडी का पर्दाफाश करने की आवश्यकता होगी यदि आपके पास हैश; यह आम तौर पर महत्वपूर्ण नहीं है इसलिए इसे उजागर करने में कोई समस्या नहीं है। आपका सत्र आईडी दृष्टिकोण ठीक है, लेकिन, जैसा कि आप कहते हैं, इसे डीबी में कुछ सहेजना होगा। यह वांछित नहीं हो सकता है अगर यह जानकारी है जो थोड़ी देर के लिए जीनी चाहिए। –

संबंधित मुद्दे