सुरक्षित पासवर्ड रीसेट बद्दल तुम्हाला जे काही जाणून घ्यायचे होते. भाग 1

सुरक्षित पासवर्ड रीसेट वैशिष्ट्य कसे कार्य करावे याबद्दल मला अलीकडेच विचार करण्याची वेळ आली आहे, प्रथम जेव्हा मी ही कार्यक्षमता तयार करत होतो ASafaWeb, आणि नंतर जेव्हा त्याने दुसर्‍या व्यक्तीला असेच काहीतरी करण्यास मदत केली. दुस-या बाबतीत, मला त्याला रिसेट फंक्शन सुरक्षितपणे कसे अंमलात आणायचे याच्या सर्व तपशीलांसह कॅनोनिकल रिसोर्सची लिंक द्यायची होती. तथापि, समस्या अशी आहे की असे संसाधन अस्तित्त्वात नाही, कमीतकमी माझ्यासाठी महत्वाचे वाटणाऱ्या प्रत्येक गोष्टीचे वर्णन करणारे नाही. म्हणून मी ते स्वतः लिहायचे ठरवले.

तुम्ही पाहता, विसरलेल्या पासवर्डचे जग खरे तर खूप गूढ आहे. बरेच भिन्न, पूर्णपणे स्वीकार्य दृष्टिकोन आणि बरेच धोकादायक आहेत. अंतिम वापरकर्ता म्हणून तुम्ही त्यापैकी प्रत्येकाला अनेक वेळा भेटले असण्याची शक्यता आहे; त्यामुळे कोण योग्य करत आहे, कोण नाही आणि तुमच्या अॅपमध्ये वैशिष्ट्य मिळवण्यासाठी तुम्हाला कशावर लक्ष केंद्रित करणे आवश्यक आहे हे दाखवण्यासाठी मी ही उदाहरणे वापरण्याचा प्रयत्न करेन.

पासवर्ड स्टोरेज: हॅशिंग, एनक्रिप्शन आणि (हंफणे!) साधा मजकूर

विसरलेल्या पासवर्डचे काय करायचे ते आम्ही ते कसे संग्रहित करायचे यावर चर्चा करण्यापूर्वी आम्ही चर्चा करू शकत नाही. पासवर्ड डेटाबेसमध्ये तीन मुख्य प्रकारांपैकी एकामध्ये संग्रहित केले जातात:

1. साधा मजकूर. एक पासवर्ड कॉलम आहे, जो साध्या मजकूर स्वरूपात संग्रहित आहे.
2. एनक्रिप्टेड. सामान्यत: सिमेट्रिक एन्क्रिप्शन वापरणे (एक की एन्क्रिप्शन आणि डिक्रिप्शन दोन्हीसाठी वापरली जाते), आणि एनक्रिप्ट केलेले पासवर्ड देखील त्याच स्तंभात संग्रहित केले जातात.
3. हॅशड. वन-वे प्रक्रिया (पासवर्ड हॅश केला जाऊ शकतो, परंतु डिहॅश केला जाऊ शकत नाही); पासवर्ड, मी आशा करू इच्छितो, त्यानंतर मीठ, आणि प्रत्येक त्याच्या स्वतःच्या स्तंभात आहे.

चला सरळ सोप्या प्रश्नाकडे जाऊया: साध्या मजकुरात पासवर्ड कधीही साठवू नका! कधीच नाही. साठी एकच असुरक्षा इंजेक्शन, एक निष्काळजी बॅकअप, किंवा इतर डझनभर सोप्या चुकांपैकी एक - आणि तेच, गेमओव्हर, तुमचे सर्व पासवर्ड - म्हणजे माफ करा, तुमच्या सर्व क्लायंटचे पासवर्ड सार्वजनिक डोमेन होईल. अर्थात, याचा अर्थ असा मोठा संभव आहे त्यांचे सर्व पासवर्ड इतर सिस्टममधील त्यांच्या सर्व खात्यांमधून. आणि तो तुमचा दोष असेल.

एन्क्रिप्शन चांगले आहे, परंतु त्याच्या कमकुवतपणा आहेत. एन्क्रिप्शनची समस्या डिक्रिप्शन आहे; आम्ही हे विलक्षण दिसणारे सिफर घेऊ शकतो आणि त्यांना पुन्हा साध्या मजकुरात रूपांतरित करू शकतो आणि जेव्हा असे घडते तेव्हा आम्ही मानवी-वाचनीय संकेतशब्द स्थितीकडे परत येऊ. हे कसे घडते? कोडमध्ये एक छोटासा दोष आढळतो जो पासवर्ड डिक्रिप्ट करतो, तो सार्वजनिकरित्या उपलब्ध करतो - हा एक मार्ग आहे. हॅकर्स ज्या मशीनवर एनक्रिप्टेड डेटा संग्रहित केला जातो त्या मशीनमध्ये प्रवेश मिळवतात - ही दुसरी पद्धत आहे. दुसरा मार्ग, पुन्हा, डेटाबेस बॅकअप चोरणे आणि एखाद्याला एनक्रिप्शन की देखील मिळते, जी बर्याचदा असुरक्षितपणे संग्रहित केली जाते.

आणि हे आपल्याला हॅशिंगकडे आणते. हॅशिंग करण्यामागची कल्पना अशी आहे की ती एकतर्फी आहे; वापरकर्त्याने प्रविष्ट केलेल्या पासवर्डची त्याच्या हॅश आवृत्तीशी तुलना करण्याचा एकमेव मार्ग म्हणजे इनपुट हॅश करणे आणि त्यांची तुलना करणे. इंद्रधनुष्य सारण्यांसारख्या साधनांद्वारे होणारे हल्ले रोखण्यासाठी, आम्ही यादृच्छिकतेसह प्रक्रिया मीठ करतो (माझे वाचा पोस्ट क्रिप्टोग्राफिक स्टोरेज बद्दल). शेवटी, योग्यरित्या अंमलात आणल्यास, आम्ही खात्री बाळगू शकतो की हॅश केलेले पासवर्ड पुन्हा कधीही साधा मजकूर बनणार नाहीत (मी दुसर्‍या पोस्टमध्ये वेगवेगळ्या हॅशिंग अल्गोरिदमच्या फायद्यांबद्दल बोलेन).

हॅशिंग विरुद्ध एन्क्रिप्शन बद्दल एक द्रुत युक्तिवाद: तुम्हाला पासवर्ड हॅश करण्याऐवजी कूटबद्ध करणे आवश्यक असलेले एकमेव कारण म्हणजे जेव्हा तुम्हाला साध्या मजकुरात पासवर्ड पाहण्याची आवश्यकता असते आणि तुम्हाला हे कधीही नको आहे, किमान एक मानक वेबसाइट परिस्थितीत. आपल्याला याची आवश्यकता असल्यास, बहुधा आपण काहीतरी चुकीचे करत आहात!

खबरदारी

पोस्टच्या मजकुराच्या खाली अलोटपॉर्न या अश्लील वेबसाइटच्या स्क्रीनशॉटचा भाग आहे. ते सुबकपणे सुव्यवस्थित केले आहे त्यामुळे तुम्हाला समुद्रकिनार्यावर दिसणार नाही असे काहीही नाही, परंतु तरीही काही समस्या निर्माण होण्याची शक्यता असल्यास, खाली स्क्रोल करू नका.

तुमचा पासवर्ड नेहमी रीसेट करा कधीही नाही त्याला आठवण करून देऊ नका

तुम्हाला कधी फंक्शन तयार करण्यास सांगितले आहे स्मरणपत्रे पासवर्ड? एक पाऊल मागे घ्या आणि या विनंतीबद्दल उलट विचार करा: हे "स्मरणपत्र" आवश्यक का आहे? कारण वापरकर्ता पासवर्ड विसरला आहे. आम्हाला खरोखर काय करायचे आहे? त्याला पुन्हा लॉग इन करण्यास मदत करा.

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

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

मी एका उदाहरणासह समस्या दर्शवितो usoutdoor.com: येथे एक सामान्य लॉगिन पृष्ठ आहे:

अर्थात, पहिली अडचण ही आहे की लॉगिन पृष्ठ HTTPS वर लोड होत नाही, परंतु साइट तुम्हाला पासवर्ड ("पासवर्ड पाठवा") पाठवण्यास देखील सूचित करते. हे वर नमूद केलेल्या शब्दाच्या बोलचालीतील वापराचे एक उदाहरण असू शकते, तर चला एक पाऊल पुढे टाकू आणि काय होते ते पाहू:

दुर्दैवाने ते जास्त चांगले दिसत नाही; आणि एक ईमेल एक समस्या असल्याची पुष्टी करतो:

हे usoutdoor.com चे दोन महत्त्वाचे पैलू सांगतात:

1. साइट पासवर्ड हॅश करत नाही. सर्वोत्कृष्ट, ते कूटबद्ध केलेले आहेत, परंतु ते साध्या मजकुरात संग्रहित केले जाण्याची शक्यता आहे; याच्या विरुद्ध कोणताही पुरावा आम्हाला दिसत नाही.
2. साइट एका असुरक्षित चॅनेलवर दीर्घकालीन पासवर्ड पाठवते (आम्ही परत जाऊ शकतो आणि तो पुन्हा पुन्हा वापरू शकतो).

हे बाहेर असताना, आम्हाला रीसेट प्रक्रिया सुरक्षित पद्धतीने केली गेली आहे की नाही हे तपासण्याची आवश्यकता आहे. हे करण्यासाठी पहिली पायरी म्हणजे विनंतीकर्त्याला रीसेट करण्याचा अधिकार आहे याची खात्री करणे. दुसऱ्या शब्दांत, याआधी आपल्याला ओळख तपासणी आवश्यक आहे; विनंतीकर्ता हा खरेतर खाते मालक आहे हे सत्यापित न करता ओळख सत्यापित केल्यावर काय होते ते पाहू या.

वापरकर्तानावे सूचीबद्ध करणे आणि निनावीपणावर त्याचा प्रभाव

ही समस्या दृष्यदृष्ट्या उत्तम प्रकारे स्पष्ट केली आहे. समस्या:

बघतोय का? "या ईमेल पत्त्यावर कोणताही वापरकर्ता नोंदणीकृत नाही" या संदेशाकडे लक्ष द्या. अशा साइटची पुष्टी झाल्यास समस्या स्पष्टपणे उद्भवते उपलब्धता अशा ईमेल पत्त्यावर नोंदणीकृत वापरकर्ता. बिंगो - तुम्हाला आत्ताच तुमच्या नवऱ्याचा/बॉस/शेजाऱ्याचा पोर्न फेटिश सापडला आहे!

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

अशा पद्धतींमुळे "वापरकर्तानाव गणनेचा" धोका देखील वाढतो, ज्याद्वारे एखादी व्यक्ती वेबसाइटवरील वापरकर्तानावांच्या किंवा ईमेल पत्त्यांच्या संपूर्ण संग्रहाचे अस्तित्व फक्त समूह क्वेरी आयोजित करून आणि त्यांना मिळालेल्या प्रतिसादांचे परीक्षण करून सत्यापित करू शकते. तुमच्याकडे सर्व कर्मचाऱ्यांच्या ईमेल पत्त्यांची यादी आणि स्क्रिप्ट लिहिण्यासाठी काही मिनिटे आहेत का? मग बघा काय प्रॉब्लेम आहे ते!

पर्याय काय? खरं तर, हे अगदी सोपे आहे, आणि आश्चर्यकारकपणे अंमलात आणले आहे Entropay:

येथे एंट्रोपे त्याच्या सिस्टममध्ये ईमेल पत्त्याच्या अस्तित्वाबद्दल पूर्णपणे काहीही उघड करत नाही ज्याच्याकडे हा पत्ता नाही. जर तू स्वतःचे हा पत्ता आणि तो सिस्टीममध्ये अस्तित्वात नाही, तर तुम्हाला यासारखे ईमेल प्राप्त होईल:

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

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

या दृष्टिकोनासह आहे लहान उपयोगिता कमी झाली कारण तुम्ही अस्तित्वात नसलेले खाते रीसेट करण्याचा प्रयत्न केल्यास, त्वरित प्रतिक्रिया मिळणार नाही. अर्थात, ईमेल पाठवण्याचा हा संपूर्ण मुद्दा आहे, परंतु वास्तविक अंतिम वापरकर्त्याच्या दृष्टीकोनातून, जर त्यांनी चुकीचा पत्ता प्रविष्ट केला असेल, तर त्यांना प्रथमच ईमेल प्राप्त झाल्यावरच कळेल. यामुळे त्याच्याकडून काही तणाव निर्माण होऊ शकतो, परंतु अशा दुर्मिळ प्रक्रियेसाठी ही एक छोटी किंमत आहे.

