पासवर्ड-रीसेट और ओटीपी ईमेल डिलीवरी: प्रमाणीकरण और विलंबता की जांच करें

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

एक संशोधित ईवेंट टाइमलाइन बनाएं

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

SMTP स्वीकृति का अर्थ है कि सर्वर ने उस स्तर पर जिम्मेदारी स्वीकार कर ली है; यह इनबॉक्स प्लेसमेंट या किसी मानव द्वारा संदेश पढ़ने को प्रदर्शित नहीं करता है। समर्थन टूलींग में उस विशिष्टता को सुरक्षित रखें। RFC 5321.

OWASP लॉगिंग मार्गदर्शन नियमित लॉग से रहस्यों को बाहर करते हुए सहसंबंध का समर्थन करता है।

प्रमाणीकरण को आवेदन की वैधता से अलग करें

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

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

अन्य प्रमाणीकरण उपयोगों के लिए ईमेल द्वारा वितरित कोड को अपने स्वयं के सुरक्षा मूल्यांकन की आवश्यकता होती है। ईमेल कब्जे को फ़िशिंग-प्रतिरोधी प्रमाणीकरण के रूप में वर्णित न करें, और यह न मानें कि पासवर्ड-रीसेट अनुशंसा प्रत्येक ओटीपी परिनियोजन को मंजूरी देती है। अपनी डिजिटल-पहचान आवश्यकताओं के भीतर, NIST ईमेल को आउट-ऑफ-बैंड प्रमाणक के रूप में प्रतिबंधित करता है, जबकि पते-पुष्टि और पुनर्प्राप्ति कोड को उस निषेध से अलग करता है। NIST एसपी 800-63बी-4 अनुभाग 3.1.3 और 3.1.3.1.

वैधता बजट पर काम करें

एक काल्पनिक समयरेखा 09:00:00 पर टोकन निर्माण और 09:05:00 पर समाप्ति निर्धारित करती है। प्रदाता की स्वीकृति 09:00:10 पर होती है, रिसीवर की स्वीकृति 09:04:40 पर होती है और उदाहरणात्मक उपयोगकर्ता कार्रवाई 09:05:20 पर होती है। रिसीवर की स्वीकृति पर केवल 20 सेकंड शेष हैं; समाप्ति के 20 सेकंड बाद कार्रवाई होती है।

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

कार्रवाई योग्य प्रश्न यह है कि निर्माण और रिसीवर की स्वीकृति के बीच 280 सेकंड कहां गए। दूसरे 10 पर प्रदाता की स्वीकृति यह साबित नहीं करती है कि अगले 270 सेकंड पूरी तरह से एक प्रदाता के अंदर बिताए गए थे; जिम्मेदारी सौंपने से पहले कतार और प्रतिक्रिया साक्ष्य प्राप्त करें। इनबॉक्स दृश्यता अज्ञात बनी हुई है. किसी वास्तविक टोकन, उत्पादन खाते या डिलीवरी का परीक्षण नहीं किया गया।

विफल चरण की मरम्मत करें

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

बार-बार होने वाले क्लिक को मेल बाढ़ बनने से रोकने के लिए दर सीमा का उपयोग करें और सामान्य अनुरोध प्रतिक्रियाओं को स्पष्ट करें। एप्लिकेशन की टोकन नीति के साथ पुनः प्रयास का मिलान करें। किसी पुराने संदेश को आँख बंद करके दोबारा भेजने से ऐसा टोकन मिल सकता है जो पहले से ही अमान्य है, जबकि असीमित नए टोकन जारी करने से दुरुपयोग का जोखिम बढ़ सकता है।

रहस्य लॉग किए बिना सत्यापित करें

प्रासंगिक गंतव्यों पर अनुमोदित नियंत्रित खातों का परीक्षण करें और चरण विलंबता, समाप्ति परिणाम और डुप्लिकेट हैंडलिंग रिकॉर्ड करें। समाप्ति, टोकन सृजन या खाता पुनर्प्राप्ति में किसी भी बदलाव के लिए सुरक्षा समीक्षा की आवश्यकता होती है; जीवनकाल बढ़ाना कतारों को ठीक करने का विकल्प नहीं है।

घटना को चरण-विशिष्ट कारण, व्यापक निवारण और मापी गई ग्राहक यात्रा के साथ बंद करें। शेष दृश्यता अंतराल को स्पष्ट रखें. समर्थन को यह समझाने में सक्षम होना चाहिए कि "प्राप्तकर्ता द्वारा स्वीकार कर लिया गया है, वैधता विंडो समाप्त हो गई है" यह दावा किए बिना कि ग्राहक ने संदेश पढ़ा है या अपनी साख उजागर की है।

असफल अवस्था से मालिक चुनें

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