दो चरण अनिवार्य रूप से दो कारक नहीं हैं: पासवर्ड और PIN दोनों ज्ञान हैं। बायोमेट्रिक्स ऑथेंटिकेटर सक्रिय कर सकते हैं, लेकिन अकेले गुमनामी या फ़िशिंग प्रतिरोध की गारंटी नहीं देते।
स्क्रीन की संख्या नहीं, तंत्र तुलना करें
NIST ज्ञान, स्वामित्व और जैविक विशेषताओं में अंतर करता है। हाथ से दर्ज एकबारगी कोड नकली साइट से आगे भेजा जा सकता है; SMS और TOTP फ़िशिंग-प्रतिरोधी प्रमाणीकरण के समान नहीं हैं। सही लागू पासकी प्रतिक्रिया को सेवा से बाँधती है। सुरक्षा स्थानीय सत्यापन तथा बैकअप या सिंक्रोनाइज़ेशन की शर्तों पर भी निर्भर करती है।
बायोमेट्रिक्स की भूमिका समझें
WebAuthn में जैविक पहचान ऑथेंटिकेटर के भीतर हो सकती है; बायोमेट्रिक डेटा प्राप्तकर्ता वेब सेवा को नहीं भेजा जाता। स्थानीय सत्यापन PIN भी इस्तेमाल कर सकता है। उपयोगकर्ता की उपस्थिति (UP) और सत्यापन (UV) अलग हैं। सर्वर को प्रोटोकॉल के अनुसार प्रतिक्रिया जाँचनी होती है; चेहरा पहचानने वाली स्क्रीन पर्याप्त नहीं है।
पूरा जीवनचक्र सुरक्षित रखें
नामांकन, नया तरीका जोड़ना, उपकरण खोना, निरस्तीकरण और खाता वापसी की योजना बनाएं। सुलभता और वैकल्पिक तरीकों की जाँच करें; वे मुख्य प्रवेश को कमजोर कर सकते हैं। प्रमाणीकरण डेटा और कार्यों की अनुमति का विकल्प नहीं है।
स्रोत
संपादकीय जाँच: 1 नवंबर 2026।
दूसरे फैक्टर को फ़िशिंग रेजिस्टेंस से अलग करें।
NIST नोट करता है कि हाथ से डाला गया एक बार का कोड किसी धोखेबाज़ पेज से भेजा जा सकता है, इसलिए सिर्फ़ उसकी मौजूदगी से साइन-इन फ़िशिंग-रेजिस्टेंट नहीं हो जाता। ठीक से इंटीग्रेटेड WebAuthn जवाब को असली सर्विस से जोड़ता है। अकाउंट रिकवरी सुरक्षित रहने का एक रास्ता है।
- उन एप्लिकेशन की लिस्ट बनाएं जो अभी भी SMS, कोड या बायपास करने लायक अप्रूवल ले रहे हैं और खास अकाउंट को प्राथमिकता दें।
- असली यूज़र जर्नी के ज़रिए एनरोलमेंट, डिवाइस लॉस और रिवोकेशन को टेस्ट करें।
- रेजिस्टेंट-फैक्टर कवरेज को मापें और मालिकों के पास डेटेड एक्सेप्शन रखें।
प्राथमिक स्रोत: NIST SP 800-63B-4. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
पासकी: डोमेन और RP ID बदलने की तैयारी
खाते, वेब ओरिजिन और RP ID को अलग रखें ताकि क्रेडेंशियल चुपचाप फिर न बाँधे जाएँ।
- पुराने तथा नए ओरिजिन, RP ID और जुड़े खाते लिखें। वही खाता नाम किसी पासकी को दूसरे RP ID के लिए वैध नहीं बनाता। WebAuthn के अनुमत संयोजन और बदलाव के दौरान उपलब्ध प्रवेश मार्ग जाँचें।
- अधिकृत परीक्षण वातावरण में उपयुक्त लाइब्रेरी से चैलेंज, ओरिजिन, RP ID और खाते का जुड़ाव जाँचें। अप्रत्याशित ओरिजिन और दोहराया चैलेंज आजमाएँ। RP ID बदले तो प्रमाणित नया पंजीकरण तैयार करें; डेटाबेस की पंक्ति कॉपी करना कुंजी का स्थानांतरण नहीं है।
- केवल पुराना क्रेडेंशियल रखने वाला उपयोगकर्ता, बहाली और खुले सत्र जाँचें। जाँची वापसी के साथ मार्ग खोलने और हटाने का क्रम तय करें। नए डोमेन पर पंजीकरण सफल होना सभी पुराने सत्रों का निरस्तीकरण साबित नहीं करता।
दोहराने योग्य स्वीकृति मामला
काल्पनिक उदाहरण: डेटा किसी ग्राहक या देखे गए परिणाम का नहीं है।
मामले के इनपुट देखें
{
"old_origin": "https://login.old.example",
"old_rp_id": "old.example",
"new_origin": "https://login.new.example",
"new_rp_id": "new.example",
"same_service_account": true,
"expected": "authenticated_new_registration"
}अपेक्षित निर्णय
काल्पनिक उदाहरण: खाता वही है, लेकिन old.example से अलग RP ID वाला new.example होता है। पुराने क्रेडेंशियल को चुपचाप नहीं बाँध सकते; नया पंजीकरण नियोजित प्रमाणित मार्ग से होना चाहिए।
क्या डेटाबेस संपादन पासकी का RP ID बदल सकता है?
नहीं। RP ID क्रेडेंशियल के सत्यापित दायरे का हिस्सा है। नए दायरे में वैध पंजीकरण और प्रमाणित खाता मिलान तैयार करें।
प्राथमिक स्रोत: W3C — Web Authentication Level 2. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
postMessage: स्रोत, विंडो और आदेश सत्यापित करें
iframe या पॉपअप संदेश अनुबंध से अनपेक्षित प्रेषक और डेटा अस्वीकार करें।
- सटीक स्वीकृत origin, अपेक्षित विंडो संदर्भ और जरूरी संदेश प्रकार लिखें। संवेदनशील डेटा के लिए स्पष्ट targetOrigin दें। origin में प्रोटोकॉल, होस्ट और पोर्ट होते हैं; डोमेन के हिस्से की खोज प्रेषक सत्यापित नहीं करती।
- event.origin और इस एकीकरण में event.source को अपेक्षित विंडो से मिलाएँ। संरचना, अनुमत मान और कार्य स्थिति जाँचें। eval या HTML डालने के बिना डेटा समझें। स्वीकृत origin सर्वर अनुमति जाँच का विकल्प नहीं है।
- मिलता डोमेन, अलग पोर्ट, समान origin की दूसरी विंडो, गलत फ़ील्ड और बंद होने के बाद संदेश जाँचें। अनावश्यक लिसनर हटाएँ और पूरे आदान-प्रदान निष्क्रिय करें। विंडो बदलने पर भी उत्तर पहले स्वीकृत origin पर ही दें।
दोहराने योग्य स्वीकृति मामला
काल्पनिक उदाहरण: डेटा किसी ग्राहक या देखे गए परिणाम का नहीं है।
मामले के इनपुट देखें
{
"allowed_origin": "https://widget.example",
"observed_origin": "https://widget.example",
"expected_window": "active_iframe",
"observed_window": "another_window",
"payload_schema_valid": true,
"expected": "reject_without_effect"
}अपेक्षित निर्णय
काल्पनिक उदाहरण: https://widget.example स्वीकृत है, पर event.source दूसरी विंडो है। अनुबंध सक्रिय iframe माँगता है; आदेश दिए बिना संदेश अस्वीकार करें।
प्राथमिक स्रोत: MDN — Window.postMessage. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
पहचान: कारक, सत्र और पुनर्प्राप्ति
दो कारक: इंटरफ़ेस के साथ प्रोटोकॉल भी जाँचें
दर्ज कोड, push स्वीकृति और WebAuthn प्रतिक्रिया सेवा से अलग तरह जुड़ते हैं। बायोमेट्रिक्स ऑथेंटिकेटर सक्रिय कर सकते हैं, प्रतिक्रिया की क्रिप्टोग्राफ़िक जाँच का विकल्प नहीं हैं।
- स्थानीय सक्रियण — उपकरण के अनुसार PIN या बायोमेट्रिक्स।
- प्रतिक्रिया पर हस्ताक्षर — सेवा की कुंजी और प्राप्त चुनौती।
- सर्वर पर सत्यापन — चुनौती, ओरिजिन, हस्ताक्षर और फ़्लैग।
- कार्रवाई की अनुमति — ऑब्जेक्ट और कार्य के अधिकार।
- UP और UV अलग देखें।
- जरूरी सिंक्रोनाइज़ेशन और निर्यात-निषेध की शर्तें जाँचें।
- मौजूदा सत्र से उपकरण खोने और नया तरीका जोड़ने का अभ्यास करें।
पहचान नियंत्रण विस्तार से देखें →
स्रोत जाँच की तारीख · NIST SP 800-63B-4 · final publication NIST · Authenticator Event Management W3C · WebAuthn Level 3
एक्सटेंशन: अनुमतियाँ और पहुँच
इस संस्करण में विस्तृत संदर्भ टिप्पणियाँ अंग्रेज़ी में उपलब्ध हैं।
Robust authentication does not describe extension access
Phishing resistance does not remove the need to examine what runs in the browser after a session opens. A manifest provides clues about cookies, scripting, debugging and identity without establishing collection.
- Test approved extensions in a profile dedicated to sensitive operations.
- For identity, inspect OAuth scopes and recipients; this permission does not enumerate identity-provider rights.
- Distinguish session revocation, token revocation, extension disablement and native-component removal.
Read the permission directory and manifest examples →
Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent