सवाल फॉर्म-आधारित वेबसाइट प्रमाणीकरण के लिए निश्चित मार्गदर्शिका [बंद]


वेबसाइटों के लिए फॉर्म-आधारित प्रमाणीकरण

हमारा मानना ​​है कि स्टैक ओवरफ़्लो केवल विशिष्ट तकनीकी प्रश्नों के लिए संसाधन नहीं होना चाहिए, बल्कि सामान्य समस्याओं पर भिन्नताओं को हल करने के तरीके पर सामान्य दिशानिर्देशों के लिए भी होना चाहिए। "वेबसाइटों के लिए फॉर्म आधारित प्रमाणीकरण" इस तरह के प्रयोग के लिए एक अच्छा विषय होना चाहिए।

इसमें विषयों को शामिल करना चाहिए जैसे कि:

  • लॉग इन कैसे करें
  • लॉग आउट कैसे करें
  • लॉग इन कैसे रहें
  • कुकीज़ प्रबंधित करना (अनुशंसित सेटिंग्स सहित)
  • एसएसएल / एचटीटीपीएस एन्क्रिप्शन
  • पासवर्ड कैसे स्टोर करें
  • गुप्त प्रश्नों का प्रयोग करना
  • भूल गए उपयोगकर्ता नाम / पासवर्ड कार्यक्षमता
  • का उपयोग nonces रोकने के लिए क्रॉस साइट अनुरोध फर्जीज (सीएसआरएफ)
  • OpenID
  • "मुझे याद रखें" चेकबॉक्स
  • उपयोगकर्ता नाम और पासवर्ड का ब्राउज़र स्वत: पूर्णता
  • गुप्त यूआरएल (सार्वजनिक यूआरएल पचाने से संरक्षित)
  • पासवर्ड की ताकत की जांच
  • ई-मेल सत्यापन
  • और इसके बारे में और अधिक  फॉर्म आधारित प्रमाणीकरण...

इसमें चीजों को शामिल नहीं करना चाहिए:

  • भूमिकाएं और प्राधिकरण
  • HTTP मूल प्रमाणीकरण

कृपया हमारी सहायता करें:

  1. उपtopics का सुझाव
  2. इस विषय के बारे में अच्छे लेख जमा करना
  3. आधिकारिक उत्तर संपादन

5002


मूल


HTTP मूल प्रमाणीकरण क्यों बहिष्कृत करें? यह अजाक्स के माध्यम से एचटीएमएल फॉर्म में काम कर सकता है: peej.co.uk/articles/http-auth-with-html-forms.html - system PAUSE
HTTP बेसिक एथ में ब्राउज़र को भूलने के लिए (तुलनात्मक रूप से) होने की संपत्ति है। यदि आप कनेक्शन सुरक्षित करने के लिए एसएसएल के साथ इसका उपयोग नहीं करते हैं तो यह भी बेहद असुरक्षित है (यानी, HTTPS)। - Donal Fellows
मुझे लगता है कि सत्रों (फिक्सेशन और अपहरण सहित) कुकीज़ (सुरक्षित और http केवल झंडे) HTTP आधारित एसएसओ के बारे में बात करना उचित होगा - symcbean
सुपर-उपयोगी HttpOnly कुकी ध्वज, जो जावास्क्रिप्ट-आधारित कुकी चोरी (एक्सएसएस हमलों का एक सबसेट) को रोकता है, कहीं भी उल्लेख किया जाना चाहिए। - Alan H.
वाह। लंबे उत्तरों, उनमें से कुछ के लिए अपरिवर्तनीय दर्जनों, फिर भी कोई भी HTTP पर लॉगिन फॉर्म की सेवा करने की सामान्य गलती का उल्लेख नहीं करता है। मैंने उन लोगों के साथ भी तर्क दिया है जिन्होंने कहा था "लेकिन यह https: // ... पर सबमिट हो जाता है" और केवल रिक्त स्ट्रेर्स प्राप्त हुए जब मैंने पूछा कि क्या उन्हें यकीन है कि एक हमलावर ने गैर-एन्क्रिप्टेड पेज को फिर से लिखना नहीं था जिस पर फ़ॉर्म परोसा गया था । - dzuelke


