बैकएंड इंटरव्यू: एक सुरक्षित पासवर्ड रीसेट फ़्लो डिज़ाइन करें

प्रॉम्ट और लागू संदर्भ

एक उपभोक्ता वेब एप्लिकेशन के लिए सेल्फ़-सर्विस ईमेल-लिंक पासवर्ड रीसेट फ़्लो डिज़ाइन करें। रिक्वेस्ट API एक ईमेल पता स्वीकार करता है और जब कोई अकाउंट मेल खाता है, तो एक अपारदर्शी टोकन युक्त HTTPS लिंक भेजता है। टोकन निर्माण के 30 मिनट बाद समाप्त हो जाता है। डेटाबेस में रॉ बियरर (bearer) टोकन कभी स्टोर नहीं होना चाहिए।

डिज़ाइन को एक अप्रमाणित (unauthenticated) कॉलर को यह जानने से रोकना चाहिए कि क्या कोई ईमेल पंजीकृत है, किसी एक इनबॉक्स में ईमेल की बाढ़ (flooding) लाना, उपयोग किए गए लिंक को रीप्ले करना, किसी अन्य उपयोगकर्ता का पासवर्ड बदलना, या दूसरे रीसेट सबमिशन के साथ रेस जीतना। एक सफल रीसेट पासवर्ड बदलता है, उस अकाउंट के लिए प्रत्येक बकाया रीसेट टोकन को अमान्य करता है, मौजूदा प्रमाणित सत्रों को रद्द करता है, और एक सुरक्षा सूचना भेजता है। पासवर्ड रीसेट नामांकित MFA प्रमाणक (authenticator) को हटाता या बदलता नहीं है।

यह मुख्य रूप से बैकएंड सुरक्षा और निरंतरता (consistency) का प्रश्न है। एक परिष्कृत उत्तर थ्रेट मॉडल को API अनुबंध, टोकन लाइफ़साइकिल, डेटाबेस ट्रांज़ैक्शन, ईमेल डिलीवरी, सत्र मॉडल और परिचालन साक्ष्य (operational evidence) से जोड़ता है। केवल एक यादृच्छिक (random) टोकन और समाप्ति समय का नाम देना सिर्फ़ शुरुआत है; कठिन हिस्सा प्रत्येक अवलोकनीय (observable) और समवर्ती पथ को समान सुरक्षा अनुबंध का पालन कराना है।

इंटरव्यूअर क्या मूल्यांकन करता है

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

दूसरा संकेत रॉ टोकन और उसके संग्रहीत सत्यापनकर्ता (verifier) के बीच का अंतर है। ईमेल में एक उच्च-एन्ट्रॉपी बियरर सीक्रेट होता है। डेटाबेस केवल एक वन-वे डाइजेस्ट (digest) स्टोर करता है, इसलिए टोकन तालिका को पढ़ने से सीधे कोई प्रयोग करने योग्य लिंक प्रकट नहीं होता है। उम्मीदवार को इस यादृच्छिक टोकन को मानव पासवर्ड से भी अलग करना चाहिए: उपयोगकर्ता द्वारा चुने गए पासवर्ड के लिए एक धीमे पासवर्ड हैश की आवश्यकता होती है, जबकि समान रूप से यादृच्छिक 256-बिट टोकन को अनुमान लगाने योग्य बने बिना एक तेज़ क्रिप्टोग्राफ़िक डाइजेस्ट द्वारा अनुक्रमित (indexed) किया जा सकता है।

तीसरा संकेत ट्रांज़ैक्शन डिज़ाइन है। एप्लिकेशन कोड में used_at की जांच करना और बाद में इसे अपडेट करना एक रीप्ले रेस बनाता है। एक ही उपयोगकर्ता के लिए दो अलग-अलग मान्य टोकन एक और रेस बनाते हैं जब तक कि अकाउंट क्रमबद्धता बिंदु (serialization point) न हो। एक मज़बूत उत्तर उपयोगकर्ता पंक्ति को लॉक करता है, प्रस्तुत टोकन का सशर्त उपभोग करता है, पासवर्ड बदलता है, सिबलिंग (sibling) टोकन और सत्रों को रद्द करता है, और एक छोटे ट्रांज़ैक्शन के अंदर एक आउटबॉक्स इवेंट रिकॉर्ड करता है।

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

