वेब अनुप्रयोग प्रमाणीकरण / सुरक्षा (किसी भी प्लेटफ़ॉर्म) के लिए सर्वोत्तम अभ्यास


12

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

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

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

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

क्या इस दृष्टिकोण के साथ कोई बड़ी सुरक्षा खामियां हैं? क्या आपके पास कोई बेहतर सुझाव है?


जब एक-तरफ़ा एन्क्रिप्टेड (यानी हैशेड) पासवर्ड को संग्रहीत करते हैं, तो सुनिश्चित करें कि आप या तो एक मजबूत हैश (यानी एमडी 5 नहीं) का उपयोग करें या पासवर्ड को नमक करें (देखें stackoverflow.com/questions/420843/… ) या दोनों।
जॉर्डन रीटर

OWASP वेबसाइट ( owasp.org ) देखें। उनके पास बहुत उपयोगी सुरक्षा जानकारी है, जिसमें विभिन्न प्रोटोकॉल के लिए "चीट शीट" शामिल हैं।
राल्फ

फॉर्म आधारित वेबसाइट प्रमाणीकरण के लिए कुछ दिशा-निर्देश यहां दिए गए हैं stackoverflow.com/a/477578/463478
केवल आप

जवाबों:


13

कुछ उच्च स्तरीय सुझाव:

  1. केवल वही डेटा स्टोर करें जिसकी आपको जरूरत है
  2. जब आप इसे स्टोर करते हैं तो हमेशा संवेदनशील डेटा (SSN, पासवर्ड, क्रेडिट कार्ड # आदि) को एन्क्रिप्ट करें
  3. संवेदनशील डेटा संचारित / प्राप्त करते समय हमेशा SSL का उपयोग करके ट्रैफ़िक को एन्क्रिप्ट करें
  4. यदि जानकारी की संवेदनशीलता के बारे में संदेह है, तो इसे एन्क्रिप्ट करें
  5. उपयोगकर्ता इनपुट पर विश्वास न करें (कोई व्यक्ति कुछ बुरा दर्ज करने का प्रयास करेगा)
  6. अपने डेटा पर भरोसा न करें (कोई व्यक्ति इसे डेटाबेस में बदल सकता है - उदाहरण के लिए दुर्भावनापूर्ण स्क्रिप्ट को इंजेक्ट करना)
  7. अपना स्वयं का एन्क्रिप्शन रोल न करें
  8. एप्लिकेशन / डेटाबेस होस्ट करने वाले सर्वर को सुरक्षित करें
  9. सुरक्षा के लिए अंतिम उपयोगकर्ताओं पर बोझ बढ़ाएं (पासवर्ड प्रतिबंध, पासवर्ड कभी उजागर न करें, ईमेल में URL न भेजें, सत्र का समय कम करें, आदि)

मेरा सुझाव है कि आप वेब एप्लिकेशन हासिल करने के लिए एक पुस्तक प्राप्त करेंगे। एक ही उत्तर / ब्लॉग / लेख में व्यक्त करने के लिए बहुत अधिक जानकारी है। अकेले एन्क्रिप्शन का विषय पर्याप्त है।


अपने स्वयं के एन्क्रिप्शन को रोल करने के बजाय SSL का उपयोग करने के पीछे क्या तर्क है? क्या आप WS-Security जैसे कुछ का उपयोग करके अपने स्वयं के एन्क्रिप्शन को रोल करने पर विचार करेंगे? एसएसएल सेट करना एक दर्द हो सकता है।
श्री जेफरसन

यह अच्छी चेकलिस्ट है। मुझे आश्चर्य है कि इस पर अधिक मत नहीं हैं।
क्रिस्टोफर होच

2
@ Mr.Jefferson मैं उस समय का 99.999999% कहना चाहूँगा जब आप "अपना स्वयं का एन्क्रिप्शन रोल करना चाहते हैं"।
जैच लीटन

2

आप ब्राउज़र व्यवहार को ओवर-राइड करने का प्रयास कर सकते हैं - यहां कुछ अच्छी सलाह:

/programming/32369/disable-browser-save-password-functionality


1
अच्छा लिंक। मुझे व्यक्तिगत रूप से ऐसा नहीं लगता है कि डेवलपर्स के रूप में यह हमारा व्यवसाय है कि उपयोगकर्ता की पसंद को ओवरराइड करें, लेकिन मैंने एक ग्राहक के लिए एक साइट बनाई है, जिसने इसकी मांग की है, इसलिए यह जानना महत्वपूर्ण है कि इसे कैसे करना है।
कार्सन 63000

1

मैं कहूंगा कि आपको ठीक होना चाहिए।

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

यदि SSL पर लॉगिन पेज को एन्क्रिप्ट नहीं किया गया है, तो एक हमलावर के लिए उस पासवर्ड को सूँघना बहुत मुश्किल नहीं होगा क्योंकि यह नेटवर्क पर यात्रा करता है। अच्छा काम डेटाबेस में पासवर्ड हैशिंग है, हालांकि, एक संभावित हमलावर को हर किसी के पासवर्ड को देखने से रोकेगा (जो वे ईमेल पते के साथ उपयोग कर सकते हैं जो अन्य साइटों पर उपयोगकर्ता को लॉग इन करने का प्रयास कर सकते हैं।)

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


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

मैं यह भी जोड़ना चाहता हूं कि मैं अपने आवेदन में खराब सुरक्षा मॉडल के लिए जरूरी "बहाने" के रूप में फेसबुक में सुरक्षा खामियों की ओर इशारा नहीं कर रहा हूं। सिर्फ इसलिए कि जोई की माँ उसे देखने के मूल्यांकन आर फिल्मों यह सही :) नहीं है की सुविधा देता है
maple_shaft

1

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

यही है, जब तक कि कोई भी सफलतापूर्वक मुकदमेबाजी नहीं करता है और नियम बदलता है। यह भी देखें: "चेतावनी: सामग्री गर्म हो सकती है"।


0

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

मुझे लगता है कि आप हर बार अपने लॉगिन फ़ॉर्म में फ़ील्ड नामों को यादृच्छिक कर सकते हैं। इसके बजाय <input name="username", कुछ का उपयोग करें <input name="user658667587"। यह कैश्ड यूजरनेम को काफी बेकार बना देगा। लेकिन मुझे नहीं पता कि क्या ओवरहेड इसके लायक होगा। नहीं उल्लेख करने के लिए असुविधाजनक उपयोगकर्ताओं को, जो नहीं हैं सार्वजनिक मशीनों पर।

यदि आप एक अत्यंत सुरक्षा संवेदनशील स्थिति (बैंकिंग, निवेश) में हैं, तो आप लॉगऑन के दौरान लोगों से पूछ सकते हैं कि क्या यह एक सार्वजनिक मशीन है। जब आप लोग लॉग इन करते हैं, तो आप ज्ञात आईपी पते को भी कैश कर सकते हैं और यदि वे किसी अन्य स्थान से लॉग इन करते हैं, तो सामान्य उपयोगकर्ता / पास के अलावा एक गैर टाइप करने योग्य पिन नंबर (उदा, छवियों पर क्लिक करें) की आवश्यकता होती है। मेरा बैंक कुछ ऐसा करता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.