दुसरी टीप, किंचित विषयापासून दूर: लॉगिन सहाय्य कार्ये जे उघड करतात की वापरकर्तानाव किंवा ईमेल पत्ता बरोबर आहे की नाही ते समान समस्या आहे. क्रेडेन्शियल्सच्या अस्तित्वाची स्पष्टपणे पुष्टी करण्याऐवजी नेहमी वापरकर्त्याला “तुमचे वापरकर्तानाव आणि संकेतशब्द संयोजन अवैध आहे” संदेशासह प्रतिसाद द्या (उदाहरणार्थ, “वापरकर्तानाव बरोबर आहे, परंतु पासवर्ड चुकीचा आहे”).

रीसेट पासवर्ड पाठवणे वि रीसेट URL पाठवणे

तुमचा पासवर्ड कसा रीसेट करायचा ते पुढील संकल्पनेवर चर्चा करायची आहे. दोन लोकप्रिय उपाय आहेत:

1. सर्व्हरवर नवीन पासवर्ड तयार करणे आणि ईमेलद्वारे पाठवणे
2. रीसेट प्रक्रिया सुलभ करण्यासाठी अद्वितीय URL सह ईमेल पाठवा

असूनही अनेक मार्गदर्शक, पहिला मुद्दा कधीही वापरला जाऊ नये. यासह समस्या अशी आहे की याचा अर्थ तेथे आहे संचयित पासवर्ड, ज्यावर तुम्ही परत येऊ शकता आणि कधीही वापरू शकता; ते एका असुरक्षित चॅनेलवर पाठवले होते आणि तुमच्या इनबॉक्समध्ये राहते. इनबॉक्सेस मोबाईल डिव्हाइसेस आणि ईमेल क्लायंटवर समक्रमित होण्याची शक्यता आहे, तसेच ते वेब ईमेल सेवेमध्ये बर्याच काळासाठी ऑनलाइन संग्रहित केले जाऊ शकतात. मुद्दा असा आहे की मेलबॉक्सला दीर्घकालीन स्टोरेजचे विश्वसनीय साधन मानले जाऊ शकत नाही.

परंतु याशिवाय, पहिल्या मुद्द्यामध्ये आणखी एक गंभीर समस्या आहे - ती शक्य तितके सोपे करते दुर्भावनापूर्ण हेतूने खाते अवरोधित करणे. वेबसाइटवर खाते असलेल्या एखाद्याचा ईमेल पत्ता मला माहीत असल्यास, मी त्यांचा पासवर्ड रीसेट करून त्यांना कधीही ब्लॉक करू शकतो; चांदीच्या ताटात सर्व्हिस अटॅकचा हा नकार आहे! म्हणूनच रिसेट फक्त विनंतीकर्त्याच्या अधिकारांची यशस्वी पडताळणी केल्यानंतरच केले जावे.

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

आम्हाला एक अद्वितीय टोकन तयार करायचे आहे जे रीसेट URL म्हणून मेल केले जाऊ शकते, आणि नंतर वापरकर्त्याच्या खात्याच्या सर्व्हर रेकॉर्डशी जुळले जाऊ शकते, अशा प्रकारे खाते मालक हीच व्यक्ती आहे जो पासवर्ड रीसेट करण्याचा प्रयत्न करत आहे याची पुष्टी करते. उदाहरणार्थ, टोकन "3ce7854015cd38c862cb9e14a1ae552b" असू शकते आणि रीसेट करत असलेल्या वापरकर्त्याच्या आयडीसह आणि टोकन जनरेट झाल्याची वेळ यासह टेबलमध्ये संग्रहित केले जाऊ शकते (खाली यावरील अधिक). जेव्हा ईमेल पाठवला जातो, तेव्हा त्यात “Reset/?id=3ce7854015cd38c862cb9e14a1ae552b” सारखी URL असते आणि जेव्हा वापरकर्ता ते डाउनलोड करतो, तेव्हा पृष्ठ टोकनच्या अस्तित्वासाठी सूचित करते, त्यानंतर ते वापरकर्त्याच्या माहितीची पुष्टी करते आणि त्यांना बदलण्याची परवानगी देते. पासवर्ड