जवाब:


भाग I: लॉग इन कैसे करें

हम मान लेंगे कि आप पहले ही जानते हैं कि लॉगिन + पासवर्ड HTML फॉर्म कैसे बनाया जाए जो प्रमाणीकरण के लिए सर्वर पक्ष पर एक स्क्रिप्ट को मान पोस्ट करता है। नीचे दिए गए अनुभाग ध्वनि व्यावहारिक लेख के लिए पैटर्न और सबसे आम सुरक्षा नुकसान से बचने के तरीकों से निपटेंगे।

HTTPS या HTTPS के लिए नहीं?

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

संक्षेप में, केवल व्यावहारिक लॉगिन के दौरान वायरटैपिंग / पैकेट स्नीफिंग के खिलाफ सुरक्षा करने का तरीका HTTPS या किसी अन्य प्रमाणपत्र-आधारित एन्क्रिप्शन योजना का उपयोग करना है (उदाहरण के लिए, टीएलएस) या एक सिद्ध और परीक्षण चुनौती-प्रतिक्रिया योजना (उदाहरण के लिए, Diffie-Hellmanआधारित एसआरपी)। किसी भी अन्य विधि को आसानी से घुमाया जा सकता है एक छिपे हुए हमलावर द्वारा।

बेशक, यदि आप थोड़ा अव्यवहारिक होने के इच्छुक हैं, तो आप दो-कारक प्रमाणीकरण योजना (जैसे Google प्रमाणक ऐप, एक भौतिक 'शीत युद्ध शैली' कोडबुक, या एक आरएसए कुंजी जनरेटर डोंगल) का कुछ रूप भी नियोजित कर सकते हैं। यदि सही तरीके से लागू किया गया है, तो यह असुरक्षित कनेक्शन के साथ भी काम कर सकता है, लेकिन यह कल्पना करना मुश्किल है कि एक देव दो कारक लेख को लागू करने के इच्छुक होगा लेकिन एसएसएल नहीं।

(मत करो) अपनी खुद की जावास्क्रिप्ट एन्क्रिप्शन / हैशिंग रोल करें

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

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

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

मानवता के खिलाफ कैप्चास

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

जानें कि कैप्चा कार्यान्वयन समान रूप से नहीं बनाए जाते हैं; वे अक्सर मानव-सुलभ नहीं होते हैं, उनमें से अधिकतर वास्तव में बॉट्स के खिलाफ अप्रभावी होते हैं, वे सभी सस्ते तीसरे विश्व श्रम के खिलाफ अप्रभावी हैं (के अनुसार OWASP, वर्तमान sweatshop दर $ 500 प्रति 500 ​​परीक्षण है), और कुछ कार्यान्वयन कुछ देशों में तकनीकी रूप से अवैध हो सकता है (देखें OWASP प्रमाणीकरण धोखा शीट)। यदि आपको कैप्चा का उपयोग करना होगा, तो Google का उपयोग करें reCAPTCHAचूंकि यह परिभाषा के अनुसार ओसीआर-हार्ड है (चूंकि यह पहले से ही ओसीआर-गलत वर्गीकृत पुस्तक स्कैन का उपयोग करता है) और उपयोगकर्ता के अनुकूल होने के लिए बहुत मेहनत करता है।

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

पासवर्ड संग्रहीत / लॉग इन सत्यापित करना

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

