सुरक्षित पासवर्ड रीसेट के बारे में वह सब कुछ जो आप जानना चाहते थे। भाग 1

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

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

पासवर्ड भंडारण: हैशिंग, एन्क्रिप्शन और (हांफते हुए!) सादा पाठ

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

1. सरल पाठ. एक पासवर्ड कॉलम है, जो सादे टेक्स्ट फॉर्म में संग्रहीत है।
2. कूट रूप दिया गया। आमतौर पर सममित एन्क्रिप्शन का उपयोग किया जाता है (एन्क्रिप्शन और डिक्रिप्शन दोनों के लिए एक कुंजी का उपयोग किया जाता है), और एन्क्रिप्टेड पासवर्ड भी एक ही कॉलम में संग्रहीत होते हैं।
3. हशेड। एकतरफ़ा प्रक्रिया (पासवर्ड को हैश किया जा सकता है, लेकिन डीहैश नहीं किया जा सकता); पासवर्ड, मैं आशा करना चाहूंगा, उसके बाद एक नमक, और प्रत्येक अपने स्वयं के कॉलम में है।

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

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

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

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

चेतावनी!

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

अपना पासवर्ड हमेशा रीसेट करें कभी नहीं उसे याद मत दिलाओ

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

मुझे एहसास है कि "रिमाइंडर" शब्द का प्रयोग (अक्सर) बोलचाल के अर्थ में किया जाता है, लेकिन हम वास्तव में क्या करने की कोशिश कर रहे हैं उपयोगकर्ता को फिर से ऑनलाइन होने में सुरक्षित रूप से मदद करें. चूँकि हमें सुरक्षा की आवश्यकता है, इसलिए दो कारण हैं कि अनुस्मारक (अर्थात उपयोगकर्ता को उनका पासवर्ड भेजना) उचित नहीं है:

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

आइए मैं समस्या को एक उदाहरण से प्रदर्शित करता हूँ usoutdoor.com: यहां एक विशिष्ट लॉगिन पृष्ठ है:

जाहिर है, पहली समस्या यह है कि लॉगिन पेज HTTPS पर लोड नहीं होता है, लेकिन साइट आपको एक पासवर्ड ("पासवर्ड भेजें") भेजने के लिए भी संकेत देती है। यह ऊपर उल्लिखित शब्द के बोलचाल में उपयोग का एक उदाहरण हो सकता है, तो आइए इसे एक कदम आगे बढ़ाएं और देखें कि क्या होता है:

दुर्भाग्यवश, यह ज्यादा बेहतर नहीं दिखता; और एक ईमेल पुष्टि करता है कि कोई समस्या है:

यह हमें usoutdoor.com के दो महत्वपूर्ण पहलू बताता है:

1. साइट में पासवर्ड नहीं है. अधिक से अधिक, वे एन्क्रिप्टेड हैं, लेकिन यह संभावना है कि वे सादे पाठ में संग्रहीत हैं; हमें इसके विपरीत कोई सबूत नहीं दिखता।
2. साइट एक असुरक्षित चैनल पर एक दीर्घकालिक पासवर्ड भेजती है (हम वापस जा सकते हैं और इसे बार-बार उपयोग कर सकते हैं)।

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

उपयोगकर्ता नाम सूचीबद्ध करना और गुमनामी पर इसका प्रभाव

इस समस्या को सबसे अच्छे ढंग से चित्रित किया गया है। संकट:

क्या आप देखते हैं? संदेश पर ध्यान दें "इस ईमेल पते पर कोई उपयोगकर्ता पंजीकृत नहीं है।" यदि ऐसी साइट पुष्टि करती है तो समस्या स्पष्ट रूप से उत्पन्न होती है उपलब्धता उपयोगकर्ता ऐसे ईमेल पते के साथ पंजीकृत है। बिंगो - आपने अभी-अभी अपने पति/बॉस/पड़ोसी के अश्लील आकर्षण का पता लगाया है!

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

इस तरह की प्रथाएं "उपयोगकर्ता नाम गणना" के खतरे को भी बढ़ाती हैं, जिससे कोई व्यक्ति किसी वेबसाइट पर उपयोगकर्ता नाम या ईमेल पते के पूरे संग्रह के अस्तित्व को केवल समूह प्रश्नों का संचालन करके और उनके जवाबों की जांच करके सत्यापित कर सकता है। क्या आपके पास सभी कर्मचारियों के ईमेल पतों की सूची और स्क्रिप्ट लिखने के लिए कुछ मिनट हैं? फिर आप देखेंगे कि समस्या क्या है!

विकल्प क्या है? वास्तव में, यह काफी सरल है और इसे आश्चर्यजनक ढंग से लागू किया गया है Entropay:

