2010-01-20 19 views
56

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

if (this.ChkRememberme != null && this.ChkRememberme.Checked == true) 
    { 
    HttpCookie cookie = new HttpCookie(TxtUserName.Text, TxtPassword.Text); 
    cookie.Expires.AddYears(1); 
    Response.Cookies.Add(cookie); 
    } 

क्या मैं जानना चाहता हूँ है:

  • यह सुरक्षित कुकीज़ में पासवर्ड स्टोर करने के लिए है यह मेरा कोड है?
  • ऐसा करने का उचित तरीका क्या है?
  • कुकी के लिए समय निर्धारित करने में सर्वोत्तम प्रथाएं क्या हैं?
+13

प्रपत्र प्रमाणीकरण इसे हसल दें! फॉर्म प्रमाणीकरण.SetAuthCookie (उपयोगकर्ता नाम, सच); वास्तव में –

उत्तर

57

कुकीज़ में पासवर्ड स्टोर करना सुरक्षित नहीं है क्योंकि वे सादे पाठ के रूप में उपलब्ध हैं।

कुकीज़ के बारे में कुछ जवाब खोजने के लिए एक अच्छी जगह Cookie Central. सदस्यता के लिए आम तौर पर एक टोकरी कहा जाता है जिसे 'टोकन' कहा जाता है जिसे वेबसाइट से जारी किया जाता है, जब आप अपना उपयोगकर्ता नाम और पासवर्ड प्रदान करते हैं। इस प्रक्रिया के बारे में अधिक जानकारी आप article में पा सकते हैं। - सच है अगर यह लगातार कुकीज़ कि आपके जाने के बाद तक चलेगा पैदा करेगा

FormsAuthentication.SetAuthCookie(userName, isPersistanceCookie); 

दूसरा पैरामीटर के लिए प्रयोग किया जाता है कार्यक्षमता "मुझे याद रखें": ASP.NET में रूपों प्रमाणीकरण का उपयोग जब आप इस तरह प्रमाणीकरण कुकी सेट कर सकते हैं जगह। तुम भी प्रोग्राम के इस तरह कुकी में हेरफेर कर सकते हैं:

HttpCookie authCookie = 
    HttpContext.Current.Request.Cookies[FormsAuthentication.FormsCookieName]; 
+3

। कहीं भी पासवर्ड स्टोर करना सुरक्षित नहीं है। केवल एक हैश संस्करण को स्टोर करें और इसके खिलाफ जांच करें। –

+5

आपको यहां एक हैश संस्करण की भी आवश्यकता नहीं है (और इससे बचें क्योंकि इसका अपना जोखिम है, उदाहरण के लिए नमक की कमी)। एक मनमाना टोकन जिसका उपयोगकर्ता आईडी के साथ कोई गणितीय संबंध पर्याप्त नहीं है - टोकन को समझने वाली एकमात्र पार्टी आपकी लॉगिन सेवा है, और यह डीबी लुकअप द्वारा टोकन की जांच करता है। – MSalters

9

यह आपको कभी नहीं करना चाहिए क्या है, क्योंकि यह बहुत आसान है एक कुकी का मान बदल सकते हैं और सर्वर से वापस भेजने के लिए। यहां तक ​​कि "कुकी को एक कुकी में" नाइविस्ट्स "के रूप में भी खराब किया जाता है, यह गलत है, क्योंकि मैं इसे" पांडिया चेन्डूर "के रूप में लॉग इन कर सकता हूं।

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

आप उन्हें कुकी में संग्रहीत सत्र आईडी दे सकते हैं, क्योंकि वे किसी और चीज को बदलते हैं (जब तक कि वे किसी अन्य सत्र से वैध सत्र आईडी नहीं जानते)।

क्या माइक्रोसॉफ्ट के MSDN says about using cookies:

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

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

