पासवर्ड ईमेल उलटण्यायोग्यता सिद्ध करतो, स्कीमा नाही

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

पुरावा त्याच पातळीवर ठेवा, आढाव्याचा उर्वरित भाग अचूक राहील।

जुने रहस्य परत पाठवणे काय सिद्ध करते

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

मधल्या प्रकरणाकडेही लक्ष द्या: ॲप्लिकेशनकडे असलेल्या की सह साठवलेला एन्क्रिप्टेड ब्लॉब प्रत्यक्षात उलटण्यायोग्य आहे, अहवालात एन्क्रिप्टेड हा शब्द दिलासा देणारा वाटला तरी।

हे रचनेचा निष्कर्ष का आहे, साठवणीचा नकाशा नाही

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

तुम्ही जे म्हणू शकता ते अधिक मर्यादित आणि अधिक उपयुक्त आहे: हा मार्ग रहस्य पुन्हा मिळवू शकतो, त्यामुळे उत्पादन पुनर्प्राप्तीयोग्य क्रेडेन्शियल अस्तित्वात नाही असा दावा करू शकत नाही। त्यापुढील प्रत्येक गोष्टीसाठी ऑपरेटरचा पुरावा लागतो।

रीसेट अधिकृततेभोवती उभारा

रीसेट वेगळी समस्या सोडवते: विनंती करणाऱ्याला नवीन पासवर्ड निवडण्याचा अधिकार आहे हे सिद्ध करणे। याबद्दलचे OWASP मार्गदर्शन सुरक्षितपणे तयार केलेले, एकदाच वापरता येणारे टोकन किंवा कोड आणि योग्य कालबाह्यता वर्णन करते, आणि विनंतीच्या टप्प्याकडे गणना व पूर यांपासून संरक्षित करावयाची गोष्ट म्हणून पाहते। अनधिकृत विनंतीने स्वतःहून खाते बदलू नये। बदली स्वीकारण्यापूर्वी अधिकृतता पडताळा, आणि एका यशस्वी वापरानंतर टोकन निरुपयोगी करा।

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

पासवर्ड ज्याचे संरक्षण करत होता ते अवैध करा

पासवर्ड बदलल्याने त्याने दिलेला प्रवेश आपोआप संपत नाही। सक्रिय VPN सत्रे, लक्षात ठेवलेली उपकरणे आणि सर्व्हरने जारी केलेली टोकन या प्रत्येकाचे स्वतःचे अवैधीकरण वर्तन असू शकते। त्यातील कोणते संपले पाहिजे हे सुज्ञपणे ठरवा, आणि अंमलबजावणी तसे करते याची पडताळणी करा, कारण रीसेटने आपल्याला सर्वत्र साइन आउट केले असे गृहीत धरणारा वापरकर्ता बऱ्याचदा चुकतो। तो निर्णय प्रवाहासोबत नोंदवा।

ऑपरेटरसाठी: कोणता घटक विनंती पडताळतो, कोणता क्रेडेन्शियल बदलतो आणि संबंधित सत्रे कशी हाताळली जातात ते नोंदवा। वापरकर्त्यांसाठी: वैध पुनर्प्राप्ती माध्यमाचे संरक्षण करा आणि पासवर्ड परत पाठवणाऱ्या कोणत्याही संदेशाकडे संशयाने पाहा।

अचूक मूल्यांकन संक्षिप्त आहे: संदेश काय सिद्ध करतो, काय अज्ञात राहते, आणि पुनर्प्राप्ती नियंत्रित प्रक्रियेद्वारे प्रवेश बदलते का।