अर्थात, वरील प्रक्रिया (आशेने) वापरकर्त्याला नवीन पासवर्ड तयार करण्यास अनुमती देत ​​असल्याने, URL HTTPS वर लोड केली आहे याची खात्री करणे आवश्यक आहे. नाही, HTTPS वर POST विनंतीसह पाठवणे पुरेसे नाही, या टोकन URL ने ट्रान्सपोर्ट लेयर सुरक्षा वापरणे आवश्यक आहे जेणेकरून नवीन पासवर्ड फॉर्मवर हल्ला होऊ शकत नाही एमआयटीएम आणि वापरकर्त्याने तयार केलेला पासवर्ड सुरक्षित कनेक्शनद्वारे प्रसारित केला गेला.

तसेच, रीसेट URL साठी, तुम्हाला टोकन वेळ मर्यादा जोडणे आवश्यक आहे जेणेकरून रीसेट प्रक्रिया एका तासाच्या आत, ठराविक अंतराने पूर्ण केली जाऊ शकते. हे सुनिश्चित करते की रीसेट वेळ विंडो कमीतकमी ठेवली जाते जेणेकरून रीसेट URL प्राप्तकर्ता फक्त त्या अगदी लहान विंडोमध्ये कार्य करू शकेल. नक्कीच, आक्रमणकर्ता रीसेट प्रक्रिया पुन्हा सुरू करू शकतो, परंतु त्यांना दुसरी अद्वितीय रीसेट URL प्राप्त करणे आवश्यक असेल.

शेवटी, ही प्रक्रिया डिस्पोजेबल असल्याची खात्री करणे आवश्यक आहे. रीसेट प्रक्रिया पूर्ण झाल्यावर, टोकन काढून टाकणे आवश्यक आहे जेणेकरून रीसेट URL यापुढे कार्य करणार नाही. मागील बिंदू हे सुनिश्चित करण्यासाठी आवश्यक आहे की आक्रमणकर्त्याकडे खूप लहान विंडो आहे ज्या दरम्यान तो रीसेट URL हाताळू शकतो. शिवाय, अर्थातच, एकदा रीसेट यशस्वी झाल्यानंतर, टोकनची आवश्यकता नाही.

यापैकी काही पायऱ्या अत्याधिक अनावश्यक वाटू शकतात, परंतु ते वापरण्यामध्ये व्यत्यय आणत नाहीत आणि खरं तर सुरक्षितता सुधारा, जरी आम्हाला आशा आहे की दुर्मिळ असेल अशा परिस्थितीत. 99% प्रकरणांमध्ये, वापरकर्ता खूप कमी कालावधीत रीसेट सक्षम करेल आणि नजीकच्या भविष्यात पासवर्ड पुन्हा रीसेट करणार नाही.

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

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

अर्थात, कॅप्चा स्वतः परिपूर्ण नाही; त्याचे सॉफ्टवेअर "हॅकिंग" आणि पुरेसा यश दर (60-70%) मिळवण्यासाठी अनेक उदाहरणे आहेत. याव्यतिरिक्त, माझ्या पोस्टमध्ये एक उपाय दर्शविला आहे स्वयंचलित लोकांद्वारे कॅप्चा हॅकिंग, जिथे तुम्ही लोकांना प्रत्येक कॅप्चा सोडवण्यासाठी आणि 94% चा यशाचा दर मिळवण्यासाठी एका सेंटचे अपूर्णांक देऊ शकता. म्हणजेच, ते असुरक्षित आहे, परंतु ते (किंचित) प्रवेशासाठी अडथळा वाढवते.

चला PayPal च्या उदाहरणावर एक नजर टाकूया:

या प्रकरणात, कॅप्चा निराकरण होईपर्यंत रीसेट प्रक्रिया सुरू होऊ शकत नाही, म्हणून सैद्धांतिकदृष्ट्या प्रक्रिया स्वयंचलित करणे अशक्य आहे. सिद्धांतामध्ये.

तथापि, बर्‍याच वेब अनुप्रयोगांसाठी हे ओव्हरकिल असेल आणि एकदम बरोबर वापरण्यातील घट दर्शवते - लोकांना कॅप्चा आवडत नाही! याव्यतिरिक्त, कॅप्चा अशी गोष्ट आहे जी आवश्यक असल्यास आपण सहजपणे परत येऊ शकता. जर सेवेवर हल्ला होऊ लागला (येथेच लॉगिंग उपयोगी पडते, परंतु नंतर त्यावर अधिक), तर कॅप्चा जोडणे सोपे होणार नाही.