यहां एन्ट्रोपे अपने सिस्टम में ईमेल पते के अस्तित्व के बारे में कुछ भी नहीं बताता है किसी ऐसे व्यक्ति के लिए जिसके पास यह पता नहीं है... अगर तुम अपना यह पता और यह सिस्टम में मौजूद नहीं है, तो आपको इस तरह एक ईमेल प्राप्त होगा:

निःसंदेह, ऐसी स्वीकार्य स्थितियाँ हो सकती हैं जिनमें कोई सोचता हैकि आपने वेबसाइट पर पंजीकरण कर लिया है। लेकिन यह मामला नहीं है, या मैंने इसे किसी भिन्न ईमेल पते से किया है। ऊपर दिखाया गया उदाहरण दोनों स्थितियों को अच्छी तरह से संभालता है। जाहिर है, यदि पता मेल खाता है, तो आपको एक ईमेल प्राप्त होगा जिससे आपका पासवर्ड रीसेट करना आसान हो जाएगा।

एंट्रोपे द्वारा चुने गए समाधान की सूक्ष्मता यह है कि पहचान सत्यापन इसके अनुसार किया जाता है ईमेल किसी भी ऑनलाइन सत्यापन से पहले. कुछ साइटें उपयोगकर्ताओं से सुरक्षा प्रश्न का उत्तर मांगती हैं (इस पर अधिक जानकारी नीचे दी गई है) से रीसेट कैसे शुरू हो सकता है; हालाँकि, इसके साथ समस्या यह है कि आपको किसी प्रकार की पहचान (ईमेल या उपयोगकर्ता नाम) प्रदान करते समय प्रश्न का उत्तर देना होगा, जिससे अज्ञात उपयोगकर्ता के खाते के अस्तित्व का खुलासा किए बिना सहजता से उत्तर देना लगभग असंभव हो जाता है।

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

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

रीसेट पासवर्ड भेजना बनाम रीसेट यूआरएल भेजना

अगली अवधारणा जिस पर हमें चर्चा करने की आवश्यकता है वह है अपना पासवर्ड कैसे रीसेट करें। दो लोकप्रिय समाधान हैं:

1. सर्वर पर एक नया पासवर्ड बनाना और उसे ईमेल द्वारा भेजना
2. रीसेट प्रक्रिया को आसान बनाने के लिए एक अद्वितीय यूआरएल के साथ एक ईमेल भेजें

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

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

जब हम रीसेट यूआरएल के बारे में बात करते हैं, तो हमारा मतलब एक वेबसाइट का पता होता है रीसेट प्रक्रिया के इस विशेष मामले के लिए अद्वितीय. बेशक, यह यादृच्छिक होना चाहिए, इसका अनुमान लगाना आसान नहीं होना चाहिए, और इसमें खाते का कोई बाहरी लिंक नहीं होना चाहिए जिससे इसे रीसेट करना आसान हो जाए। उदाहरण के लिए, रीसेट URL केवल "Reset/?username=JohnSmith" जैसा पथ नहीं होना चाहिए।

हम एक अद्वितीय टोकन बनाना चाहते हैं जिसे रीसेट यूआरएल के रूप में मेल किया जा सके, और फिर उपयोगकर्ता के खाते के सर्वर रिकॉर्ड के साथ मिलान किया जा सके, इस प्रकार पुष्टि की जा सके कि खाता मालिक वास्तव में वही व्यक्ति है जो पासवर्ड रीसेट करने का प्रयास कर रहा है। उदाहरण के लिए, एक टोकन "3ce7854015cd38c862cb9e14a1ae552b" हो सकता है और रीसेट करने वाले उपयोगकर्ता की आईडी और टोकन उत्पन्न होने के समय (नीचे इस पर अधिक) के साथ एक तालिका में संग्रहीत किया जा सकता है। जब ईमेल भेजा जाता है, तो इसमें "Reset/?id=3ce7854015cd38c862cb9e14a1ae552b" जैसा URL होता है, और जब उपयोगकर्ता इसे डाउनलोड करता है, तो पेज टोकन के अस्तित्व के लिए संकेत देता है, जिसके बाद यह उपयोगकर्ता की जानकारी की पुष्टि करता है और उन्हें बदलने की अनुमति देता है। पासवर्ड।

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

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

अंततः, हमें यह सुनिश्चित करना होगा कि यह प्रक्रिया डिस्पोजेबल हो। एक बार रीसेट प्रक्रिया पूरी हो जाने के बाद, टोकन को हटा दिया जाना चाहिए ताकि रीसेट यूआरएल अब काम न करे। पिछला बिंदु यह सुनिश्चित करने के लिए आवश्यक है कि हमलावर के पास एक बहुत छोटी विंडो है जिसके दौरान वह रीसेट यूआरएल में हेरफेर कर सकता है। साथ ही, निश्चित रूप से, एक बार रीसेट सफल होने के बाद, टोकन की आवश्यकता नहीं रह जाती है।

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

कैप्चा की भूमिका

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

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

आइए पेपैल उदाहरण पर एक नज़र डालें:

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

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

गुप्त प्रश्न और उत्तर

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

वास्तव में, उपरोक्त लिंक सारा पॉलिन के याहू की हैकिंग के बारे में है! दो उद्देश्यों को पूरा करता है; सबसे पहले, यह दर्शाता है कि (कुछ) ईमेल खातों को हैक करना कितना आसान है, और दूसरे, यह दर्शाता है कि दुर्भावनापूर्ण इरादे से कितने खराब सुरक्षा प्रश्नों का उपयोग किया जा सकता है। लेकिन हम इस पर बाद में वापस आएंगे।

XNUMX% ईमेल-आधारित पासवर्ड रीसेट के साथ समस्या यह है कि जिस साइट को आप रीसेट करने का प्रयास कर रहे हैं उसके खाते की अखंडता ईमेल खाते की अखंडता पर XNUMX% निर्भर हो जाती है। कोई भी जिसके पास आपके ईमेल तक पहुंच है किसी भी खाते तक पहुंच है जिसे केवल एक ईमेल प्राप्त करके रीसेट किया जा सकता है. ऐसे खातों के लिए, ईमेल आपके ऑनलाइन जीवन के "सभी दरवाजों की कुंजी" है।

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

सारा पॉलिन पर वापस: गलती यह थी कि उसके सुरक्षा प्रश्न/प्रश्नों के उत्तर आसानी से मिल सकते थे। विशेष रूप से जब आप इतने महत्वपूर्ण सार्वजनिक व्यक्ति हों, तो आपकी मां के विवाह से पहले का नाम, शैक्षिक इतिहास, या अतीत में कोई व्यक्ति कहां रहा होगा, के बारे में जानकारी इतनी गुप्त नहीं होती है। वास्तव में, इसका अधिकांश भाग लगभग किसी को भी मिल सकता है। सारा के साथ यही हुआ:

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

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

आइए सुरक्षा प्रश्नों पर लौटते हैं - उपयोगकर्ता को अपने स्वयं के प्रश्न बनाने की अनुमति देने का एक विकल्प है। समस्या यह है कि इसके परिणामस्वरूप अत्यंत स्पष्ट प्रश्न उत्पन्न होंगे:

आसमान का रंग क्या है?

जब किसी सुरक्षा प्रश्न का उपयोग पहचान के लिए किया जाता है तो ऐसे प्रश्न लोगों को असहज कर देते हैं लोग (उदाहरण के लिए, कॉल सेंटर में):

क्रिसमस पर मैं किसके साथ सोया?

या स्पष्ट रूप से मूर्खतापूर्ण प्रश्न:

आप "पासवर्ड" कैसे लिखते हैं?

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

एक अच्छा सुरक्षा प्रश्न क्या है? यह कई कारकों से प्रभावित है:

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

जैसा कि होता है, अच्छे प्रश्न पूछने के लिए समर्पित एक वेबसाइट है जिसका नाम है GoodSecurityQuestions.com. कुछ प्रश्न काफी अच्छे लगते हैं, अन्य ऊपर वर्णित कुछ परीक्षणों में उत्तीर्ण नहीं होते हैं, विशेष रूप से "खोज में आसानी" परीक्षण।

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

परिणामस्वरूप, उपयोगकर्ता को निम्नलिखित पत्र प्राप्त होता है:

अब तक सब कुछ बिल्कुल सामान्य है, लेकिन इस रीसेट यूआरएल के पीछे क्या छिपा है:

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

खोज में आसानी के मामले में स्कूल और अस्पताल का प्रश्न थोड़ा कठिन हो सकता है, लेकिन अन्य भी उतने बुरे नहीं हैं। हालाँकि, सुरक्षा बढ़ाने के लिए, PayPal को अतिरिक्त पहचान की आवश्यकता होती है परिवर्तन सुरक्षा प्रश्नों के उत्तर:

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

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

फिर मैंने एक स्क्रीन देखी जहां मैं सुरक्षा प्रश्नों और उत्तरों के कई जोड़े, साथ ही एक बचाव ईमेल पता भी चुन सकता था:

जहां तक ​​पेपैल का सवाल है, प्रश्न पूर्व-चयनित हैं और उनमें से कुछ वास्तव में बहुत अच्छे हैं:

तीन प्रश्न/उत्तर युग्मों में से प्रत्येक संभावित प्रश्नों के एक अलग सेट का प्रतिनिधित्व करता है, इसलिए किसी खाते को कॉन्फ़िगर करने के बहुत सारे तरीके हैं।

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

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

[करने के लिए जारी।]

विज्ञापन के अधिकार पर

वीडीएसिना विश्वसनीय प्रदान करता है दैनिक भुगतान वाले सर्वर, प्रत्येक सर्वर 500 मेगाबिट्स के इंटरनेट चैनल से जुड़ा है और DDoS हमलों से निःशुल्क सुरक्षित है!

स्रोत: www.habr.com