इसलिए यदि आप पासवर्ड स्टोर नहीं कर सकते हैं, तो आप कैसे जांचते हैं कि लॉगिन फॉर्म से पोस्ट किया गया लॉगिन + पासवर्ड संयोजन सही है? जवाब ए का उपयोग कर हैशिंग है कुंजी व्युत्पन्न समारोह। जब भी कोई नया उपयोगकर्ता बनाया जाता है या पासवर्ड बदल जाता है, तो आप पासवर्ड लेते हैं और इसे KDF के माध्यम से चलाते हैं, जैसे कि Argon2, bcrypt, scrypt या PBKDF2, क्लीयरएक्स्ट पासवर्ड ("correcthorsebatterystaple") को एक लंबे, यादृच्छिक दिखने वाली स्ट्रिंग में बदलना , जो आपके डेटाबेस में स्टोर करने के लिए बहुत सुरक्षित है। लॉगिन सत्यापित करने के लिए, आप दर्ज पासवर्ड पर एक ही हैश फ़ंक्शन चलाते हैं, इस बार नमक में गुजरते हैं और परिणामी हैश स्ट्रिंग की तुलना अपने डेटाबेस में संग्रहीत मान से करते हैं। Argon2, bcrypt और scrypt पहले से ही हैश के साथ नमक स्टोर। इसकी जांच करो लेख अधिक विस्तृत जानकारी के लिए sec.stackexchange पर।

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

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

सत्र डेटा - "आप स्पाइडरमैन 6 9 के रूप में लॉग इन हैं"

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

यदि आप सत्र डेटा से अपरिचित हैं, तो यहां यह काम करता है: एक एकल यादृच्छिक रूप से जेनरेट की गई स्ट्रिंग एक समाप्ति कुकी में संग्रहीत होती है और डेटा के संग्रह को संदर्भित करने के लिए उपयोग की जाती है - सत्र डेटा - जो सर्वर पर संग्रहीत होता है। यदि आप एक एमवीसी ढांचे का उपयोग कर रहे हैं, तो निस्संदेह यह पहले से ही संभाला जा रहा है।

यदि संभव हो, तो सुनिश्चित करें कि सत्र कुकी में सुरक्षित और HTTP केवल ब्राउज़र पर भेजे जाने पर फ़्लैग सेट हो। HttpONly ध्वज XSS हमले द्वारा पढ़ी जाने वाली कुकी के खिलाफ कुछ सुरक्षा प्रदान करता है। सुरक्षित ध्वज यह सुनिश्चित करता है कि कुकी केवल HTTPS के माध्यम से वापस भेजी जाए, और इसलिए नेटवर्क स्नीफिंग हमलों के खिलाफ सुरक्षा करता है। कुकी का मूल्य अनुमानित नहीं होना चाहिए। जहां एक गैर-मौजूदा सत्र का संदर्भ देने वाली कुकी प्रस्तुत की जाती है, तो इसके मूल्य को तुरंत रोकने के लिए प्रतिस्थापित किया जाना चाहिए सत्र निर्धारण

भाग II: लॉग इन कैसे रहें - कुख्यात "मुझे याद रखें" चेकबॉक्स

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

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

बेशक, कुछ सिस्टम बर्दाश्त नहीं कर सकते हैं कोई खातों हैक किया; ऐसी प्रणालियों के लिए, कोई भी तरीका नहीं है जिससे आप निरंतर लॉगिन कर सकें।

