2011-01-23 14 views
8

मुझे आश्चर्य है कि मुझे किसी फॉर्म में (मास्क किए गए) पासवर्ड फ़ील्ड को फिर से पॉप्युलेट करना चाहिए जब अन्य फ़ील्ड मान्य नहीं होते हैं। मैं दोनों वेब जहां प्रपत्र या तो हैं पर देखा है:एक फॉर्म में पासवर्ड फ़ील्ड को फिर से पॉप्युलेट करना एक सुरक्षा समस्या होगी?

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

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

+1

यदि आप HTTPS के माध्यम से फ़ॉर्म दस्तावेज़ की सेवा नहीं करते हैं, तो ** बिल्कुल नहीं **। – Gumbo

+0

संभवतः आप वास्तविक पासवर्ड नहीं डाल पाएंगे। चूंकि आपने केवल अपने हैश को संग्रहीत किया है, वैसे भी आप कैसे कर सकते हैं। –

+0

वह उस परिदृश्य के बारे में बात कर रहा है जिसमें उपयोगकर्ता लॉग इन कर रहा है, सही पासवर्ड दर्ज करता है, लेकिन गलत ईमेल/उपयोगकर्ता नाम। उस स्थिति में, वह फॉर्म को सबमिट करना चाहता है और पासवर्ड सहित इनपुट में रखी गई वही जानकारी के साथ फिर से प्रस्तुत किया जाता है। – kbuilds

उत्तर

8

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

+0

मैंने इसके बारे में भी सोचा है। अगर मैं सत्र में संग्रहीत पासवर्ड को अतिरिक्त रूप से एन्क्रिप्ट करता हूं तो यह और भी सुरक्षित होगा। मुझे लगता है कि यह एक उपयुक्त समाधान होगा? – Frank

+1

@ फ्रैंक: बिल्कुल। आपको सत्र सादे पाठ में इसे स्टोर करने की भी आवश्यकता नहीं है। नमकीन हैश स्टोर करें। और इस तरह टोकन मैचों, बस इसे डीबी में स्टोर करें। यदि नहीं, तो इसे फेंक दें ... अच्छा विकल्प (मैं इसे संपादित कर दूंगा) – ircmaxell

+0

लेकिन आप किस यादृच्छिक टोकन का उपयोग करेंगे? विशेष रूप से: लंबाई की एक यादृच्छिक टोकन? – Gumbo

2

इसे फिर से पॉप्युलेट करना उपयोगकर्ता के लिए अधिक आरामदायक है।

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

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

0

बिल्कुल, अपने पासवर्ड फ़ील्ड साफ़ करें और उन्हें फिर से पॉप्युलेट न करें। प्रयोज्यता के लिए सुरक्षा समझौता मत करो।

0

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

मैं व्यक्तिगत रूप से उपयोगकर्ता को अन्य उपयोगकर्ता नाम + पासवर्ड जोड़ी को याद रखने की आवश्यकता के बजाय ओपनआईडी के साथ जाऊंगा (जो बेहतर करने के लिए उपयोगिता को भी प्रभावित करता है)।

0

यदि आपको सर्वर से क्लाइंट से वास्तविक पासवर्ड (या उससे प्राप्त कुछ भी) भेजने की आवश्यकता है, तो इसे फिर से पॉप्युलेट करने के लिए, यह एक प्रमुख सुरक्षा छेद है।

यदि आप जो भी करते हैं, तब तक क्लाइंट पर स्थानीय रूप से पासवर्ड सहेजते हैं जब तक कि फॉर्म सबमिट नहीं हो जाता है (पृष्ठ को पुनः लोड नहीं करके, जैसे जावास्क्रिप्ट के माध्यम से), तो यह मेरे लिए ठीक लगता है।

+0

यदि सर्वर सिर्फ उसी स्ट्रिंग को वापस भेजता है जो उपयोगकर्ता मूल रूप से टाइप करता है, तो "प्रमुख सुरक्षा छेद" कैसा होता है? – Pointy

+0

एचटीटीपीएस से अधिक शायद ठीक रहेगा, हालांकि सैद्धांतिक रूप से यह दोहराए गए सादे टेक्स्ट हमलों (समान सादे टेक्स्ट कई बार एन्क्रिप्टेड) ​​की अनुमति देता है। ऐसा नहीं है कि मैं एसएसएल में ऐसी किसी भी भेद्यता के बारे में जानता हूं। कोई सवाल नहीं है कि सबसे अच्छा यह सब नहीं भेजना होगा। – sinelaw

0

नहीं, यह नहीं होगा (अगर सही हो)।

  • नेटवर्क में एक हमलावर (यानी ब्राउज़र और सर्वर के बीच) क्लाइंट को भेजे गए पासवर्ड को देखा होगा। यदि आप HTTPS का उपयोग कर रहे हैं, तो आप फ़ॉर्म के साथ-साथ इसके लक्ष्य के लिए इसका उपयोग कर सकते हैं।
  • ब्राउज़र-पक्ष हमलावर पासवर्ड फ़ील्ड पर श्रोता पंजीकृत कर सकता था या अनुरोध को रोक सकता था।
  • एक तृतीय-पक्ष हमलावर उपयोगकर्ता के उपयोग के प्रॉक्सी से भरे हुए पृष्ठ को लाने का प्रयास कर सकता है। पृष्ठ को कैश होने से रोकने के लिए उपयुक्त Cache-Control शीर्षलेख सेट करें।
+0

@ फ्रैंक मिशेल उत्तर में सूचीबद्ध शर्तों का सम्मान करके, यदि आप इसका उपयोग करते हैं और उचित कैश हेडर सेट करते हैं तो सब कुछ के लिए HTTPS का उपयोग करें। – phihag

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

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