अंतिम संकेत परिचालन संबंधी सोच (operational thinking) है। यदि समय (timing), रेट-लिमिट व्यवहार, लॉग, एनालिटिक्स या सपोर्ट टूलिंग अभी भी अकाउंट के अस्तित्व या रॉ टोकन का खुलासा करते हैं तो सामान्य प्रतिक्रियाएं अप्रभावी होती हैं। ईमेल डिलीवरी को अकाउंट को समय से पहले बदले बिना प्रदाता विफलताओं से बचना चाहिए, और मॉनिटरिंग को लॉग में बियरर सीक्रेट को स्टोर किए बिना दुरुपयोग का पता लगाना चाहिए।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

• क्या यह पासवर्ड प्रतिस्थापन है या पूर्ण अकाउंट रिकवरी? यदि उपयोगकर्ता के पास अभी भी एक सत्यापित ईमेल है लेकिन केवल पासवर्ड खो गया है, तो लिंक उस पासवर्ड को बदल सकता है। ईमेल एक्सेस, MFA और रिकवरी कोड खोने के लिए एक मज़बूत, अलग रिकवरी प्रक्रिया की आवश्यकता होती है।
• क्या अकाउंट MFA का उपयोग करता है? पासवर्ड रीसेट को नामांकित फ़ैक्टर को बरकरार रखना चाहिए। यदि उत्पाद दोनों को पुनर्प्राप्त करने के लिए एक फ़्लो चाहता है, तो इसकी आश्वासन आवश्यकताएं और दुरुपयोग समीक्षा काफी हद तक बदल जाती है।
• किन सत्रों को रद्द किया जाना चाहिए? यह प्रॉम्ट सभी सत्रों को रद्द करता है। आरंभ करने वाले डिवाइस को साइन इन रखने के लिए इस बात के प्रमाण की आवश्यकता होगी कि यह पहले से ही विश्वसनीय था और एक स्पष्ट रूप से प्रलेखित अपवाद था।
• क्या कई लिंक बकाया हो सकते हैं? एक छोटी सीमित संख्या की अनुमति देने से केवल इसलिए एक वैध ईमेल को अमान्य करने से बचा जाता है क्योंकि बाद का संदेश पहले आया था। जो भी लिंक सफल होता है उसे उस उपयोगकर्ता के लिए हर दूसरे लिंक को रद्द करना होगा।
• कौन से जोखिम और डिलीवरी चैनल लागू होते हैं? कम जोखिम वाले उपभोक्ता अकाउंट के लिए ईमेल स्वीकार्य हो सकता है लेकिन वित्तीय या विनियमित एक्सेस के लिए अपर्याप्त हो सकता है। SMS, रिकवरी कोड, सपोर्ट प्रूफ़िंग और प्रतीक्षा अवधि में अलग-अलग टेकओवर और उपलब्धता जोखिम होते हैं।
• साइन-इन को कौन सी पासवर्ड नीति पहले से नियंत्रित करती है? रीसेट को समान लंबाई, ब्लॉकलिस्ट और हैश नीति का उपयोग करना चाहिए। एक कमज़ोर रीसेट-विशिष्ट नीति एक प्रमाणीकरण बाईपास बन जाती है।
• कौन सा दुरुपयोग बजट और ईमेल-प्रदाता सीमाएं मौजूद हैं? रेट लिमिट को अकाउंट, IP, डिवाइस और वैश्विक प्रदाता क्षमता जैसे आयामों की आवश्यकता होती है। केवल अकाउंट के लिए हार्ड लॉक हमलावर को ज्ञात पीड़ित के लिए रिकवरी से वंचित करने की अनुमति देता है।

30-सेकंड उत्तर ढांचा

“मैं प्रत्येक ईमेल के लिए समान 202 प्रतिक्रिया और संदेश लौटाऊंगा, फिर स्तरित (layered) रेट सीमाओं के पीछे एसिंक्रोनस रूप से लुकअप और डिलीवरी निष्पादित करूंगा। एक वास्तविक अकाउंट के लिए, मैं 32 रैंडम बाइट्स जनरेट करूंगा, कॉन्फ़िगर किए गए HTTPS ऑरिजिन से बने लिंक में base64url टोकन ईमेल करूंगा, और उपयोगकर्ता और 30-मिनट की समाप्ति के साथ केवल इसका डाइजेस्ट स्टोर करूंगा। GET पेज कभी भी टोकन का उपभोग नहीं करता है। अंतिम POST पर, मैं इसे पुनः मान्य करता हूं, नए पासवर्ड को हैश करता हूं, उपयोगकर्ता पंक्ति को लॉक करता हूं, टोकन को परमाणु रूप से (atomically) उपयोग के रूप में चिह्नित करता हूं, पासवर्ड अपडेट करता हूं, अन्य सभी रीसेट टोकन और सत्रों को रद्द करता हूं, और अधिसूचना व ऑडिट आउटबॉक्स इवेंट लिखता हूं। समवर्ती या रीप्ले किए गए अनुरोध तब सशर्त उपभोग में विफल हो जाते हैं। MFA रिकवरी एक अलग फ़्लो बनी रहती है।”

चरण-दर-चरण विस्तृत समीक्षा

दो सार्वजनिक एंडपॉइंट और जानबूझकर छोटे प्रतिक्रिया अनुबंधों के साथ शुरुआत करें:

POST /password-reset-requests
{ "email": "person@example.com" }

202 Accepted
{ "message": "If an account matches, reset instructions will be sent." }

POST /password-resets
{ "token": "opaque-base64url-value", "new_password": "..." }

अनुरोध एंडपॉइंट समान स्थिति, संदेश संरचना (shape) और कैश नीति लौटाता है चाहे अकाउंट मौजूद हो या नहीं। इसे वापस लौटने से पहले एक सीमित कतार (bounded queue) को काम सौंपना चाहिए ताकि एक स्पष्ट डेटाबेस त्वरित निकास (quick exit) या SMTP कॉल टाइमिंग ओरेकल न बनाए। एक निश्चित स्लीप न जोड़ें और समस्या को हल न समझें: कतार संतृप्ति (queue saturation), केवल-अकाउंट थ्रॉटल, और अलग-अलग त्रुटि पथ अभी भी व्यवहार को उजागर कर सकते हैं या सेवा से इनकार (DoS) उपकरण बन सकते हैं।

ईमेल को केवल उत्पाद के सत्यापित पहचान नियमों के अनुसार सामान्यीकृत (normalize) करें। डोमेन को लोअरकेस करना मान्य हो सकता है; प्रत्येक डोमेन पर प्रदाता-विशिष्ट नियमों को लागू करना जैसे डॉट्स या प्लस टैग को हटाना दो अलग-अलग खातों को जोड़ सकता है। सामान्यीकृत अकाउंट कुंजी, स्रोत IP या नेटवर्क, डिवाइस या जोखिम संकेत, और ईमेल प्रदाता के वैश्विक बजट में रेट सीमाओं को स्तरित करें। संदिग्ध ट्रैफ़िक को चुनौती (challenge) के लिए एस्केलेट करें। सार्वजनिक प्रतिक्रिया सामान्य बनी रहती है, और भूला हुआ पासवर्ड अनुरोध कभी भी अकाउंट को लॉक नहीं करता है या उसका पासवर्ड नहीं बदलता है।

मौजूदा खाते के लिए, क्रिप्टोग्राफ़िक रूप से सुरक्षित रैंडम जनरेटर के साथ 32 बाइट्स उत्पन्न करें। वह 256 बिट्स है; अनपैडेड base64url इसे 43 वर्णों में दर्शाता है। यह एक डिज़ाइन विकल्प है, कोई सार्वभौमिक समाप्ति या एन्कोडिंग नियम नहीं। SHA-256(raw_token) स्टोर करें और कच्चा मान केवल ईमेल लिंक के माध्यम से भेजें। क्योंकि इनपुट समान रूप से यादृच्छिक और उच्च एन्ट्रापी वाला है, एक तेज़ वन-वे डाइजेस्ट इंडेक्स किए गए लुकअप का समर्थन करता है; डाइजेस्ट को ही सबमिट किए गए बियरर मान के रूप में उपयोग करना विफल हो जाता है क्योंकि सर्वर इनपुट को फिर से हैश करता है। पासवर्ड कम-एन्ट्रॉपी मानव रहस्य हैं और इसलिए इसके बजाय एक धीमे, सॉल्टेड पासवर्ड हैश की आवश्यकता होती है।

एक उदाहरणात्मक PostgreSQL तालिका है:

CREATE TABLE password_reset_tokens (
  id uuid PRIMARY KEY,
  user_id uuid NOT NULL REFERENCES users(id),
  token_digest bytea NOT NULL UNIQUE,
  created_at timestamptz NOT NULL,
  expires_at timestamptz NOT NULL,
  used_at timestamptz,
  revoked_at timestamptz
);

CREATE INDEX password_reset_tokens_active_user_idx
  ON password_reset_tokens (user_id, expires_at)
  WHERE used_at IS NULL AND revoked_at IS NULL;

ईमेल URL में अविश्वसनीय Host हेडर के बजाय एक कॉन्फ़िगर किया गया या अनुमति सूची (allowlist) वाला ऑरिजिन उपयोग किया जाना चाहिए। HTTPS का उपयोग करें, एप्लिकेशन, प्रॉक्सी, एनालिटिक्स और एरर लॉग से टोकन को हटा दें (redact करें), और रीसेट पेज से तीसरे पक्ष की संपत्तियों को दूर रखें। no-referrer नीति सेट करें ताकि नेविगेशन क्वेरी टोकन का खुलासा न करे। एक GET फ़ॉर्म दिखा सकता है या रिपोर्ट कर सकता है कि एक लिंक अमान्य है, लेकिन इसे टोकन का उपभोग नहीं करना चाहिए: मेल सुरक्षा स्कैनर और लिंक पूर्वावलोकन उपयोगकर्ता से पहले नियमित रूप से लिंक पर जाते हैं।

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

अंतिम स्थिति परिवर्तन क्रमबद्धता बिंदु के रूप में उपयोगकर्ता पंक्ति का उपयोग करता है:

candidate = find token by SHA-256(raw_token)
reject publicly if candidate is missing, expired, used, or revoked
new_hash = Argon2id(new_password, fresh_salt, tuned_parameters)

BEGIN
  SELECT id FROM users WHERE id = candidate.user_id FOR UPDATE

  UPDATE password_reset_tokens
  SET used_at = now()
  WHERE id = candidate.id
    AND used_at IS NULL
    AND revoked_at IS NULL
    AND expires_at > now()
  RETURNING user_id

  if no row returned: ROLLBACK and reject

  UPDATE users
  SET password_hash = new_hash,
      password_changed_at = now(),
      auth_version = auth_version + 1
  WHERE id = candidate.user_id

  UPDATE password_reset_tokens
  SET revoked_at = now()
  WHERE user_id = candidate.user_id
    AND id <> candidate.id
    AND used_at IS NULL
    AND revoked_at IS NULL

  DELETE FROM sessions WHERE user_id = candidate.user_id

  INSERT security_outbox(password_reset_succeeded, user_id, occurred_at)
COMMIT

BEGIN से पहले हैश की गणना करें, लेकिन इसे तब तक कभी कमिट न करें जब तक कि सशर्त टोकन अपडेट सफल न हो जाए। एक नई तैनाती के लिए, OWASP वर्तमान में 19 MiB मेमोरी, दो पुनरावृत्तियों (iterations) और समानता की एक डिग्री (degree of parallelism) के साथ Argon2id को एक न्यूनतम कॉन्फ़िगरेशन के रूप में सूचीबद्ध करता है; बेंचमार्क करें और वैध प्रमाणीकरण क्षमता को सुरक्षित रखते हुए लागत बढ़ाएं। एल्गोरिदम और पैरामीटर को पासवर्ड हैश के साथ स्टोर करें ताकि वे विकसित हो सकें। Bcrypt इनपुट-लंबाई की कमी वाला एक लीगेसी फ़ॉलबैक है, कोई ड्रॉप-इन समानार्थी नहीं है।

