SaaS password reset और account recovery security guide
Generic responses, random single-use links, rate limits, सुरक्षित notifications और स्पष्ट session policy से account enumeration और reset-token abuse का जोखिम घटाएँ।
इस मार्गदर्शिका में
SaaS password-reset flow कैसे काम करना चाहिए?
सुरक्षित password-reset flow account owner को trusted recovery channel पर नियंत्रण साबित करने देता है, नया password set करवाता है और फिर सामान्य sign-in पर लौटाता है। अधिक entropy वाला, कम समय तक चलने वाला single-use token बनाएँ, उसे सुरक्षित रखें, requests व attempts सीमित करें और account मौजूद हो या न हो, public response समान रखें। Link को leak होने से बचाएँ और reset के बाद पुराने sessions के बारे में नीति तय करें।
Registered और unregistered दोनों accounts को एक जैसा public response दें
Reset request से email या username का customer account होना उजागर नहीं होना चाहिए। Response wording और processing व्यवहार यथासंभव समान रखें, abuse पर rate limit लगाएँ और केवल reset requests की वजह से account lock न करें। Enumeration patterns पर निगरानी रखें, लेकिन requester को account existence न बताएं।
Reset token random, सीमित, single-use और सुरक्षित रूप से stored हो
Cryptographically secure random source से token बनाएँ, उसे एक account और केवल reset purpose से बाँधें, जोखिम के अनुसार expiry दें और सफल use या replacement पर तुरंत invalid करें। जहाँ व्यावहारिक हो, raw token के बजाय उसका verifier या hash store करें। Token guessing को rate-limit करें और token से unrelated account functions चलने न दें।
Link trusted configuration से बनाएँ और leakage रोकें
Recovery URL को configured canonical HTTPS origin से बनाएँ, untrusted Host header से नहीं। Token analytics events, application logs, support tickets और third-party resources में न जाए। Reset page पर restrictive Referrer-Policy रखें, जहाँ संभव हो external scripts न लोड करें और नया password email से न भेजें।
| Flow का चरण | Account control का प्रमाण | Enumeration या abuse रोकथाम | Token और session handling | Accessibility और recovery owner |
|---|---|---|---|---|
| Reset request | ||||
| Reset link खोलना या code देना | ||||
| Password set करके समाप्त करना |
Reset link के अलावा account recovery को कैसे सुरक्षित करें?
सामान्य password rules लागू करें और सामान्य sign-in पर लौटाएँ
Password storage और policy वही रखें जो सामान्य change-password flow में है। नया password सुरक्षित ढंग से confirm कराएँ, completion संदेश दें और आम तौर पर recovery token से सीधे नई authenticated session बनाने के बजाय व्यक्ति को सामान्य तरीके से sign-in करने दें।
Session revocation और notification की स्पष्ट policy चुनें
Successful reset के बाद reset token invalidate करें और तय करें कि पुराने sessions, remember-me tokens और refresh tokens revoke होंगे या नहीं। अधिक जोखिम वाले product में सभी sessions हटाना उचित हो सकता है; असर समझाएँ और devices पर समान व्यवहार रखें। Password बदलने की सूचना भेजें, लेकिन password या authentication bypass करने वाला link न भेजें।
MFA, support और accessibility के लिए recovery design करें
Password recovery और MFA recovery अलग-अलग account-control proofs हैं। Password reset के बहाने user का MFA चुपचाप bypass न करें। जिस व्यक्ति का recovery channel खो गया हो, उसके लिए accessible और documented रास्ता रखें। Support staff को ad hoc security questions या email किए secret के बजाय स्वीकृत identity verification और audit प्रक्रिया अपनानी चाहिए।
Team account recovery को कैसे test और monitor करे?
Abuse, expiry और one-time-use व्यवहार जाँचें
Expired, अनुमानित, बदले हुए, पहले उपयोग किए गए या superseded token को अस्वीकार होना चाहिए। देखें कि लगातार requests से असीमित valid links तो नहीं बनते। Account identifier और network संकेतों के आधार पर उपयोगी rate limit लगाएँ, लेकिन attacker को victim का account आसानी से बंद कराने का मौका न दें। अस्वीकृत request password या session न बदले।
User enumeration और link leakage की जाँच करें
Registered और unregistered addresses के response, status, content और स्पष्ट timing की तुलना करें। Email templates, redirects, referrer headers, analytics, logs और support tools में token देखें। Unexpected Host header या proxy forwarding values के बावजूद reset URL अपेक्षित production host ही उपयोग करे।
Session revocation और support escalation को exercise करें
Reset के बाद पुराने browser sessions, refresh tokens और remembered devices को तय policy के अनुसार test करें। Lost-email या lost-device support flow जाँचें, overrides किसने किए इसका audit रखें और सुनिश्चित करें कि staff password बता या identity check bypass न कर सके। Authentication, email provider या account linking बदले तो फिर test करें।
SaaS password-reset के सवाल
क्या reset form को बताना चाहिए कि email account से जुड़ा है?
आम तौर पर नहीं। समान public response account enumeration कम करता है। वैध account holder को email या किसी अन्य verified channel पर अगले कदम मिल सकते हैं।
क्या reset token एक से अधिक बार चलना चाहिए?
नहीं। Token को उसके उद्देश्य तक सीमित, समय-बद्ध रखें और इस्तेमाल या बदलने के बाद invalid करें। इससे exposed link बाद में दोबारा उपयोग होने का जोखिम घटता है।
क्या reset के बाद user को अपने-आप sign in कर देना चाहिए?
OWASP सामान्य login पर लौटने की सलाह देता है क्योंकि अपने-आप session बनाना जटिलता और जोखिम जोड़ता है। पुराने sessions revoke होंगे या रहेंगे, यह documented risk policy से तय करें।
क्या password reset से खोया हुआ MFA factor भी वापस मिल जाता है?
अपने-आप नहीं। MFA recovery के लिए अलग documented verification चाहिए; password-reset flow उसे चुपचाप bypass न करे।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .