तपाईंले सुरक्षित पासवर्ड रिसेट बारे जान्न चाहनुभएको सबै कुरा। भाग 1

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

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

पासवर्ड भण्डारण: ह्यासिङ, एन्क्रिप्शन र (हँस्दै!) सादा पाठ

हामीले बिर्सिएका पासवर्डहरूलाई कसरी भण्डारण गर्ने भनेर छलफल गर्नु अघि हामी छलफल गर्न सक्दैनौं। पासवर्डहरू डेटाबेसमा तीन मुख्य प्रकारहरू मध्ये एकमा भण्डारण गरिएका छन्:

1. सरल पाठ। त्यहाँ एउटा पासवर्ड स्तम्भ छ, जुन सादा पाठ फारममा भण्डार गरिएको छ।
2. इन्क्रिप्टेड। सामान्यतया सिमेट्रिक इन्क्रिप्सन प्रयोग गर्दै (एउटा कुञ्जी दुवै इन्क्रिप्सन र डिक्रिप्शनको लागि प्रयोग गरिन्छ), र एन्क्रिप्टेड पासवर्डहरू पनि एउटै स्तम्भमा भण्डारण गरिन्छ।
3. ह्यास गरिएको। एकतर्फी प्रक्रिया (पासवर्ड ह्यास गर्न सकिन्छ, तर डिह्याश गर्न सकिँदैन); पासवर्ड, म आशा गर्न चाहन्छु, नुन पछि, र प्रत्येक आफ्नै स्तम्भमा छ।

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

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

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

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

सावधानी

पोष्टको पाठमा तल अश्लील वेबसाइट AlotPorn को स्क्रिनसटको अंश छ। यसलाई सफासँग ट्रिम गरिएको छ त्यसैले तपाईंले समुद्र तटमा देख्न नसक्ने केही छैन, तर यदि यसले अझै पनि कुनै समस्या ल्याउने सम्भावना छ भने, तल स्क्रोल नगर्नुहोस्।

सधैं आफ्नो पासवर्ड रिसेट गर्नुहोस् कहिल्यै उसलाई सम्झाउनु हुँदैन

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

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

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

मलाई एउटा उदाहरणको साथ समस्या देखाउन दिनुहोस् usoutdoor.com: यहाँ एउटा सामान्य लगइन पृष्ठ छ:

जाहिर छ, पहिलो समस्या यो हो कि लगइन पृष्ठ HTTPS मा लोड हुँदैन, तर साइटले तपाइँलाई पासवर्ड ("पासवर्ड पठाउनुहोस्") पठाउन पनि संकेत गर्दछ। यो माथि उल्लेख गरिएको शब्दको बोलचाल प्रयोगको एक उदाहरण हुन सक्छ, त्यसैले यसलाई एक कदम अगाडि लैजाऔं र के हुन्छ हेरौं:

यो धेरै राम्रो देखिदैन, दुर्भाग्यवश; र एउटा इमेलले कुनै समस्या भएको पुष्टि गर्छ:

यसले हामीलाई usoutdoor.com को दुई महत्त्वपूर्ण पक्षहरू बताउँछ:

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

यो बाटो बाहिर संग, हामीले जाँच गर्न आवश्यक छ यदि रिसेट प्रक्रिया सुरक्षित तरिकामा गरिन्छ। यो गर्नको लागि पहिलो चरण भनेको अनुरोधकर्तासँग रिसेट गर्ने अधिकार छ भनी सुनिश्चित गर्नु हो। अर्को शब्दमा, यो भन्दा पहिले हामीलाई पहिचान जाँच चाहिन्छ; अनुरोधकर्ता वास्तवमा खाताको मालिक हो भनी पुष्टि नगरीकन पहिचान प्रमाणित गर्दा के हुन्छ भनेर हेरौं।

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

यो समस्या सबैभन्दा राम्रो दृश्य चित्रण गरिएको छ। समस्या:

देख्नुहुन्छ ? सन्देशमा ध्यान दिनुहोस् "यस इमेल ठेगानामा कुनै प्रयोगकर्ता दर्ता गरिएको छैन।" यदि यस्तो साइटले पुष्टि गर्छ भने समस्या स्पष्ट रूपमा उत्पन्न हुन्छ उपलब्धता यस्तो इमेल ठेगाना संग दर्ता प्रयोगकर्ता। बिंगो - तपाईंले भर्खरै आफ्नो पति/हाकिम/छिमेकीको पोर्न फेटिश पत्ता लगाउनुभयो!

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

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

यसको विकल्प के हो ? वास्तवमा, यो एकदम सरल छ, र आश्चर्यजनक रूपमा लागू गरिएको छ Entropay:

यहाँ Entropay ले आफ्नो प्रणालीमा इमेल ठेगानाको अस्तित्वको बारेमा बिल्कुलै केही खुलासा गर्दैन यस ठेगानाको स्वामित्व नभएको व्यक्तिलाई... यदि तिमी आफ्नै यो ठेगाना र यो प्रणालीमा अवस्थित छैन, त्यसपछि तपाईंले यस प्रकारको इमेल प्राप्त गर्नुहुनेछ:

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

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

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

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

रिसेट पासवर्ड पठाउने बनाम रिसेट URL पठाउने

हामीले छलफल गर्न आवश्यक अर्को अवधारणा तपाईको पासवर्ड कसरी रिसेट गर्ने हो। त्यहाँ दुई लोकप्रिय समाधानहरू छन्:

1. सर्भरमा नयाँ पासवर्ड उत्पन्न गर्दै र इमेल मार्फत पठाउने
2. रिसेट प्रक्रिया सजिलो बनाउनको लागि एक अद्वितीय URL को साथ ईमेल पठाउनुहोस्

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

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

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

हामी एउटा अद्वितीय टोकन सिर्जना गर्न चाहन्छौं जुन रिसेट URL को रूपमा पठाउन सकिन्छ, र त्यसपछि प्रयोगकर्ताको खाताको सर्भर रेकर्डसँग मेल खान्छ, यसरी खाता मालिकले पासवर्ड रिसेट गर्ने प्रयास गर्ने उही व्यक्ति हो भनेर पुष्टि गर्दछ। उदाहरणका लागि, टोकन "3ce7854015cd38c862cb9e14a1ae552b" हुन सक्छ र रिसेट गर्ने प्रयोगकर्ताको ID र टोकन उत्पन्न भएको समयको साथ तालिकामा भण्डारण गर्न सकिन्छ (यसको बारेमा थप तल)। जब इमेल पठाइन्छ, यसले "Reset/?id=3ce7854015cd38c862cb9e14a1ae552b" जस्ता URL समावेश गर्दछ, र जब प्रयोगकर्ताले यसलाई डाउनलोड गर्दछ, पृष्ठले टोकनको अस्तित्वको लागि प्रम्प्ट गर्दछ, त्यसपछि यसले प्रयोगकर्ताको जानकारी पुष्टि गर्दछ र पासवर्डलाई अनुमति दिन्छ। परिवर्तन भयो।

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

साथै रिसेट URL को लागि तपाईंले टोकन समय सीमा थप्न आवश्यक छ ताकि रिसेट प्रक्रिया निश्चित अन्तराल भित्र पूरा गर्न सकिन्छ, एक घण्टा भित्र भन्नुहोस्। यसले सुनिश्चित गर्दछ कि रिसेट समय सञ्झ्याल न्यूनतम राखिएको छ ताकि रिसेट URL को प्राप्तकर्ताले त्यो सानो विन्डो भित्र मात्र कार्य गर्न सक्छ। अवश्य पनि, आक्रमणकारीले पुन: रिसेट प्रक्रिया सुरु गर्न सक्छ, तर तिनीहरूले अर्को अद्वितीय रिसेट URL प्राप्त गर्न आवश्यक हुनेछ।

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

यी केही चरणहरू अत्यधिक अनावश्यक लाग्न सक्छ, तर तिनीहरूले उपयोगिता र हस्तक्षेप गर्दैनन् वास्तवमा सुरक्षामा सुधार गर्नुहोस्, यद्यपि हामीले आशा गरेको अवस्थामा दुर्लभ हुनेछ। 99% केसहरूमा, प्रयोगकर्ताले धेरै छोटो अवधिमा रिसेट सक्षम पार्नेछ र निकट भविष्यमा फेरि पासवर्ड रिसेट गर्दैन।

क्याप्चा को भूमिका

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

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

PayPal को उदाहरण हेरौं:

यस अवस्थामा, क्याप्चा हल नभएसम्म रिसेट प्रक्रिया मात्र सुरु हुन सक्दैन, त्यसैले सैद्धान्तिक यो प्रक्रिया स्वचालित गर्न असम्भव छ। सिद्धान्तमा।

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

गोप्य प्रश्न र उत्तरहरू

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

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

XNUMX% इमेल-आधारित पासवर्ड रिसेटको साथ समस्या यो हो कि तपाईंले रिसेट गर्न प्रयास गरिरहनुभएको साइटको लागि खाताको अखण्डता ईमेल खाताको अखण्डतामा XNUMX% निर्भर हुन्छ। तपाईंको इमेलमा पहुँच भएको जो कोही कुनै पनि खातामा पहुँच छ जुन इमेल प्राप्त गरेर रिसेट गर्न सकिन्छ। त्यस्ता खाताहरूका लागि, इमेल तपाईंको अनलाइन जीवनको "सबै ढोकाको कुञ्जी" हो।

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

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

ह्याकर डेभिड कर्नेलले पालिनको खातामा उनको विश्वविद्यालय र जन्म मिति जस्ता विवरणहरू पत्ता लगाएर र त्यसपछि याहूको बिर्सिएको पासवर्ड रिकभरी सुविधा प्रयोग गरेर उनको खातामा पहुँच प्राप्त गर्यो।

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

सुरक्षा प्रश्नहरूमा फर्कौं - प्रयोगकर्तालाई आफ्नै प्रश्नहरू सिर्जना गर्न अनुमति दिने विकल्प छ। समस्या यो हो कि यसले भयानक स्पष्ट प्रश्नहरूको परिणाम दिन्छ:

आकाशको रंग कस्तो छ?

सुरक्षा प्रश्न पहिचान गर्न प्रयोग गर्दा मानिसहरूलाई असहज बनाउने प्रश्नहरू व्यक्ति (उदाहरणका लागि, कल सेन्टरमा):

क्रिसमसमा म कोसँग सुतेँ?

वा स्पष्ट रूपमा मूर्ख प्रश्नहरू:

तपाइँ "पासवर्ड" कसरी हिज्जे गर्नुहुन्छ?

जब यो सुरक्षा प्रश्नहरू आउँछ, प्रयोगकर्ताहरू आफैंबाट बचाउन आवश्यक छ! अर्को शब्दमा, सुरक्षा प्रश्न साइट आफैले निर्धारण गर्नुपर्छ, वा अझ राम्रो, सोधिएको छ श्रृंखला सुरक्षा प्रश्नहरू जसबाट प्रयोगकर्ताले छनौट गर्न सक्छ। र यो छनौट गर्न सजिलो छैन один; आदर्श रूपमा प्रयोगकर्ताले दुई वा बढी सुरक्षा प्रश्नहरू चयन गर्नुपर्छ खाता दर्ताको समयमा, जुन त्यसपछि दोस्रो पहिचान च्यानलको रूपमा प्रयोग गरिनेछ। धेरै प्रश्नहरू हुनुले प्रमाणिकरण प्रक्रियामा आत्मविश्वास बढाउँछ, र अनियमितता थप्ने क्षमता पनि प्रदान गर्दछ (सधैं एउटै प्रश्न नदेखाउने), साथै वास्तविक प्रयोगकर्ताले पासवर्ड बिर्सेको अवस्थामा केही रिडन्डन्सी प्रदान गर्दछ।

राम्रो सुरक्षा प्रश्न के हो? यो धेरै कारकहरु द्वारा प्रभावित छ:

1. उहाँ हुनुपर्छ संक्षिप्त - प्रश्न स्पष्ट र अस्पष्ट हुनुपर्छ।
2. जवाफ हुनुपर्छ विशिष्ट - हामीलाई एक व्यक्तिले फरक जवाफ दिन सक्ने प्रश्न चाहिँदैन
3. सम्भावित उत्तरहरू हुनुपर्छ विविध - कसैको मनपर्ने रङ सोध्दा सम्भावित जवाफहरूको धेरै सानो उपसमूह उत्पन्न हुन्छ
4. Поиск जवाफ जटिल हुनुपर्छ - यदि जवाफ सजिलै पाउन सकिन्छ कुनै पनि (उच्च पदमा भएका मानिसहरूलाई सम्झनुहोस्), तब ऊ खराब छ
5. जवाफ हुनुपर्छ स्थायी समय मा - यदि तपाइँ कसैको मनपर्ने चलचित्र सोध्नु हुन्छ भने, एक वर्ष पछि जवाफ फरक हुन सक्छ

जसरी यो हुन्छ, त्यहाँ राम्रो प्रश्नहरू सोध्न समर्पित वेबसाइट भनिन्छ GoodSecurityQuestions.com। केहि प्रश्नहरू एकदम राम्रो देखिन्छन्, अरूले माथि वर्णन गरिएका केही परीक्षणहरू पास गर्दैनन्, विशेष गरी "खोजको सहजता" परीक्षण।

मलाई PayPal ले सुरक्षा प्रश्नहरू कसरी लागू गर्छ र विशेष गरी, साइटले प्रमाणीकरणमा राखेको प्रयासलाई देखाउन दिनुहोस्। माथि हामीले प्रक्रिया सुरु गर्न पृष्ठ देख्यौं (क्याप्चाको साथ), र यहाँ हामीले देखाउनेछौं कि तपाईंले आफ्नो इमेल ठेगाना प्रविष्ट गरेपछि र क्याप्चा समाधान गरेपछि के हुन्छ:

नतिजाको रूपमा, प्रयोगकर्ताले निम्न पत्र प्राप्त गर्दछ:

अहिलेसम्म सबै कुरा सामान्य छ, तर यहाँ यो रिसेट URL को पछाडि लुकेको छ:

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

विद्यालय र अस्पतालको प्रश्न खोजी सहजताको सन्दर्भमा अलिकति असजिलो हुन सक्छ, तर अन्य धेरै खराब छैनन्। यद्यपि, सुरक्षा बढाउनको लागि, PayPal लाई थप पहिचान चाहिन्छ परिवर्तन गर्नुहोस् सुरक्षा प्रश्नहरूको जवाफ:

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

सुरक्षा प्रश्न प्रणालीको सुविधा यो हो कि यदि तपाईंले यसलाई तुरुन्तै लागू गर्नुभएन भने, तपाईं यसलाई पछि थप्न सक्नुहुन्छ यदि स्रोत सुरक्षाको स्तर आवश्यक छ। यसको एक राम्रो उदाहरण एप्पल हो, जसले भर्खरै यो संयन्त्र लागू गर्यो [२०१२ मा लेखिएको लेख]। एकपटक मैले मेरो आईप्याडमा एप्लिकेसन अपडेट गर्न थालेपछि, मैले निम्न अनुरोध देखे:

त्यसपछि मैले एउटा स्क्रिन देखे जहाँ मैले धेरै जोडी सुरक्षा प्रश्न र उत्तरहरू, साथै उद्धार इमेल ठेगाना चयन गर्न सक्छु:

PayPal को रूपमा, प्रश्नहरू पूर्व-चयन गरिएका छन् र तिनीहरूमध्ये केही वास्तवमा राम्रो छन्:

प्रत्येक तीन प्रश्न/उत्तर जोडीले सम्भावित प्रश्नहरूको फरक सेटलाई प्रतिनिधित्व गर्दछ, त्यसैले त्यहाँ खाता कन्फिगर गर्ने प्रशस्त तरिकाहरू छन्।

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

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

[फेरि जारी राखौंला।]

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

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

स्रोत: www.habr.com