पंक्ति लॉक दो रेस वर्गों को संभालता है। यदि दो अनुरोध एक ही टोकन प्रस्तुत करते हैं, तो केवल पहला सशर्त अपडेट used_at सेट कर सकता है। यदि वे एक उपयोगकर्ता के लिए दो अलग-अलग मान्य टोकन प्रस्तुत करते हैं, तो दोनों प्रारंभिक पढ़ने और हैश कार्य को पास कर सकते हैं, लेकिन केवल एक उपयोगकर्ता लॉक रखता है। वह ट्रांज़ैक्शन दूसरे टोकन को रद्द कर देता है; दूसरे अनुरोध द्वारा लॉक प्राप्त करने के बाद, इसका सशर्त अपडेट कोई पंक्ति नहीं लौटाता है। इसलिए पासवर्ड का एक विजयी मान होता है, और प्रत्येक हारने वाला अनुरोध एक अंतिम (terminal) टोकन स्थिति देखता है।

सर्वर-साइड सत्र विलोपन डेटाबेस-समर्थित सत्रों के लिए तत्काल अमान्यकरण प्रदान करता है। रिफ़्रेश टोकन के साथ, उनके सर्वर रिकॉर्ड रद्द करें। अन्यथा स्टेटलेस एक्सेस टोकन के लिए, auth_version को बढ़ाना या password_changed_at की जांच करना केवल तभी काम करता है जब प्रत्येक संरक्षित अनुरोध उस सर्वर स्थिति की तुलना करता है; ऐसे चेक के बिना, टोकन समाप्ति तक निरस्तीकरण में देरी होती है। यह दावा करने के बजाय कि ब्राउज़र कुकी को हटाने से किसी हमलावर को कहीं और से रद्द कर दिया जाता है, उस सीमा को स्पष्ट करें।

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

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

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

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

फ़्लो को केवल एक हैप्पी-पाथ एंडपॉइंट के रूप में नहीं, बल्कि एक स्टेट मशीन के रूप में टेस्ट करें। एक ही टोकन के साथ और एक उपयोगकर्ता के लिए दो अलग-अलग टोकन के साथ समानांतर POST भेजें; ठीक एक सफल हो सकता है। सीमा पर समाप्ति, सफलता के बाद पुन: उपयोग, सिबलिंग-टोकन निरस्तीकरण, गैर-मौजूद खाते, कतार और ईमेल आउटेज, Host-हेडर हेरफेर, Referer रिसाव, लॉग रिडैक्शन, रेट-लिमिट आयाम, किसी अन्य डिवाइस पर सत्र अस्वीकृति, अधिसूचना पुनरावृत्ति, और MFA वाले खाते को सत्यापित करें। सुरक्षा स्कैनर्स को टोकन का उपभोग किए बिना लिंक पर GET करने में सक्षम होना चाहिए।

उच्च गुणवत्ता वाला नमूना उत्तर

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

एक मेल खाने वाले अकाउंट के लिए, मैं 32 रैंडम बाइट्स उत्पन्न करता हूं, HTTPS लिंक में base64url मान भेजता हूं, और केवल इसका SHA-256 डाइजेस्ट, उपयोगकर्ता ID और 30-मिनट की समाप्ति को स्टोर करता हूं। रीसेट ऑरिजिन Host से प्राप्त होने के बजाय कॉन्फ़िगर किया गया है; पेज में कोई तृतीय-पक्ष संसाधन नहीं हैं, एक no-referrer नीति का उपयोग करता है, और सभी लॉग पाइपलाइन टोकन को रिडैक्ट करते हैं। GET केवल फ़ॉर्म प्रदर्शित करता है क्योंकि एक ईमेल स्कैनर लिंक खोल सकता है।

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

