security - वेबसाइट-आधारित प्रमाणीकरण के लिए निश्चित गाइड




http authentication (8)

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

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

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

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

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

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

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

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

निश्चित लेख

साख भेजना

SSL का उपयोग करके क्रेडेंशियल्स को 100% सुरक्षित रूप से भेजने का एकमात्र व्यावहारिक तरीका है। पासवर्ड का उपयोग करने के लिए जावास्क्रिप्ट का उपयोग करना सुरक्षित नहीं है। क्लाइंट-साइड पासवर्ड हैशिंग के लिए सामान्य नुकसान:

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

एसआरपी नामक एक और सुरक्षित तरीका है, लेकिन यह पेटेंट है (हालांकि यह स्वतंत्र रूप से लाइसेंस प्राप्त है ) और कुछ अच्छे कार्यान्वयन उपलब्ध हैं।

पासवर्ड संग्रहीत करना

डेटाबेस में प्लेनटेक्स्ट के रूप में कभी भी पासवर्ड स्टोर न करें। यहां तक ​​कि अगर आप अपनी खुद की साइट की सुरक्षा की परवाह नहीं करते हैं। मान लें कि आपके कुछ उपयोगकर्ता अपने ऑनलाइन बैंक खाते के पासवर्ड का पुन: उपयोग करेंगे। इसलिए, हैशेड पासवर्ड स्टोर करें, और मूल को फेंक दें। और सुनिश्चित करें कि पासवर्ड एक्सेस लॉग या एप्लिकेशन लॉग में दिखाई नहीं देता है। OWASP नए अनुप्रयोगों के लिए आपकी पहली पसंद के रूप में आर्गन 2 के उपयोग की सिफारिश करता है । यदि यह उपलब्ध नहीं है, तो इसके बजाय PBKDF2 या स्क्रीप्ट का उपयोग किया जाना चाहिए। और अंत में यदि उपरोक्त में से कोई भी उपलब्ध नहीं है, तो bcrypt का उपयोग करें।

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

इसका मतलब है कि आप उपयोगकर्ता को उनके भूल गए पासवर्ड नहीं भेज सकते हैं (क्योंकि आपके पास केवल हैश है)। उपयोगकर्ता के पासवर्ड को तब तक रीसेट न करें जब तक कि आपने उपयोगकर्ता को प्रमाणित नहीं किया है (उपयोगकर्ताओं को यह साबित करना होगा कि वे संग्रहीत (और मान्य) ईमेल पते पर भेजे गए ईमेल पढ़ने में सक्षम हैं।)

सुरक्षा प्रश्न

सुरक्षा प्रश्न असुरक्षित हैं - उनका उपयोग करने से बचें। क्यूं कर? सुरक्षा प्रश्न कुछ भी करता है, एक पासवर्ड बेहतर करता है। भाग III पढ़ें : इस विकी में @Jens Roland में गुप्त प्रश्नों का उपयोग करना

सत्र कुकीज़

उपयोगकर्ता के लॉग इन करने के बाद, सर्वर उपयोगकर्ता को एक सत्र कुकी भेजता है। सर्वर कुकी से उपयोगकर्ता नाम या आईडी को पुनः प्राप्त कर सकता है, लेकिन कोई और इस तरह के कुकी (TODO व्याख्या तंत्र) को उत्पन्न नहीं कर सकता है।

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

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

दूसरी ओर वित्तीय वेबसाइटें, जैसे बैंक और क्रेडिट कार्ड, में केवल संवेदनशील डेटा होता है और इसे ऑटो-लॉगिन या कम-सुरक्षा मोड की अनुमति नहीं देनी चाहिए।

बाहरी संसाधनों की सूची


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

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

HTTPS को या HTTPS को नहीं?

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

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

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

(न करें) रोल-अपना-अपना जावास्क्रिप्ट एन्क्रिप्शन / हैशिंग

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PART V: पासवर्ड स्ट्रेंथ की जाँच

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

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

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

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

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

सार्वजनिक डेटा उल्लंघनों में समझौता किए गए पासवर्ड के खिलाफ उपयोगकर्ताओं के पासवर्ड की जांच करने के लिए ट्रॉय हंट आई हैव आई पीनड एपीआई का उपयोग करें।

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

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

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

  1. एक कमजोर पासवर्ड को क्रैक करने में लगभग समय नहीं लगता है, भले ही आप इसे एबेकस से क्रैक कर रहे हों

  2. यदि यह असंवेदनशील है, तो अल्फ़ान्यूमेरिक 9-कैरेक्टर पासवर्ड को क्रैक करने में लगभग समय नहीं लगता है

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

  4. हालाँकि, यदि आप प्रति सेकंड एक प्रयास तक सीमित थे , तो भी 6-वर्ण पासवर्ड को क्रैक करने के लिए समय की एक विषम राशि ले सकते हैं !

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

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

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

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

  • और अंत में, थ्रॉटलिंग लॉगिन करें : अर्थात, एन विफल प्रयासों के बाद प्रयासों के बीच एक समय की देरी सेट करना (हाँ, 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 सेकंड की देरी

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

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

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

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

भाग VII: वितरित सेना बल हमलों

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

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

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

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

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

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

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

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

भाग आठ: दो-कारक प्रमाणीकरण और प्रमाणीकरण प्रदाता

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

प्रमाणीकरण को पूरी तरह से एकल-साइन-ऑन सेवा में सौंपा जा सकता है, जहां एक और प्रदाता क्रेडेंशियल इकट्ठा करना संभालता है। यह समस्या को एक विश्वसनीय तृतीय पक्ष तक पहुंचाता है। Google और Twitter दोनों मानक-आधारित SSO सेवाएँ प्रदान करते हैं, जबकि Facebook एक समान स्वामित्व समाधान प्रदान करता है।

MUST-READ कड़ियाँ वेब प्रमाणीकरण के बारे में

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

मुझे नहीं लगता कि उपरोक्त उत्तर "गलत" है, लेकिन प्रमाणीकरण के बड़े क्षेत्र हैं, जिन्हें स्पर्श नहीं किया गया है (या इसके बजाय "कुकी सत्रों को कैसे लागू किया जाए" पर जोर दिया गया है, न कि "क्या विकल्प उपलब्ध हैं और क्या व्यापार हैं" -offs "।

मेरे सुझाए गए संपादन / उत्तर हैं

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

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

यह किसी भी "सत्र" या कुकीज़ की आवश्यकता को टालता है क्योंकि ब्राउज़र खुद ही हर बार संचार को फिर से एन्क्रिप्ट करेगा। यह सबसे "हल्का" विकास दृष्टिकोण है।

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

इसलिए ...

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

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

लेकिन यह एक बहुत परेशानी है, और बहुत वेब 2.0 नहीं है। हालाँकि, यह नए खातों को बनाने का एकमात्र सुरक्षित तरीका है जिसकी मूल्यवान जानकारी तक पहुँच है जो स्वयं निर्मित नहीं है।

  1. कर्बेरोस और SPNEGO - एक विश्वसनीय तृतीय पक्ष के साथ एकल साइन-ऑन तंत्र - मूल रूप से उपयोगकर्ता एक विश्वसनीय तृतीय पक्ष के विरुद्ध पुष्टि करता है। (एनबी यह किसी भी तरह से OAuth भरोसा नहीं किया जा सकता है )

  2. SRP - एक विश्वसनीय तीसरे पक्ष के बिना चतुर पासवर्ड प्रमाणीकरण की तरह। लेकिन यहां हम "दो-कारक प्रमाणीकरण का उपयोग करना सुरक्षित है, भले ही यह महंगा हो" के दायरे में आ रहे हैं

  3. SSL क्लाइंट साइड - क्लाइंट को एक सार्वजनिक कुंजी प्रमाणपत्र (सभी प्रमुख ब्राउज़रों में समर्थन - लेकिन ग्राहक मशीन सुरक्षा पर सवाल उठाता है) दें।

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


मुझे लगा कि मैं इस समाधान को साझा करूंगा जो मुझे ठीक काम करने के लिए मिला।

मैं इसे डमी फील्ड कहता हूं (हालांकि मैंने इसका आविष्कार नहीं किया है इसलिए मुझे इसका श्रेय न दें)।

संक्षेप में: आपको बस <form>इसे अपने अंदर डालना होगा और सत्यापन के समय इसे खाली होने के लिए जांचना होगा:

<input type="text" name="email" style="display:none" />

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

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

उदाहरण:

मानव के मामले में: उपयोगकर्ता डमी फ़ील्ड (मेरे ईमेल "नाम के मामले में) को नहीं देखेगा और उसे भरने का प्रयास नहीं करेगा। तो डमी फ़ील्ड का मूल्य तब भी खाली होना चाहिए जब फॉर्म भेजा गया हो।

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

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

मेरा मानना ​​है कि यह भी एक लॉगिन / प्रमाणीकरण फार्म के साथ ठीक इस्तेमाल किया जा सकता है।

चेतावनी : बेशक यह विधि 100% मूर्ख नहीं है। बॉट्स display:noneको उस पर लागू शैली के साथ इनपुट फ़ील्ड को अनदेखा करने के लिए प्रोग्राम किया जा सकता है। आपको उन लोगों के बारे में भी सोचना होगा जो ऑटो-पूर्ण के कुछ फॉर्म का उपयोग करते हैं (जैसे अधिकांश ब्राउज़रों ने उनके लिए सभी फॉर्म फ़ील्ड को ऑटो-फिल करने के लिए बनाया है!)। वे बस एक डमी क्षेत्र उठा सकते हैं।

आप इसे डमी फ़ील्ड को दृश्यमान और स्क्रीन की सीमाओं के बाहर छोड़कर थोड़ा अलग कर सकते हैं, लेकिन यह पूरी तरह से आपके ऊपर है।

रचनात्मक बनो!





मुझे नहीं पता कि क्या जवाब देने के लिए या टिप्पणी के रूप में इसका जवाब देना सबसे अच्छा था। मैंने पहला विकल्प चुना।

पोइंग पार्ट IV के बारे में : पहले उत्तर में पासवर्ड की कार्यक्षमता भूल जाने पर , मैं टाइमिंग अटैक्स के बारे में बात करूंगा।

में याद रखें अपना पासवर्ड रूपों, एक हमलावर संभवतः ईमेल की एक पूरी सूची की जांच कर सकता है और पता लगाने प्रणाली के लिए पंजीकृत हैं जो (नीचे दिए गए लिंक देखें)।

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

https://crypto.stanford.edu/~dabo/papers/webtiming.pdf








article