पासवर्ड ईमेल उत्क्रमणीयता साबित करता है, कोई स्कीमा नहीं

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

सबूत को उसी स्तर पर रखें, और समीक्षा का बाकी हिस्सा सटीक बना रहेगा।

पुराना रहस्य लौटाना क्या साबित करता है

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

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

यह डिज़ाइन निष्कर्ष क्यों है, संग्रह का नक्शा नहीं

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

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

रीसेट को अनुमति के इर्द-गिर्द बनाएँ

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

ईमेल चैनल सुरक्षा मॉडल का हिस्सा है। खाते का नाम रखना कुछ साबित नहीं करता, और ऐसा रीसेट प्रवाह जो बताता है कि खाता मौजूद है या नहीं, हमलावर को काम करने के लिए एक निर्देशिका दे देता है।

जिसकी पासवर्ड रक्षा करता था उसे अमान्य करें

पासवर्ड बदलने से वह पहुँच अपने आप समाप्त नहीं होती जो उसने दी थी। सक्रिय VPN सत्र, याद रखे गए उपकरण और सर्वर द्वारा जारी टोकन—इनमें से हर एक का अमान्य करने का अपना व्यवहार हो सकता है। सचेत रूप से तय करें कि इनमें से कौन समाप्त होना चाहिए, और सत्यापित करें कि कार्यान्वयन ऐसा करता है, क्योंकि जो उपयोगकर्ता मानता है कि रीसेट ने उसे हर जगह से साइन आउट कर दिया है, वह अक्सर गलत होता है। उस निर्णय को प्रवाह के साथ दर्ज करें।

ऑपरेटरों के लिए: दस्तावेज़ करें कि कौन-सा घटक अनुरोध सत्यापित करता है, कौन क्रेडेंशियल बदलता है और संबंधित सत्र कैसे संभाले जाते हैं। उपयोगकर्ताओं के लिए: वैध पुनःप्राप्ति चैनल की रक्षा करें और पासवर्ड लौटाने वाले किसी भी संदेश को संदिग्ध मानें।

सटीक मूल्यांकन छोटा है: संदेश क्या साबित करता है, क्या अज्ञात रहता है, और क्या पुनःप्राप्ति नियंत्रित प्रक्रिया के ज़रिए पहुँच को बदल देती है।