कमिट के बाद, कार्यकर्ता सुरक्षा सूचना भेजते हैं और स्वतंत्र रूप से पुनः प्रयास करते हैं। मैं सामान्य प्रतिक्रियाओं और समय, टोकन और URL लीकेज, समवर्ती उपयोग, समाप्ति, प्रदाता विफलता, रिमोट-सत्र अस्वीकृति और MFA खातों का परीक्षण करूंगा। पासवर्ड रीसेट करने से MFA बरकरार रहता है; सभी प्रमाणक खोने पर एक अलग उच्च-आश्वासन रिकवरी प्रक्रिया से गुज़रना पड़ता है।”

सामान्य गलतियां

• “ईमेल नहीं मिला” लौटाना → एक हमलावर पंजीकृत खातों की गणना कर सकता है → समान सार्वजनिक स्थिति और संदेश लौटाएं और त्वरित-निकास टाइमिंग पथ से बचें।
• रॉ टोकन स्टोर करना → एक डेटाबेस रीडर काम करने वाले रीसेट लिंक प्राप्त कर लेता है → एक वन-वे डाइजेस्ट स्टोर करें और डिलीवरी और उपयोगकर्ता सबमिशन को छोड़कर हर जगह रॉ मान को रिडैक्ट करें।
• अंतिम फ़ॉर्म से उपयोगकर्ता ID का उपयोग करना → एक क्लाइंट लक्षित खाते को बदल सकता है → उपयोगकर्ता को केवल सर्वर-साइड टोकन रिकॉर्ड से प्राप्त करें।
• GET पर लिंक का उपभोग करना → उपयोगकर्ता के आने से पहले एक ईमेल स्कैनर इसे अमान्य कर सकता है → केवल पासवर्ड बदलने वाले POST के दौरान उपभोग करें।
• GET पर मान्य करना लेकिन POST पर नहीं → एक जाली क्लाइंट प्रदर्शित फ़ॉर्म को बायपास करता है → अंतिम सर्वर-साइड ट्रांज़ैक्शन में समाप्ति और अंतिम स्थिति को फिर से मान्य करें।
• बिना किसी शर्त के जांचना और फिर अपडेट करना → समानांतर अनुरोध दोनों जांच पास कर सकते हैं → एक ट्रांज़ैक्शन के अंदर एक सशर्त अपडेट का उपयोग करें और उपयोगकर्ता पंक्ति पर विभिन्न टोकन को क्रमबद्ध करें।
• हर अनुरोध पर पिछले लिंक को अमान्य करना → एक हमलावर पीड़ित के नवीनतम ईमेल को पुराना बनाए रख सकता है → एक सीमित सेट की अनुमति दें और किसी एक के सफल होने के बाद ही सभी सिबलिंग को रद्द करें।
• Host से URL बनाना → एक दूषित अनुरोध हमलावर-नियंत्रित रीसेट डोमेन भेज सकता है → एक कॉन्फ़िगर किए गए या अनुमति सूची वाले HTTPS ऑरिजिन का उपयोग करें।
• लॉग या एनालिटिक्स में टोकन डालना → ऑब्ज़र्वेबिलिटी सिस्टम क्रेडेंशियल स्टोर बन जाते हैं → क्वेरी स्ट्रिंग्स को रिडैक्ट करें और रीसेट पेज पर तीसरे पक्ष के संसाधनों को प्रतिबंधित करें।
• सत्र नीति के बिना रीसेट के बाद ऑटो-लॉगिन → सत्र निर्धारण और चोरी हुए सत्र का व्यवहार अस्पष्ट हो जाता है → सामान्य लॉगिन की आवश्यकता रखें और सर्वर-साइड सत्रों को स्पष्ट रूप से रद्द करें।
• पासवर्ड के साथ MFA को रीसेट करना → एक ईमेल का नियंत्रण एक मजबूत कारक को हरा सकता है → MFA रिकवरी को एक अलग जोखिम-आधारित फ़्लो के रूप में रखें।
• ईमेल द्वारा एक नया पासवर्ड भेजना → पासवर्ड एक असुरक्षित चैनल में बना रहता है और एक हमलावर पीड़ित को लॉक आउट कर सकता है → एक समय-सीमित लिंक भेजें और मान्य प्रमाण प्रस्तुत होने तक कुछ भी न बदलें।