इसी प्रकार, जानकारी को आप कुकी से बाहर निकलने की संदिग्ध रहें। यह मानें कि डेटा जैसा है जब आपने इसे लिखा था; कुकी मानों के साथ काम करने में समान सुरक्षा उपाय का उपयोग करें जो आप उपयोगकर्ता द्वारा वेब पेज में टाइप किए गए डेटा के साथ करेंगे। इस विषय में पहले उदाहरण दिखाए गए हैं किसी पृष्ठ, में मान प्रदर्शित करने से पहले कुकी की सामग्री को HTML-एन्कोडिंग दिखाएं, जैसा कि आप उपयोगकर्ताओं से प्राप्त जानकारी प्रदर्शित करने से पहले करेंगे।

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

25

नहीं! कुकीज़ में पासवर्ड स्टोर न करें!

ASP.NET में, यदि कुकी लगातार है

FormsAuthentication.SetAuthCookie(username, true); 

दूसरा तर्क के मूल्य निर्धारित करता है का उपयोग करें (मुझे चेकबॉक्स का मूल्य ना भूलें)।

0

यह बिल्कुल सुरक्षित नहीं है। कुकीज़ क्लाइंट कंप्यूटर में संग्रहीत की जाती है, जिसे छेड़छाड़ की जा सकती है।

15

नहीं, दूरस्थ रूप से सुरक्षित नहीं है। आपको कोई गारंटी नहीं है कि कुकीज़ को सादा पाठ में संग्रहीत नहीं किया जाता है (और वास्तव में, अधिकांश कार्यान्वयन उन्हें सादा पाठ के रूप में संग्रहित करते हैं)।

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

मैं एक एन्क्रिप्टेड कुकी स्ट्रिंग का उपयोग करता हूं जिसमें उपयोगकर्ता के खाते का नाम उस टोकन के साथ संयुक्त होता है जो मेरे सर्वर पर एक तालिका को छोड़कर उपयोगकर्ता के खाते से जुड़े किसी अन्य (अन्य) तरीके से नहीं होता है। जब उपयोगकर्ता साइट पर वापस आ जाता है, तो हम कुकी को डिक्रिप्ट करते हैं और देखते हैं कि टोकन वास्तव में उस खाते से जुड़ा हुआ है या नहीं। टोकन (और इसलिए कुकी) प्रत्येक ऑटो-लॉगिन को बदलता है, और उस ऑटो-लॉगिन के लिए उपयोग किए गए किसी को अमान्य करता है। (कई स्थानों से ऑटो-लॉगिन की अनुमति देने के लिए टोकन और खाते के बीच एक से अधिक संबंध हैं। यदि आप चाहें तो आप इसे सीमित कर सकते हैं।) टोकन का समय समाप्त हो जाता है यदि उनका उपयोग X दिनों के भीतर नहीं किया जाता है। (यह न केवल कुकी की अवधि सीमित करके किया जाता है; यह सर्वर-साइड भी किया जाता है।) जीवन को बनाने के लिए कुछ अन्य चीजें हैं जो बिट कुकी को डीकोड करने की कोशिश करने वाले किसी व्यक्ति के लिए मुश्किल है (इसे सफलतापूर्वक डिक्रिप्ट कर रहा है) या एक चोरी हुई कुकी (जिसे डिक्रिप्शन की आवश्यकता नहीं है) का उपयोग करें, लेकिन कोई बात नहीं है ओवरकिल जाने में (फिर से, "मुझे याद रखें" स्वाभाविक रूप से असुरक्षित है)।

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

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

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

+0

प्रत्येक टोकन में जो टोकन बदलता है, वह अलग-अलग स्थानों ("घर" और "काम") से अलग खाते से एक ही खाते में एक ऑटो लॉगिन को प्रतिबंधित करेगा। –

+0

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

2

कुकीज में पासवर्ड स्टोर करना सुरक्षित नहीं है क्योंकि वे सादे पाठ के रूप में उपलब्ध हैं। लेकिन यदि आपका पसंदीदा मानदंड ऐसा करना है या कोई उपयोगकर्ता आवश्यकता है तो आप तारों को एन्क्रिप्ट करके ऐसा कर सकते हैं। जो इसे सुरक्षित रख सकता है।

लेकिन यह अनुशंसित नहीं है,

2

मैं तुम्हें उपयोगकर्ता नाम के साथ एक टोकन और एक एन्क्रिप्टेड प्रमाणीकरण स्ट्रिंग जो आप विंडोज पहचान से मिलता है बनाने की जरूरत है। कुकी पर पासवर्ड स्टोर करने की जरूरत नहीं है। हमारे पास हमारा एप्लिकेशन है जो उपयोगकर्ता नाम और प्रमाणीकृत स्ट्रिंग

2

बीटीडब्लू, स्टोर पासवर्ड हर जगह सुरक्षित नहीं है, दोनों क्लाइंट और सर्वर-साइड।

आपको ऐसा करने की आवश्यकता नहीं है।

1

क्या Branislav ने कहा, और ...

इसके अलावा अपने कुकीज़ में संवेदनशील डेटा डाल नहीं करने के लिए, आप भी उन्हें कम से कम रखकर सुरक्षित करना चाहिए अपने web.config में निम्नलिखित:

<httpCookies httpOnlyCookies="true" /> 

अधिक जानकारी के लिए देखें: How exactly do you configure httpOnlyCookies in ASP.NET?

-2
  • आप SSL जो आप करना चाहिए अगर आप किसी भी सुरक्षित जानकारी प्रसारित करने का उपयोग करते हैं, कि को हटा देता है एक तीसरी पार्टी अपने वेब यातायात सुनने से। कुकी में उपयोगकर्ता क्रेडेंशियल्स को संग्रहीत करने के बावजूद यह वही समस्या होगी क्योंकि जब भी वे सर्वर पर अपना उपयोगकर्ता नाम और पासवर्ड भेजते हैं, जहां मुझे लगता है कि सर्वर इसे हैश करता है और उस उपयोगकर्ता के लिए आपके पास हैश पासवर्ड के मुकाबले इसकी तुलना करता है।

  • अन्य डोमेन क्रॉस-उत्पत्ति के कारण आपकी कुकी को कभी भी पढ़ने में सक्षम नहीं होंगे, इसलिए यह कोई समस्या नहीं है।

  • तो वास्तव में केवल एकमात्र "सुरक्षा छेद" अगर आप इसे कॉल करना चाहते हैं तो यह है कि अगर कोई शारीरिक रूप से अपने कंप्यूटर तक पहुंच प्राप्त करता है।यदि ऐसा होता है तो वे उस व्यक्ति से वैसे भी किसी भी जानकारी प्राप्त करने की संभावना रखते हैं। जब आप क्रोम ऑटो आपके लिए लॉगिन फॉर्म भरते हैं तो आप कैसे समझाते हैं, क्या यह सुरक्षित है? मुझे यकीन है कि वे इसे सादे पाठ में संग्रहित नहीं कर रहे हैं, लेकिन इससे कोई फर्क नहीं पड़ता। यदि आप किसी ऐसे पृष्ठ पर जाते हैं जो क्रोम ऑटो भरता है तो आप केवल फॉर्म से पासवर्ड कॉपी कर सकते हैं और देख सकते हैं कि अब आपके पास उस व्यक्ति का पासवर्ड है।

  • यह वास्तव में नीचे आता है कि आपको "सुरक्षित" होने की आवश्यकता है। मैं सहमत हूं कि एक टोकन के रूप में एक समाप्ति के साथ उपयोगकर्ताओं की जानकारी एन्क्रिप्ट करना सेवा कॉल प्रमाणित करने का सबसे अच्छा तरीका है और यह लचीलापन प्रदान करता है। मुझे कुकी में लॉगिन प्रमाण-पत्र संग्रहीत करने के साथ समस्या दिखाई नहीं दे रही है।

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

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