यदि आप निरंतर लॉगिन कुकीज़ को लागू करने का निर्णय लेते हैं, तो आप इसे कैसे करते हैं:

  1. सबसे पहले, पढ़ने के लिए कुछ समय ले लो पैरागोन पहल का लेख इस विषय पर। आपको तत्वों का एक गुच्छा सही करने की आवश्यकता होगी, और आलेख प्रत्येक को समझाए जाने का एक अच्छा काम करता है।

  2. और बस सबसे आम नुकसान में से एक को दोहराने के लिए, अपने डाटाबेस में व्यक्तिगत लॉगिन कुकी (टोकन) को न रखें, केवल इसकी एक ख़बर! लॉगिन टोकन पासवर्ड समतुल्य है, इसलिए यदि किसी हमलावर को आपके डेटाबेस पर हाथ मिला, तो वे टोकन का उपयोग किसी भी खाते में लॉग इन करने के लिए कर सकते थे, जैसे कि वे क्लीयरएक्स्ट लॉगिन-पासवर्ड संयोजन थे। इसलिए, हैशिंग का उपयोग करें (के अनुसार https://security.stackexchange.com/a/63438/5002 एक कमजोर हैश इस उद्देश्य के लिए ठीक काम करेगा) जब लगातार लॉगिन टोकन संग्रहित करते हैं।

भाग III: गुप्त प्रश्नों का उपयोग करना

'गुप्त प्रश्न' लागू न करें। 'गुप्त प्रश्न' सुविधा एक सुरक्षा विरोधी पैटर्न है। मस्ट-रीड सूची से लिंक नंबर 4 से पेपर पढ़ें। आप उसके बारे में सारा पॉलिन से पूछ सकते हैं, उसके याहू के बाद! पिछले राष्ट्रपति अभियान के दौरान ईमेल अकाउंट हैक किया गया क्योंकि उसके सुरक्षा प्रश्न का जवाब था ... "वासीला हाई स्कूल"!

यहां तक ​​कि उपयोगकर्ता द्वारा निर्दिष्ट प्रश्नों के साथ, यह अत्यधिक संभावना है कि अधिकतर उपयोगकर्ता या तो चुनेंगे:

  • मां का पहला नाम या पसंदीदा पालतू जैसे एक 'मानक' गुप्त प्रश्न

  • ट्रिविया का एक साधारण टुकड़ा कि कोई भी अपने ब्लॉग, लिंक्डइन प्रोफाइल, या इसी तरह से उठा सकता है

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

अंत में, सुरक्षा प्रश्न मूल रूप से उनके सभी रूपों और विविधताओं में असुरक्षित रूप से असुरक्षित हैं, और किसी भी कारण से प्रमाणीकरण योजना में नियोजित नहीं किए जाने चाहिए।

जंगली में सुरक्षा प्रश्न भी मौजूद होने का सही कारण यह है कि वे आसानी से उन उपयोगकर्ताओं से कुछ समर्थन कॉल की लागत को बचाते हैं जो पुनः सक्रियण कोड प्राप्त करने के लिए अपने ईमेल तक नहीं पहुंच सकते हैं। यह सुरक्षा और सारा पॉलिन की प्रतिष्ठा की कीमत पर है। इसके लायक? शायद ऩही।

भाग IV: भूल गए पासवर्ड कार्यक्षमता

मैंने पहले ही उल्लेख किया है कि आपको क्यों चाहिए सुरक्षा प्रश्नों का कभी भी उपयोग न करेंभूल गए / खोए गए उपयोगकर्ता पासवर्ड को संभालने के लिए; यह बिना कहने के भी चला जाता है कि आपको कभी भी अपने वास्तविक पासवर्ड उपयोगकर्ताओं को ई-मेल नहीं करना चाहिए। इस क्षेत्र में बचने के लिए कम-से-कम दो और आम-सामान्य समस्याएं हैं:

  1. नहीं रीसेट एक स्वत: जेनरेटेड मजबूत पासवर्ड के लिए एक भूल गया पासवर्ड - ऐसे पासवर्ड याद रखने के लिए कुख्यात रूप से कठिन हैं, जिसका अर्थ है कि उपयोगकर्ता को या तो इसे बदलना चाहिए या इसे लिखना चाहिए - कहें, उनके मॉनिटर के किनारे पर एक उज्ज्वल पीले पोस्ट-इट पर। नया पासवर्ड सेट करने के बजाय, बस उपयोगकर्ताओं को तुरंत एक नया चुनने दें - वही है जो वे वैसे भी करना चाहते हैं। (इसका अपवाद हो सकता है यदि उपयोगकर्ता सार्वभौमिक रूप से पासवर्ड प्रबंधक को प्रबंधित / प्रबंधित करने के लिए पासवर्ड प्रबंधक का उपयोग कर रहे हैं जो सामान्य रूप से इसे लिखने के बिना याद रखना असंभव होगा)।

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

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

भाग वी: पासवर्ड शक्ति की जांच

सबसे पहले, आप वास्तविकता जांच के लिए इस छोटे लेख को पढ़ना चाहेंगे: 500 सबसे आम पासवर्ड

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

इसलिए: न्यूनतम पासवर्ड शक्ति आवश्यकताओं के साथ, 2% उपयोगकर्ता शीर्ष 20 सबसे आम पासवर्ड में से एक का उपयोग करते हैं। मतलब: यदि किसी हमलावर को केवल 20 प्रयास मिलते हैं, तो आपकी वेबसाइट पर 50 में से 1 खाते क्रैक करने योग्य होंगे।

इसे विफल करने के लिए पासवर्ड की एन्ट्रॉपी की गणना करना और फिर थ्रेसहोल्ड लागू करना आवश्यक है। नेशनल इंस्टीट्यूट ऑफ स्टैंडर्ड एंड टेक्नोलॉजी (एनआईएसटी) विशेष प्रकाशन 800-63 बहुत अच्छे सुझावों का एक सेट है। वह, जब एक शब्दकोश और कीबोर्ड लेआउट विश्लेषण के साथ संयुक्त (उदाहरण के लिए, 'qwertyuiop' एक बुरा पासवर्ड है), कर सकते हैं सभी खराब चुने गए पासवर्डों का 99% अस्वीकार करें एन्ट्रॉपी के 18 बिट्स के स्तर पर। बस पासवर्ड की ताकत की गणना और एक दृश्य शक्ति मीटर दिखा रहा है एक उपयोगकर्ता के लिए अच्छा है, लेकिन अपर्याप्त है। जब तक इसे लागू नहीं किया जाता है, तब तक बहुत से उपयोगकर्ता इसे अनदेखा कर सकते हैं।

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

भाग VI: बहुत अधिक - या: रैपिड-फायर लॉगिन प्रयासों को रोकना

सबसे पहले, संख्याओं पर एक नज़र डालें: पासवर्ड रिकवरी स्पीड - आपका पासवर्ड कब तक खड़ा होगा

यदि आपके पास उस लिंक में टेबल को देखने का समय नहीं है, तो यहां उनकी सूची दी गई है:

  1. यह वस्तुतः कोई समय नहीं एक कमजोर पासवर्ड को तोड़ने के लिए, भले ही आप इसे अबाकस के साथ क्रैक कर रहे हों

  2. यह वस्तुतः कोई समय नहीं एक अल्फान्यूमेरिक 9-वर्ण पासवर्ड को क्रैक करने के लिए, यदि यह है असंवेदनशील मामला

  3. यह वस्तुतः कोई समय नहीं एक जटिल, प्रतीकों और अक्षरों और संख्याओं को ऊपरी-और-लोअरकेस पासवर्ड को तोड़ने के लिए, यदि यह है 8 अक्षर से कम लंबा (एक डेस्कटॉप पीसी पूरे कुंजीपटल को दिन या यहां तक ​​कि घंटों के मामले में 7 अक्षरों तक खोज सकता है)

  4. हालांकि, यह 6-वर्ण पासवर्ड को तोड़ने के लिए एक अनोखा समय लेगा, यदि आप प्रति सेकंड एक प्रयास तक ही सीमित थे!

तो हम इन नंबरों से क्या सीख सकते हैं? खैर, बहुत, लेकिन हम सबसे महत्वपूर्ण भाग पर ध्यान केंद्रित कर सकते हैं: तथ्य यह है कि बड़ी संख्या में तेजी से आग लगने वाले लॉगिन प्रयासों को रोकना (यानी। पाशविक बल हमला) वास्तव में मुश्किल नहीं है। लेकिन इसे रोक रहा है सही ऐसा लगता है जितना आसान नहीं है।

आम तौर पर, आपके पास तीन विकल्प हैं जो क्रूर बल के हमलों के खिलाफ प्रभावी हैं (और शब्दकोश हमले, लेकिन चूंकि आप पहले से ही एक मजबूत पासवर्ड नीति नियोजित कर रहे हैं, इसलिए उन्हें कोई मुद्दा नहीं होना चाहिए):

  • एक प्रस्तुत करें कॅप्चा एन विफल प्रयासों के बाद (नरक के रूप में परेशान और अक्सर अप्रभावी - लेकिन मैं खुद को दोहरा रहा हूं)

  • खातों को लॉक करना और एन विफल प्रयासों के बाद ईमेल सत्यापन की आवश्यकता है (यह एक है DoS हमले होने का इंतजार

  • और अंत में, लॉगिन थ्रॉटलिंग: यानी, एन विफल प्रयासों के प्रयासों के बीच समय विलंब स्थापित करना (हां, डीओएस हमले अभी भी संभव हैं, लेकिन कम से कम वे बहुत कम संभावनाएं हैं और खींचने के लिए बहुत अधिक जटिल हैं)।

सर्वश्रेष्ठ अभ्यास # 1: असफल प्रयासों की संख्या के साथ बढ़ने में थोड़ी देर की देरी, जैसे:

  • 1 विफल प्रयास = कोई देरी नहीं
  • 2 विफल प्रयास = 2 सेकंड देरी
  • 3 विफल प्रयास = 4 सेकंड देरी
  • 4 विफल प्रयास = 8 सेकंड देरी
  • 5 विफल प्रयास = 16 सेकंड देरी
  • आदि।

इस योजना पर हमला करने वाले डीओएस बहुत अव्यवहारिक होंगे, क्योंकि परिणामी लॉकआउट समय पिछले लॉकआउट समय के योग से थोड़ा बड़ा है।

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

सर्वश्रेष्ठ अभ्यास # 2: एक मध्यम लंबाई की देरी जो एन विफल प्रयासों के बाद प्रभावी हो जाती है, जैसे:

  • 1-4 विफल प्रयास = कोई देरी नहीं
  • 5 विफल प्रयास = 15-30 मिनट देरी

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

सर्वश्रेष्ठ अभ्यास # 3: दो दृष्टिकोणों का संयोजन - या तो एक निश्चित, छोटी अवधि की देरी जो एन विफल प्रयासों के बाद प्रभावी हो जाती है, जैसे:

  • 1-4 विफल प्रयास = कोई देरी नहीं
  • 5+ विफल प्रयास = 20 सेकंड देरी

या, एक निश्चित ऊपरी सीमा के साथ बढ़ती देरी, जैसे:

  • 1 विफल प्रयास = 5 सेकंड देरी
  • 2 विफल प्रयास = 15 सेकंड देरी
  • 3+ विफल प्रयास = 45 सेकंड देरी

यह अंतिम योजना ओडब्ल्यूएएसपी सर्वोत्तम प्रथाओं के सुझावों (मस्ट-रीड सूची से लिंक 1) से ली गई थी, और इसे सर्वोत्तम अभ्यास माना जाना चाहिए, भले ही यह स्वीकार्य रूप से प्रतिबंधित पक्ष पर हो।

अंगूठे के नियम के रूप में, मैं कहूंगा: आपकी पासवर्ड नीति जितनी मजबूत होगी, उतनी ही कम आपको उपयोगकर्ताओं को देरी के साथ बग करना होगा। यदि आपको मजबूत (केस-संवेदनशील अल्फान्यूमेरिक्स + आवश्यक संख्याएं और प्रतीकों) 9 + वर्ण पासवर्ड की आवश्यकता होती है, तो आप थ्रॉटलिंग को सक्रिय करने से पहले उपयोगकर्ताओं को 2-4 गैर-देरी वाले पासवर्ड प्रयास दे सकते हैं।

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

इसके अतिरिक्त, यह व्यवस्थापक खातों पर अधिक आक्रामक थ्रॉटलिंग करने के लिए समझ में आता है, क्योंकि वे सबसे आकर्षक प्रवेश बिंदु हैं

भाग VII: वितरित ब्रूट फोर्स अटैक

एक तरफ के रूप में, अधिक उन्नत हमलावर 'अपनी गतिविधियों को फैलाने' द्वारा लॉगिन थ्रॉटलिंग को रोकने की कोशिश करेंगे:

  • आईपी ​​एड्रेस फ्लैगिंग को रोकने के लिए एक बॉटनेट पर प्रयासों को वितरित करना

  • एक उपयोगकर्ता को चुनने और 50,000 सबसे आम पासवर्ड (जो वे नहीं कर सकते हैं, हमारे थ्रॉटलिंग के कारण) की कोशिश करने के बजाय, वे सबसे आम पासवर्ड चुनेंगे और इसके बजाय 50,000 उपयोगकर्ताओं के खिलाफ कोशिश करेंगे। इस तरह, न केवल उन्हें कैप्चा और लॉगिन थ्रॉटलिंग जैसे अधिकतम प्रयासों के उपाय मिलते हैं, सफलता की संभावना भी बढ़ जाती है, क्योंकि नंबर 1 सबसे आम पासवर्ड संख्या 49.9 5 9 से कहीं अधिक है

  • रडार के नीचे छींकने के लिए, 30 सेकंड अलग, प्रत्येक उपयोगकर्ता खाते के लिए लॉगिन अनुरोधों को स्थानांतरित करें

यहां, सबसे अच्छा अभ्यास होगा असफल लॉगिन, सिस्टम-व्यापी की संख्या लॉगिंग, और अपनी साइट की खराब-लॉगिन आवृत्ति के चल रहे औसत का उपयोग ऊपरी सीमा के आधार के रूप में करते हैं जिसे आप तब सभी उपयोगकर्ताओं पर लगाते हैं।

बहुत सार? मुझे दोबारा दोहराएं:

कहें कि पिछले 3 महीनों में आपकी साइट पर प्रतिदिन औसतन 120 खराब लॉग इन हैं। उस (औसत चलने वाले) का उपयोग करके, आपका सिस्टम वैश्विक सीमा को 3 गुना निर्धारित कर सकता है - यानी। 360 24 घंटे की अवधि में विफल प्रयासों। फिर, यदि सभी खातों में असफल प्रयासों की कुल संख्या एक दिन के भीतर उस संख्या से अधिक हो जाती है (या इससे भी बेहतर, त्वरण की दर की निगरानी करें और गणना की गई थ्रेसहोल्ड पर ट्रिगर करें), यह सिस्टम-व्यापी लॉगिन थ्रॉटलिंग को सक्रिय करता है - जिसका मतलब है कि सभी उपयोगकर्ताओं के लिए छोटी देरी (अभी भी, कुकी लॉग इन और / या बैकअप कैप्चा लॉग इन के अपवाद के साथ)।

मैंने साथ एक प्रश्न भी पोस्ट किया अधिक जानकारी और मुश्किल pitfals से बचने के लिए वास्तव में अच्छी चर्चा वितरित ब्रूट फोर्स हमलों को बंद करने में

भाग VIII: दो-फैक्टर प्रमाणीकरण और प्रमाणीकरण प्रदाता

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

प्रमाणीकरण को एकल-साइन-ऑन सेवा पर पूरी तरह से प्रतिनिधि किया जा सकता है, जहां कोई अन्य प्रदाता प्रमाण-पत्र एकत्रित करता है। यह समस्या को एक विश्वसनीय तृतीय पक्ष को धक्का देता है। Google और ट्विटर दोनों मानक-आधारित एसएसओ सेवाएं प्रदान करते हैं, जबकि फेसबुक एक समान मालिकाना समाधान प्रदान करता है।

वेब प्रमाणीकरण के बारे में लिंक पढ़ें

  1. प्रमाणीकरण के लिए OWASP गाइड / OWASP प्रमाणीकरण धोखा शीट
  2. वेब पर क्लाइंट प्रमाणीकरण के डॉस और डॉन (बहुत पठनीय एमआईटी शोध पत्र)
  3. विकिपीडिया: HTTP कुकी
  4. फ़ॉलबैक प्रमाणीकरण के लिए व्यक्तिगत ज्ञान प्रश्न: फेसबुक के युग में सुरक्षा प्रश्न (बहुत पठनीय बर्कले शोध पत्र)

3498



खैर, मैं वास्तव में कैप्चा भाग से सहमत नहीं हूं, हां कैप्चा परेशान हैं और उन्हें तोड़ा जा सकता है (रिकैप्चा को छोड़कर, लेकिन यह मनुष्यों द्वारा मुश्किल से हल करने योग्य है!) लेकिन यह बिल्कुल कहने जैसा है क