गुप्त प्रश्न आणि उत्तरे

आम्ही विचारात घेतलेल्या सर्व पद्धतींसह, आम्ही ईमेल खात्यात प्रवेश करून पासवर्ड रीसेट करू शकलो. मी “फक्त” म्हणतो, परंतु, अर्थातच, दुसर्‍याच्या ईमेल खात्यात प्रवेश मिळवणे बेकायदेशीर आहे. हे केलेच पाहिजे एक जटिल प्रक्रिया व्हा. तथापि नेहमी असे नसते.

खरं तर, सारा पॉलिनच्या याहूच्या हॅकिंगबद्दल वरील लिंक! दोन उद्देश पूर्ण करते; प्रथम, ते (काही) ईमेल खाती हॅक करणे किती सोपे आहे हे स्पष्ट करते आणि दुसरे म्हणजे, ते दुर्भावनापूर्ण हेतूने सुरक्षिततेचे प्रश्न कसे वापरले जाऊ शकतात हे दर्शविते. परंतु आम्ही नंतर याकडे परत येऊ.

XNUMX% ईमेल-आधारित पासवर्ड रीसेट करताना समस्या अशी आहे की आपण रीसेट करण्याचा प्रयत्न करत असलेल्या साइटसाठी खात्याची अखंडता XNUMX% ईमेल खात्याच्या अखंडतेवर अवलंबून असते. तुमच्या ईमेलमध्ये प्रवेश असलेले कोणीही फक्त ईमेल प्राप्त करून रीसेट केले जाऊ शकते अशा कोणत्याही खात्यात प्रवेश आहे. अशा खात्यांसाठी, ईमेल ही तुमच्या ऑनलाइन जीवनाची “सर्व दारांची गुरुकिल्ली” आहे.

हा धोका कमी करण्याचा एक मार्ग म्हणजे सुरक्षा प्रश्न आणि उत्तर नमुना लागू करणे. तुम्ही त्यांना आधीच पाहिले असेल यात शंका नाही: फक्त तुम्हीच उत्तर देऊ शकता असा प्रश्न निवडा पाहिजे उत्तर जाणून घ्या, आणि नंतर तुम्ही तुमचा पासवर्ड रीसेट केल्यावर तुम्हाला तो विचारला जाईल. हे आत्मविश्वास जोडते की रीसेट करण्याचा प्रयत्न करणारी व्यक्ती खरोखरच खाते मालक आहे.

सारा पॉलिनकडे परत जा: चूक अशी होती की तिच्या सुरक्षा प्रश्न/प्रश्नांची उत्तरे सहज सापडू शकतात. विशेषत: जेव्हा तुम्ही इतके महत्त्वाचे सार्वजनिक व्यक्तिमत्व असता, तेव्हा तुमच्या आईचे पहिले नाव, शैक्षणिक इतिहास किंवा कोणीतरी भूतकाळात कोठे राहत असावे याबद्दलची माहिती हे सर्व काही गुप्त नसते. खरं तर, त्यापैकी बहुतेक जवळजवळ कोणालाही आढळू शकतात. साराच्या बाबतीत असे घडले आहे:

हॅकर डेव्हिड कर्नेलने पॉलिनच्या पार्श्वभूमीबद्दल तपशील शोधून तिच्या खात्यात प्रवेश मिळवला, जसे की तिची विद्यापीठ आणि जन्मतारीख, आणि नंतर Yahoo! चे विसरलेले पासवर्ड पुनर्प्राप्ती वैशिष्ट्य वापरून.

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

चला सुरक्षा प्रश्नांकडे परत जाऊया - वापरकर्त्याला त्यांचे स्वतःचे प्रश्न तयार करण्याची परवानगी देण्याचा पर्याय आहे. समस्या अशी आहे की यामुळे भयंकर स्पष्ट प्रश्न उद्भवतील:

आकाशाचा रंग कोणता आहे?

जेव्हा सुरक्षा प्रश्न ओळखण्यासाठी वापरला जातो तेव्हा असे प्रश्न जे लोकांना अस्वस्थ करतात व्यक्ती (उदाहरणार्थ, कॉल सेंटरमध्ये):

ख्रिसमसमध्ये मी कोणासोबत झोपलो?

किंवा स्पष्टपणे मूर्ख प्रश्न:

तुम्ही "पासवर्ड" कसे लिहाल?

जेव्हा सुरक्षा प्रश्नांचा विचार केला जातो तेव्हा वापरकर्त्यांना स्वतःपासून वाचवण्याची आवश्यकता असते! दुसऱ्या शब्दांत, सुरक्षितता प्रश्न साइटद्वारेच निर्धारित केला पाहिजे, किंवा अजून चांगला विचारला गेला पाहिजे मालिका सुरक्षा प्रश्न ज्यामधून वापरकर्ता निवडू शकतो. आणि ते निवडणे सोपे नाही один; आदर्शपणे वापरकर्त्याने दोन किंवा अधिक सुरक्षा प्रश्न निवडले पाहिजेत खाते नोंदणीच्या वेळी, जे नंतर दुसरे ओळख चॅनेल म्हणून वापरले जाईल. एकाधिक प्रश्न असण्याने पडताळणी प्रक्रियेवर आत्मविश्वास वाढतो आणि यादृच्छिकता जोडण्याची क्षमता देखील प्रदान करते (नेहमी समान प्रश्न दर्शवत नाही), तसेच वास्तविक वापरकर्ता संकेतशब्द विसरला असल्यास थोडा रिडंडंसी प्रदान करतो.

एक चांगला सुरक्षा प्रश्न काय आहे? हे अनेक घटकांद्वारे प्रभावित आहे:

1. तो असावा संक्षिप्त - प्रश्न स्पष्ट आणि अस्पष्ट असणे आवश्यक आहे.
2. उत्तर असायलाच हवे विशिष्ट - आम्हाला अशा प्रश्नाची आवश्यकता नाही ज्याचे उत्तर एक व्यक्ती वेगळ्या पद्धतीने देऊ शकेल
3. संभाव्य उत्तरे असावीत वैविध्यपूर्ण - एखाद्याचा आवडता रंग विचारल्यास संभाव्य उत्तरांचा एक अतिशय छोटा उपसंच मिळतो
4. Поиск उत्तर गुंतागुंतीचे असले पाहिजे - जर उत्तर सहज सापडले कोणतेही (उच्च पदावरील लोकांना लक्षात ठेवा), मग तो वाईट आहे
5. उत्तर असायलाच हवे कायम वेळेत - जर तुम्ही एखाद्याचा आवडता चित्रपट विचारला तर एक वर्षानंतर उत्तर वेगळे असू शकते

जसे घडते, तेथे चांगले प्रश्न विचारण्यासाठी समर्पित वेबसाइट आहे ज्याला म्हणतात GoodSecurityQuestions.com. काही प्रश्न खूप चांगले वाटतात, इतर वर वर्णन केलेल्या काही चाचण्या उत्तीर्ण होत नाहीत, विशेषत: "शोध सुलभता" चाचणी.

PayPal सुरक्षा प्रश्नांची अंमलबजावणी कशी करते आणि विशेषतः, साइट प्रमाणीकरणासाठी किती प्रयत्न करते हे मी दाखवू. वर आम्ही प्रक्रिया सुरू करण्यासाठी पृष्ठ पाहिले (कॅप्चा सह), आणि तुम्ही तुमचा ईमेल पत्ता प्रविष्ट केल्यानंतर आणि कॅप्चा सोडवल्यानंतर काय होते ते आम्ही येथे दर्शवू:

परिणामी, वापरकर्त्यास खालील पत्र प्राप्त होते:

आतापर्यंत सर्वकाही अगदी सामान्य आहे, परंतु या रीसेट URL च्या मागे काय लपलेले आहे ते येथे आहे:

त्यामुळे सुरक्षेचे प्रश्न समोर येतात. खरं तर, PayPal तुम्हाला तुमचा क्रेडिट कार्ड नंबर सत्यापित करून तुमचा पासवर्ड रीसेट करण्याची अनुमती देते, त्यामुळे एक अतिरिक्त चॅनेल आहे ज्यामध्ये अनेक साइट्सना प्रवेश नाही. मी उत्तर दिल्याशिवाय माझा पासवर्ड बदलू शकत नाही दोन्ही सुरक्षा प्रश्न (किंवा कार्ड नंबर माहित नाही). जरी कोणीतरी माझा ईमेल हायजॅक केला असला तरीही, त्यांना माझ्याबद्दल थोडी अधिक वैयक्तिक माहिती माहित असल्याशिवाय ते माझ्या PayPal खात्याचा पासवर्ड रीसेट करू शकणार नाहीत. काय माहिती? PayPal ऑफर करत असलेले सुरक्षा प्रश्न पर्याय येथे आहेत:

शोध सुलभतेच्या दृष्टीने शाळा आणि रुग्णालयाचे प्रश्न थोडेसे बिनधास्त असू शकतात, परंतु इतर फारसे वाईट नाहीत. तथापि, सुरक्षा वाढविण्यासाठी, PayPal ला अतिरिक्त ओळख आवश्यक आहे बदल करा सुरक्षा प्रश्नांची उत्तरे:

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

सुरक्षा प्रश्न प्रणालीची सोय अशी आहे की जर तुम्ही ती लगेच अंमलात आणली नसेल, तर संसाधन संरक्षणाच्या पातळीवर आवश्यक असल्यास तुम्ही ते नंतर जोडू शकता. याचे एक चांगले उदाहरण Appleपल आहे, ज्याने अलीकडेच ही यंत्रणा लागू केली आहे [२०१२ मध्ये लिहिलेला लेख]. एकदा मी माझ्या iPad वर ऍप्लिकेशन अपडेट करणे सुरू केल्यानंतर, मला खालील विनंती दिसली:

मग मला एक स्क्रीन दिसली जिथे मी अनेक जोड्या सुरक्षा प्रश्न आणि उत्तरे, तसेच एक बचाव ईमेल पत्ता निवडू शकतो:

PayPal साठी, प्रश्न पूर्व-निवडलेले आहेत आणि त्यापैकी काही खरोखर चांगले आहेत:

तीन प्रश्न/उत्तर जोड्यांपैकी प्रत्येक संभाव्य प्रश्नांच्या भिन्न संचाचे प्रतिनिधित्व करते, म्हणून खाते कॉन्फिगर करण्याचे बरेच मार्ग आहेत.

तुमच्या सुरक्षा प्रश्नाचे उत्तर देताना विचारात घेण्यासारखे आणखी एक पैलू म्हणजे स्टोरेज. डेटाबेसमध्‍ये साधा मजकूर डेटाबेस असल्‍याने जवळपास पासवर्ड सारखेच धोके निर्माण होतात, म्हणजे डेटाबेस उघड केल्‍याने त्‍याच मूल्‍य उघड होते आणि त्‍याच त्‍याच सुरक्षा प्रश्‍नांचा वापर करण्‍यासाठी केवळ अॅप्लिकेशनच नाही तर संभाव्यतः पूर्णपणे भिन्न अॅप्लिकेशन धोक्यात येतात (तेथे पुन्‍हा acai बेरी प्रश्न). एक पर्याय म्हणजे सुरक्षित हॅशिंग (एक मजबूत अल्गोरिदम आणि क्रिप्टोग्राफिकली यादृच्छिक मीठ), परंतु बहुतेक पासवर्ड स्टोरेज प्रकरणांप्रमाणे, प्रतिसाद साधा मजकूर म्हणून दृश्यमान होण्याचे एक चांगले कारण असू शकते. एक सामान्य परिस्थिती म्हणजे थेट टेलिफोन ऑपरेटरद्वारे ओळख पडताळणी. अर्थात, या प्रकरणात हॅशिंग देखील लागू आहे (ऑपरेटर फक्त क्लायंटने नाव दिलेला प्रतिसाद प्रविष्ट करू शकतो), परंतु सर्वात वाईट परिस्थितीत, गुप्त प्रतिसाद क्रिप्टोग्राफिक स्टोरेजच्या काही स्तरावर स्थित असणे आवश्यक आहे, जरी ते फक्त सममितीय एन्क्रिप्शन असले तरीही. . सारांश: रहस्यांना गुपितांसारखे वागवा!

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

[पुढे चालू.]

जाहिरातींच्या अधिकारांवर

VDSina विश्वसनीय ऑफर दैनिक पेमेंटसह सर्व्हर, प्रत्येक सर्व्हर 500 मेगाबिट्सच्या इंटरनेट चॅनेलशी कनेक्ट केलेला आहे आणि DDoS हल्ल्यांपासून विनामूल्य संरक्षित आहे!

स्त्रोत: www.habr.com