अनुवर्ती प्रश्न और उत्तर

अनुवर्ती 1: यदि उत्पाद स्टेटलेस JWT एक्सेस टोकन का उपयोग करता है तो क्या बदलता है?

सर्वर पर रिफ़्रेश टोकन रद्द करें। तत्काल एक्सेस-टोकन अमान्यकरण के लिए, एक प्रमाणीकरण संस्करण या जारी किए गए समय (issued-at) का मान शामिल करें और प्रत्येक संरक्षित अनुरोध पर वर्तमान सर्वर स्थिति के साथ इसकी तुलना करें। यदि आर्किटेक्चर उस लुकअप या निरस्तीकरण कैश से इनकार करता है, तो पुराने एक्सेस टोकन समाप्ति तक मान्य रहते हैं; तत्काल लॉगआउट का वादा करने के बजाय अधिकतम एक्सपोज़र बताएं।

अनुवर्ती 2: क्या एक नए अनुरोध को पिछले प्रत्येक रीसेट लिंक को अमान्य कर देना चाहिए?

आमतौर पर सफलता से पहले नहीं। ईमेल में देरी हो सकती है या क्रम बदल सकता है, और जो हमलावर पता जानता है वह पीड़ित के नवीनतम लिंक को लगातार अमान्य कर सकता है। गैर-समाप्त टोकन का एक छोटा सीमित सेट रखें, अनुरोध मात्रा को नियंत्रित करें, और सफल पासवर्ड-परिवर्तन ट्रांज़ैक्शन में प्रत्येक सिबलिंग को रद्द करें। एक उच्च-जोखिम वाला उत्पाद सख्त प्रतिस्थापन चुन सकता है, लेकिन उसे उस उपलब्धता के समझौते (trade-off) को स्वीकार करना होगा।

अनुवर्ती 3: आप URL टोकन के बजाय छह अंकों के कोड का समर्थन कैसे करेंगे?

छह अंकों के कोड में 256-बिट टोकन की तुलना में बहुत कम एन्ट्रापी होती है। इसे खाते और एक संकीर्ण रूप से सीमित रीसेट प्रयास से बांधें, सर्वर-साइड प्रयास थ्रॉटलिंग और समाप्ति लागू करें, और सफल सत्यापन के बाद ही एक अल्पकालिक रीसेट सत्र बनाएं। किसी सत्यापित कोड को सामान्य प्रमाणित सत्र न बनने दें या क्लाइंट को उपयोगकर्ता ID चुनने की अनुमति न दें।

अनुवर्ती 4: आप कौन से नए-पासवर्ड नियम लागू करेंगे?

साइन-इन के समान सत्यापनकर्ता नीति का उपयोग करें। यदि उत्पाद वर्तमान NIST मार्गदर्शन को अपनाता है, तो एकल कारक के रूप में उपयोग किए जाने वाले पासवर्ड में 15-वर्ण का न्यूनतम होना चाहिए; केवल MFA के भीतर उपयोग किए जाने वाले में 8-वर्ण का न्यूनतम हो सकता है। कम से कम 64 वर्णों की अनुमति दें, एक ब्लॉकलिस्ट के साथ सामान्य या समझौता किए गए मानों को अस्वीकार करें, और मनमाने संरचना या आवधिक-रोटेशन नियम न जोड़ें। पासवर्ड-हैश लागत को इन इनपुट नियमों से अलग से ट्यून करें।

अनुवर्ती 5: क्या होगा यदि उपयोगकर्ता ने ईमेल और MFA दोनों तक पहुंच खो दी है?

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

अनुवर्ती 6: आप कैसे सत्यापित करते हैं कि खाता एन्यूमरेशन वास्तव में नियंत्रित है?

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