पासकी सुरक्षित क्यों हैं — «रहस्य न भेजने वाले प्रमाणीकरण» का चित्रित तंत्र

«फिर किसी बड़ी सेवा से पासवर्ड लीक हुए» समाचार अब किसी को आश्चर्य नहीं देते। फ़िशिंग प्रशिक्षण हर वर्ष करें, फँसने वाले शून्य नहीं होते। «पासवर्ड दोहराएँ नहीं, लंबे करें, आवधिक बदलाव… अब नहीं चाहिए» — सलाह भी दो-तीन बार पलटी।

पिछले कुछ वर्षों में तेज़ी से फैली पासकी (passkey) इस स्थिति का उत्तर मानकर Apple, Google, Microsoft तीनों मिलकर आगे बढ़ा रहे प्रमाणीकरण तरीका है।¹ «उंगली या चेहरे से लॉगिन, सुविधाजनक» परिचय अधिक है, पर सार वहाँ नहीं। पासकी का असली मूल्य सुरक्षा का आधार «मानव सतर्कता» से «प्रोटोकॉल की संरचना» पर ले जाना है।

• पासवर्ड लीक उपयोगकर्ता की लापरवाही से, शिक्षा दें → मनुष्य अवश्य गलती करता है
• नकली साइट पहचानने का प्रशिक्षण दें → न पहचानी जा सकने वाली नकली साइट बनाई जा सकती है
• पासकी हो तो → भेजने का रहस्य ही नहीं, नकली साइट पर हस्ताक्षर बनता ही नहीं

यह लेख पासकी सुरक्षित क्यों हैं, पासवर्ड में क्या टूटा है वहाँ से चित्रों से पकड़ता है। फिर «सिंक होती पासकी सच में सुरक्षित हैं?», «कमज़ोरी नहीं?» जैसे स्वाभाविक प्रश्नों का सीधा उत्तर देता है, अंत में वेब ऐप और Windows वातावरण में लागू करने के व्यावहारिक बिंदु व्यवस्थित करता है।

1. निष्कर्ष पहले

पासकी सुरक्षित होने के कारण तीन में सिमटते हैं।

1. सर्वर पर रहस्य मौजूद नहीं। सर्वर संग्रहीत केवल सार्वजनिक कुंजी — लीक हो तो भी दुरुपयोग न हो सकने वाली जानकारी। डेटाबेस पूरा बहे तो भी हमलावर «प्रतिरूपण की सामग्री» घर नहीं ले जाता।²
2. रहस्य नेटवर्क पर नहीं बहता। लॉगिन पर भेजा जाता एकबारगी यादृच्छिक संख्या (चैलेंज) पर हस्ताक्षर मात्र। निजी कुंजी डिवाइस के प्रमाणक से बिलकुल नहीं निकलती, इसलिए पथ कहीं भी सुनें-रिले करें रहस्य हाथ नहीं आता।²
3. नकली साइट पर हस्ताक्षर बनता नहीं। पासकी साइट के डोमेन से बँधी है, ब्राउज़र डोमेन मिलान बाध्य करता है। उपयोगकर्ता नकली साइट से धोखा खाए तो भी असली साइट की पासकी उम्मीदवार में नहीं आती, हस्ताक्षर रिले भी करें तो जाँच गिरती है।³

ये तीन स्वतंत्र तरकीब नहीं, «रहस्य साझा कर भेजने» वाले प्रमाणीकरण से «रहस्य रखना हस्ताक्षर से सिद्ध करने» वाले प्रमाणीकरण एक डिज़ाइन बदलाव से निकले सब परिणाम हैं। क्रम से देखते हैं।

शब्दों का संबंध — पासकी, WebAuthn, FIDO2, CTAP

इस क्षेत्र में शब्द बहुत हैं, लेख से लेख दायरा बदलता है, इसलिए पहले संबंध बाँधें। पासकी नया प्रोटोकॉल नहीं, मौजूदा मानकों के संयोजन पर लगा «नाम» है।²¹

तालिका 1: पासकी FIDO2 आधार पर लगा नाम है, मानक का नाम नहीं

यानी «पासकी समर्थन» कार्यान्वयन की भाषा में «WebAuthn लागू करना» है। CTAP बाहरी प्रमाणक उपयोग पर ब्राउज़र और OS सँभालते हैं, वेब ऐप बनाने वाला सीधे नहीं छूता।

इस लेख का ज्ञान मानचित्र

पासकी WebAuthn और CTAP (मिलाकर FIDO2) मानकों पर बनी सार्वजनिक-कुंजी क्रिप्टोग्राफ़ी आधारित क्रेडेंशियल है; निजी कुंजी प्रमाणक से नहीं निकलती, सर्वर को लीक हो तो भी दुरुपयोग न हो सकने वाली सार्वजनिक कुंजी मात्र सौंपी जाती है। पासकी साइट के डोमेन (RP ID) से बाँधकर बनती है, इसलिए नकली साइट पर हस्ताक्षर बनता ही नहीं और फ़िशिंग संरचनात्मक रूप से रुकती है। सिंक प्रकार पासकी क्लाउड खाते पर निर्भरता के बदले खोने का प्रतिरोध पाती है, डिवाइस-बद्ध प्रकार कुंजी हार्डवेयर में बंद रखती है। पासकी लागू करने के बाद व्यावहारिक केंद्र साथ बचे फ़ॉलबैक साधन घटाना और खाता पुनर्प्राप्ति प्रवाह मज़बूत करना बनता है।

flowchart LR
    accTitle: पासकी सुरक्षित क्यों हैं का ज्ञान मानचित्र
    accDescr: पासकी WebAuthn, FIDO2, CTAP और सार्वजनिक-कुंजी क्रिप्टोग्राफ़ी पर बनी हैं; RP ID से डोमेन बाँधना फ़िशिंग संरचनात्मक रूप से रोकता है; सिंक प्रकार और डिवाइस-बद्ध प्रकार का अंतर तथा प्रत्येक का एकल विफलता बिंदु; फ़िशिंग-प्रतिरोधी MFA के रूप में स्थान; बचे जोखिम (फ़ॉलबैक, खाता पुनर्प्राप्ति, सत्र चोरी) का संबंध दर्शाने वाला चित्र
    passkey["पासकी"]
    webauthn["WebAuthn"]
    fido2["FIDO2"]
    public_key_cryptography["सार्वजनिक-कुंजी क्रिप्टोग्राफ़ी"]
    ctap["CTAP"]
    authenticator["प्रमाणक"]
    tpm["TPM"]
    windows_hello["Windows Hello"]
    fido2_security_key["सुरक्षा कुंजी"]
    device_bound_passkey["डिवाइस-बद्ध पासकी"]
    webauthn_secure_context["सुरक्षित संदर्भ आवश्यकता (HTTPS)"]
    webauthn_challenge["चैलेंज (एकबारगी यादृच्छिक संख्या)"]
    rp_id["RP ID (Relying Party पहचानकर्ता)"]
    phishing["फ़िशिंग"]
    aitm_phishing["AiTM (मध्यस्थ) प्रकार फ़िशिंग"]
    credential_database_breach["प्रमाणीकरण जानकारी डेटाबेस लीक"]
    password_authentication["पासवर्ड प्रमाणीकरण"]
    password_reuse["पासवर्ड दोहराना (सूची-प्रकार हमला)"]
    account_takeover["खाता अधिग्रहण"]
    session_cookie_theft["सत्र कुकी चोरी"]
    totp["वन-टाइम पासवर्ड (TOTP)"]
    phishing_resistant_mfa["फ़िशिंग-प्रतिरोधी MFA"]
    entra_id["Microsoft Entra ID"]
    synced_passkey["सिंक प्रकार पासकी"]
    platform_credential_vault["प्लेटफ़ॉर्म क्रेडेंशियल तिजोरी"]
    nist_aal3["NIST AAL3 (प्रमाणक आश्वासन स्तर 3)"]
    platform_account_hardening["प्लेटफ़ॉर्म खाते की सुरक्षा मज़बूत करना"]
    account_recovery_abuse["खाता पुनर्प्राप्ति प्रवाह का दुरुपयोग"]
    account_recovery_hardening["पुनर्प्राप्ति प्रवाह की पहचान पुष्टि मज़बूत करना"]
    fallback_credential["साथ बचा फ़ॉलबैक प्रमाणीकरण साधन"]
    fallback_retirement["फ़ॉलबैक साधन का नियोजित घटाना"]
    passkey -->|"उपयोग करता है"| webauthn
    passkey -->|"उपयोग करता है"| fido2
    passkey -->|"उपयोग करता है"| public_key_cryptography
    fido2 -->|"उपयोग करता है"| webauthn
    fido2 -->|"उपयोग करता है"| ctap
    passkey -->|"उपयोग करता है"| authenticator
    authenticator -.->|"उपयोग करता है"| tpm
    windows_hello -.->|"उपयोग करता है"| tpm
    passkey -.->|"उपयोग करता है"| windows_hello
    passkey -.->|"उपयोग करता है"| fido2_security_key
    device_bound_passkey -->|"उपयोग करता है"| authenticator
    webauthn -->|"अपेक्षित"| webauthn_secure_context
    webauthn -->|"उपयोग करता है"| webauthn_challenge
    passkey -->|"अपेक्षित"| rp_id
    rp_id -->|"रोकता है"| phishing
    passkey -->|"रोकता है"| phishing
    passkey -->|"रोकता है"| aitm_phishing
    public_key_cryptography -->|"कम करता है"| credential_database_breach
    password_authentication -.->|"कारण बन सकता"| credential_database_breach
    password_authentication -.->|"कारण बन सकता"| phishing
    password_authentication -.->|"कारण बन सकता"| password_reuse
    password_reuse -.->|"कारण बन सकता"| account_takeover
    aitm_phishing -.->|"कारण बन सकता"| session_cookie_theft
    totp -->|"अनुशंसित नहीं"| phishing_resistant_mfa
    passkey -->|"अनुशंसित उपाय"| phishing_resistant_mfa
    entra_id -.->|"उपयोग करता है"| passkey
    passkey -.->|"से कॉन्फ़िगर"| entra_id
    synced_passkey -->|"में संग्रहीत"| platform_credential_vault
    synced_passkey -->|"असंगत"| nist_aal3
    device_bound_passkey -.->|"अनुशंसित उपाय"| nist_aal3
    platform_credential_vault -.->|"कारण बन सकता"| account_takeover
    platform_account_hardening -->|"अनुशंसित उपाय"| account_takeover
    account_recovery_abuse -.->|"कारण बन सकता"| account_takeover
    account_recovery_hardening -->|"अनुशंसित उपाय"| account_recovery_abuse
    fallback_credential -.->|"कारण बन सकता"| account_takeover
    fallback_retirement -->|"अनुशंसित उपाय"| fallback_credential
    session_cookie_theft -->|"कारण बन सकता"| account_takeover
    passkey -->|"अनुशंसित नहीं"| session_cookie_theft

चित्र में ठोस रेखा हमेशा सत्य रहने वाला संबंध दर्शाती है और धराशायी रेखा सशर्त संबंध दर्शाती है (शर्तें विस्तृत पृष्ठ पर प्रत्येक संबंध के स्पष्टीकरण में दी गई हैं)। संबंधों की पूरी सूची (कुल 38, साक्ष्य और निश्चितता सहित) तथा मुख्य अवधारणाओं की परिभाषाएँ ज्ञान मानचित्र के विस्तृत पृष्ठ पर संकलित हैं (जापानी में)। डेटा: JSON-LD / Turtle

2. पासवर्ड प्रमाणीकरण में क्या टूटा है

पासकी की सुरक्षा समझने का छोटा रास्ता पासवर्ड की कमजोरी «स्थान» से पकड़ना है। पासवर्ड प्रमाणीकरण में रहस्य स्वयं हर प्रमाणीकरण पर पूरा पथ यात्रा करता है।

sequenceDiagram
    participant U as उपयोगकर्ता
    participant B as ब्राउज़र
    participant S as सर्वर
    Note over U: रहस्य (पासवर्ड) सिर में रखता है<br/>【कमजोरी ①】अनुमान / साइटों पर दोहराया जाता है
    U->>B: पासवर्ड डालता है
    Note over B: 【कमजोरी ②】नकली साइट पर भी वैसे ही<br/>डाल सकते हैं (दिखावट से भेद नहीं)
    B->>S: पासवर्ड स्वयं भेजता है
    Note over B,S: 【कमजोरी ③】रहस्य पथ पर बहता है<br/>TLS से बचा पर अंत पर सादा पाठ लौटता है
    S->>S: संग्रहीत हैश से मिलाता है
    Note over S: 【कमजोरी ④】सब उपयोगकर्ताओं का रहस्य (हैश) एकत्र<br/>लीक हो तो ऑफ़लाइन ब्रूट-फोर्स का निशाना

चित्र 1: पासवर्ड प्रमाणीकरण में रहस्य स्वयं पूरे पथ पर मौजूद है

हमलावर की दृष्टि से यह निशाने बहुत, मार आसान संरचना है।

• कमजोरी ① (उपयोगकर्ता): याद रखने योग्य सामर्थ्य ही, कई साइटों पर दोहराया जाता है। एक स्थान का लीक सब खातों तक फैलता है (पासवर्ड-सूची हमला)।
• कमजोरी ② (डालने का क्षण): असली से अभिन्न नकली साइट बनाएँ तो उपयोगकर्ता स्वयं रहस्य सौंप देता है (फ़िशिंग)।
• कमजोरी ③ (पथ): TLS से पथ स्वयं सुनना कठिन, पर «वैध दिखने वाला रिले बिंदु» बीच में आ जाए तो अर्थ नहीं (बाद का AiTM)।
• कमजोरी ④ (सर्वर): हैश कर रखें, डेटाबेस बहे तो ऑफ़लाइन ब्रूट-फोर्स। कमज़ोर पासवर्ड से क्रम से टूटते हैं।

«तो वन-टाइम कोड (SMS या TOTP) जोड़ दें» पारंपरिक बहु-कारक प्रमाणीकरण है, पर साझा रहस्य भेजने की संरचना नहीं बदलती। TOTP में सर्वर और प्रमाणीकरण ऐप एक ही सीड (रहस्य) साझा करते हैं, बने 6 अंक उपयोगकर्ता नकली साइट में डाल सकता है। वास्तव में नकली साइट असली सर्वर को रीयल-टाइम रिले करने वाला AiTM (Adversary-in-the-Middle) फ़िशिंग पासवर्ड+वन-टाइम कोड जोड़ी यों ही आगे भेजकर तोड़ता है। CISA (अमेरिकी साइबर सुरक्षा एजेंसी) «फ़िशिंग-प्रतिरोधी MFA» में FIDO/WebAuthn और स्मार्ट कार्ड (PIV/CAC) जैसे PKI-आधारित प्रमाणीकरण दो ही गिनाती है, उनमें FIDO को स्वर्ण मानक रखती है — यही कारण।⁴

यानी समस्या पासवर्ड की «सामर्थ्य» नहीं, «रहस्य साझा कर हर प्रमाणीकरण पर भेजना» संरचना स्वयं है।

3. पासकी का असली रूप — रहस्य न भेजकर रखना सिद्ध करना

पासकी W3C के WebAuthn और FIDO Alliance के CTAP दो मानकों (मिलाकर FIDO2) पर बनी सार्वजनिक-कुंजी क्रिप्टोग्राफ़ी आधारित क्रेडेंशियल है।²¹ कठिन लगता है, संरचना सरल है।

flowchart LR
    subgraph DEV["उपयोगकर्ता का डिवाइस"]
        AUTH["प्रमाणक (तिजोरी)<br/>Windows Hello / Face ID /<br/>Android स्क्रीन लॉक / सुरक्षा कुंजी"]
        SK["निजी कुंजी<br/>यहाँ से बिलकुल नहीं निकलती"]
        BIO["उंगली · चेहरा · PIN<br/>= तिजोरी का द्वार खोलना मात्र<br/>यह भी बाहर नहीं जाता"]
        AUTH --- SK
        BIO -->|"स्थानीय मिलान"| AUTH
    end
    subgraph SRV["सर्वर"]
        PK["सार्वजनिक कुंजी<br/>लीक हो तो भी दुरुपयोग नहीं<br/>«केवल जाँच» की जानकारी"]
    end
    SK -.->|"गणितीय युग्म<br/>(हस्ताक्षर बनाने वाला पक्ष)"| PK

चित्र 2: पासकी का पदार्थ साइट-दर कुंजी युग्म। रहस्य पक्ष डिवाइस से नहीं निकलता, सर्वर के पास केवल जाँच की सार्वजनिक कुंजी

• निजी कुंजी हस्ताक्षर बनाने वाला पक्ष, डिवाइस के प्रमाणक (Windows Hello, iPhone Face ID/Touch ID, Android स्क्रीन लॉक, या YubiKey जैसी सुरक्षा कुंजी) में संग्रहीत, बाहर नहीं जाती।
• सार्वजनिक कुंजी हस्ताक्षर जाँचने वाला पक्ष, इसे सर्वर पर सौंपते हैं। सार्वजनिक कुंजी से निजी कुंजी उलटी गणना संगणनात्मक रूप से असंभव, इसलिए लीक हो तो चले।
• उंगली-चेहरा आदि बायोमेट्रिक जानकारी तिजोरी का द्वार स्थानीय खोलने के लिए ही, यह भी डिवाइस से नहीं निकलती। सर्वर को बायोमेट्रिक नहीं भेजी जाती।¹

पंजीकरण: सार्वजनिक कुंजी «मात्र» सौंपना

साइट पर पासकी पंजीकृत करते प्रवाह।

sequenceDiagram
    participant S as सर्वर (example.com)
    participant B as ब्राउज़र
    participant A as प्रमाणक
    S->>B: पंजीकरण अनुरोध (यादृच्छिक चैलेंज + साइट जानकारी)
    B->>A: इस साइट (example.com) की कुंजी बनाओ
    A->>A: उंगली · चेहरा · PIN से पहचान (स्थानीय)
    A->>A: नया कुंजी युग्म उत्पन्न<br/>निजी कुंजी भीतर संग्रहीत
    A->>B: सार्वजनिक कुंजी + credential ID (कुंजी का नामपट्ट)
    B->>S: सार्वजनिक कुंजी + credential ID भेजता है
    S->>S: इस खाते की सार्वजनिक कुंजी के रूप में सहेजता है
    Note over S: सर्वर को मिला<br/>«लीक हो तो भी दुरुपयोग न हो सकने वाली जानकारी» मात्र

चित्र 3: पंजीकरण पर नेटवर्क बहता और सर्वर संग्रहीत केवल सार्वजनिक कुंजी

महत्वपूर्ण: इस समय कुंजी युग्म साइट के डोमेन (RP ID) से बाँधकर बनता है। example.com के लिए बनी पासकी example.com साइट पर ही चलती है (RP ID डोमेन इकाई है, इसलिए login.example.com जैसे उसी डोमेन के सबडोमेन पृष्ठ से चलती है, असंबंधित डोमेन से नहीं)। यही बंधन बाद की फ़िशिंग प्रतिरोध का आधार है।³

साथ कुंजी युग्म साइट-दर हर बार नया बनता है। साइट A और साइट B की पासकी गणितीय रूप से असंबंधित, इसलिए «दोहराना» अवधारणा ही नहीं, साइटों के बीच उपयोगकर्ता मिलाने की सामग्री भी नहीं।

प्रमाणीकरण: एकबारगी हस्ताक्षर लौटाना

लॉगिन का प्रवाह। पासवर्ड प्रमाणीकरण (चित्र 1) से तुलना करें।

sequenceDiagram
    participant S as सर्वर (example.com)
    participant B as ब्राउज़र
    participant A as प्रमाणक
    S->>B: लॉगिन अनुरोध (एकबारगी यादृच्छिक चैलेंज)
    B->>A: example.com पर हस्ताक्षर अनुरोध
    A->>A: उंगली · चेहरा · PIN से पहचान (स्थानीय)
    A->>A: निजी कुंजी से हस्ताक्षर बनाता है<br/>चैलेंज + ओरिजिन + RP ID हैश शामिल करता है
    A->>B: हस्ताक्षर (निजी कुंजी स्वयं नहीं)
    B->>S: हस्ताक्षर भेजता है
    S->>S: संग्रहीत सार्वजनिक कुंजी से हस्ताक्षर जाँचता है<br/>चैलेंज · ओरिजिन · RP ID भी पुष्टि
    Note over B,S: पथ पर बहता एकबारगी हस्ताक्षर मात्र<br/>चोरी करें तो अगले चैलेंज पर काम नहीं

चित्र 4: प्रमाणीकरण पर भी रहस्य नहीं चलता। बहता «एकबारगी प्रमाण पत्र» मात्र

सर्वर हर बार नया यादृच्छिक संख्या (चैलेंज) देता है, प्रमाणक «उस चैलेंज + अभी ब्राउज़र देख रहा ओरिजिन + RP ID हैश» पर हस्ताक्षर करता है। सर्वर संग्रहीत सार्वजनिक कुंजी से हस्ताक्षर जाँचता है, चैलेंज अपना दिया हुआ है, ओरिजिन और RP ID अपनी साइट के हैं, पुष्टि करता है।⁵

इस डिज़ाइन के फलस्वरूप आरंभ के तीन कारणों में से दो पहले से पूरे हैं।

• सर्वर पर रहस्य नहीं: संग्रहीत केवल सार्वजनिक कुंजी। बहे तो हमलावर हस्ताक्षर नहीं बना सकता, पासवर्ड हैश जैसा «घर ले जाकर तोड़ना» नहीं।
• रहस्य नहीं बहता: पथ का हस्ताक्षर चुराएँ, चैलेंज एकबारगी इसलिए पुनः उपयोग (रिप्ले) नहीं।

बचा एक, «नकली साइट पर हस्ताक्षर नहीं बनता» पासकी की सबसे बड़ी बिक्री है। अलग अनुच्छेद में देखते हैं।

4. फ़िशिंग «संरचनात्मक रूप से» न बनने का कारण

पासवर्ड पर फ़िशिंग सफल इसलिए है कि असली रहस्य नकली साइट में डाला जा सकता है। मनुष्य example.com और examp1e.com भेद (थके तो विशेषकर) नहीं करता, पर पासवर्ड क्षेत्र दोनों साइटों पर वैसे ही चलता है।

पासकी में यह मिलान मनुष्य नहीं ब्राउज़र यांत्रिक रूप से करता है। WebAuthn विनिर्देश पर ब्राउज़र «अभी दिख रहे ओरिजिन का डोमेन» और «पासकी का RP ID» मेल खाएँ तभी प्रमाणक बुला सकता है।³ नकली साइट पर जाने पर क्या होता है, चित्र में।

sequenceDiagram
    participant U as उपयोगकर्ता
    participant B as ब्राउज़र
    participant P as नकली साइट (examp1e.com)<br/>असली को रिले करने वाला AiTM प्रॉक्सी
    participant S as असली सर्वर (example.com)
    U->>P: दिखने में अभिन्न लॉगिन स्क्रीन पर जाता है
    P->>S: (पीछे) असली लॉगिन प्रक्रिया शुरू
    S->>P: चैलेंज
    P->>B: चैलेंज आगे भेजकर हस्ताक्षर माँगता है
    B->>B: अभी का ओरिजिन examp1e.com है<br/>example.com की पासकी उम्मीदवार नहीं बना सकता
    B--xP: हस्ताक्षर नहीं बनता (उपयोगकर्ता धोखा नहीं खा सकता)
    Note over B,S: किसी विधि से हस्ताक्षर बने तो भी,<br/>हस्ताक्षर में examp1e.com शामिल होता है इसलिए<br/>असली सर्वर की जाँच अवश्य गिरती है

चित्र 5: AiTM फ़िशिंग पासवर्ड+वन-टाइम कोड तोड़ती है, पासकी पर हस्ताक्षर चरण पर नहीं बनती

रक्षा दोहरी है, ध्यान दें।

1. उम्मीदवार में नहीं आती: ब्राउज़र ओरिजिन से मेल RP ID की पासकी ही सूचीबद्ध करता है। नकली डोमेन पर असली साइट की पासकी विकल्प में नहीं, उपयोगकर्ता «भूल से उपयोग» भी नहीं कर सकता।
2. हस्ताक्षर नहीं चलता: हस्ताक्षर लक्ष्य में ब्राउज़र द्वारा पुष्ट ओरिजिन और RP ID हैश शामिल। असली सर्वर जाँचते मिलाता है, इसलिए दूसरे ओरिजिन पर बना हस्ताक्षर अवश्य अस्वीकृत।⁵

पासवर्ड फ़िशिंग रोक «उपयोगकर्ता URL ध्यान से देखे» मानव प्रयास पर निर्भर थी। पासकी में उपयोगकर्ता को नकली साइट पहचानने की ज़रूरत ही नहीं। यही «फ़िशिंग प्रतिरोध (phishing-resistant)» शब्द का सटीक अर्थ है, CISA और NIST (अमेरिकी मानक संस्थान) FIDO/WebAuthn को विशेष रखने का कारण।⁴⁶

अब तक हमला विधि-दर व्यवस्थित करें।

तालिका 2: हमला विधि-दर प्रतिरोध तुलना। पासकी के «○» संचालन या सतर्कता नहीं, संरचना से आते हैं

5. «सिंक होती पासकी» सुरक्षित हैं?

अब तक पढ़कर स्वाभाविक प्रश्न: «निजी कुंजी डिवाइस से नहीं निकलती कहा, तो iPhone पर बनी पासकी iPad पर क्यों चलती है» — अच्छा प्रश्न, उत्तर «पासकी दो प्रकार की हैं»।

पहले निष्कर्ष की त्वरित तालिका। यह अनुच्छेद और अगला, तालिका की प्रत्येक पंक्ति क्यों ऐसी है, समझाने वाले हैं।

तालिका 3: सिंक प्रकार और डिवाइस-बद्ध त्वरित तालिका। कौन चुनें «खोने पर मज़बूती» और «कुंजी का स्थान प्रबंधित कर सकना» में से क्या लें, उसी से तय

flowchart TB
    subgraph SYNC["सिंक प्रकार पासकी (उपभोक्ता डिफ़ॉल्ट)"]
        S1["iCloud कीचेन /<br/>Google पासवर्ड मैनेजर /<br/>1Password जैसे पासवर्ड मैनेजर"]
        S2["उसी खाते के डिवाइसों के बीच<br/>एंड-टू-एंड एन्क्रिप्ट कर सिंक<br/>प्रदाता भी सामग्री नहीं पढ़ सकता"]
        S3["लाभ: मॉडल बदलना · खोना मज़बूत<br/>सावधान: क्लाउड खाता स्वयं की रक्षा चाहिए"]
        S1 --> S2 --> S3
    end
    subgraph BOUND["डिवाइस-बद्ध पासकी"]
        B1["सुरक्षा कुंजी (YubiKey आदि) /<br/>Windows Hello /<br/>Microsoft Authenticator (Entra ID)"]
        B2["निजी कुंजी उस हार्डवेयर से<br/>भौतिक रूप से नहीं निकलती (TPM आदि से सुरक्षित)"]
        B3["लाभ: कुंजी का स्थान एक जगह स्पष्ट<br/>सावधान: खोने के लिए कई पंजीकरण अनिवार्य"]
        B1 --> B2 --> B3
    end
    SYNC ~~~ BOUND

चित्र 6: सिंक प्रकार और डिवाइस-बद्ध। दोनों «निजी कुंजी सर्वर को न भेजें» समान, रक्षा का भार केंद्र अलग

सिंक प्रकार पासकी iCloud कीचेन या Google पासवर्ड मैनेजर निजी कुंजी उसी खाते के डिवाइसों के बीच सिंक करते हैं। यहाँ महत्वपूर्ण: सिंक एंड-टू-एंड एन्क्रिप्टेड है। Apple और Google दोनों कहते हैं पासकी डिवाइस पर एन्क्रिप्ट होकर सिंक होती है, प्रदाता स्वयं सामग्री नहीं पढ़ सकता।⁷⁸ यानी «निजी कुंजी डिवाइस से नहीं निकलती» सिद्धांत सटीक रूप से «निजी कुंजी सादे पाठ में डिवाइस से नहीं निकलती» तक ढीला होकर उसके बदले मॉडल बदलना और खोना प्रतिरोध मिलता है।

यह ढील खतरा मॉडल कैसे बदलती है, स्पष्ट कहना चाहिए। बचाने का स्थान «प्रत्येक साइट का सर्वर» से «एक क्लाउड खाता» पर सिमटता है। प्रत्येक साइट के DB लीक और फ़िशिंग पर पहले जैसी मज़बूती, अब Apple ID/Google खाता स्वयं का अधिग्रहण एकल विफलता बिंदु बनता है। इसलिए पासकी सौंपे प्लेटफ़ॉर्म खाते पर सबसे मज़बूत सुरक्षा (मज़बूत स्क्रीन लॉक, पुनर्प्राप्ति साधन व्यवस्थित, संभव हो तो भौतिक सुरक्षा कुंजी) पूर्वापेक्षा है। NIST ने अप्रैल 2024 में NIST SP 800-63B का पूरक (Supplement 1: Incorporating Syncable Authenticators Into NIST SP 800-63B) निकाला, यह सिंक प्रकार पासकी (syncable authenticator) आवश्यकताएँ पूरी करे तो सरकारी मानक AAL2 (Authenticator Assurance Level 2, प्रमाणक आश्वासन स्तर 2) पूरी कर सकती है, औपचारिक रूप से। पर निजी कुंजी निर्यात हो सकती है इसलिए हार्डवेयर-पृथक वातावरण माँगने वाले AAL3 पर सिंक प्रकार न उपयोग कहता है।⁶

डिवाइस-बद्ध पासकी निजी कुंजी हार्डवेयर से न निकलने वाला प्रकार है। YubiKey जैसी सुरक्षा कुंजी प्रतिनिधि, कॉर्पोरेट में Microsoft Entra ID पासकी (Microsoft Authenticator में बनने वाली) भी डिवाइस-बद्ध है।⁹ Windows का Windows Hello TPM हो तो निजी कुंजी TPM के नीचे सुरक्षित करता है। यह «कुंजी बाहर न निकालने वाला हार्डवेयर तिजोरी» तंत्र स्वयं TPM लेख में विस्तार से समझाया आधार है।

«फ़ोन की पासकी से PC ब्राउज़र में लॉगिन» पर QR कोड स्कैन कराने पर आश्चर्य हुआ हो सकता है। वह केवल स्क्रीन संक्रमण नहीं, Bluetooth से फ़ोन और PC की भौतिक निकटता पुष्टि करने वाला हाइब्रिड तरीका (FIDO का क्रॉस-डिवाइस प्रमाणीकरण) है। दूर के हमलावर अपने PC पर लॉगिन QR कोड से किसी और से स्वीकृत कराने वाला हमला निकटता पुष्टि से काटता है।¹

6. चाँदी की गोली नहीं — कमज़ोरी «गायब» नहीं «स्थान बदलती» है

अब तक पासकी की मज़बूती बताई, ईमानदारी से कहें तो पासकी हमले मिटाती नहीं हमलावर को कमज़ोर स्थान की ओर धकेलती तकनीक है। प्रमाणीकरण का द्वार मज़बूत हो तो हमलावर कहाँ घूमता है, चित्र में।

flowchart LR
    A["हमलावर"]
    G["प्रमाणीकरण स्वयं<br/>चैलेंज हस्ताक्षर<br/>【मज़बूत】"]
    R["खाता पुनर्प्राप्ति प्रवाह<br/>«पासकी खोई» कहकर<br/>SMS या ईमेल से पुनः सेट करवाकर<br/>हमलावर की पासकी पंजीकृत करना"]
    F["साथ बचा फ़ॉलबैक<br/>पासवर्ड · SMS लॉगिन<br/>बचे तो सबसे कमज़ोर कड़ी वहाँ"]
    C["क्लाउड खाता<br/>सिंक प्रकार हो तो Apple ID /<br/>Google खाता एकल विफलता बिंदु"]
    SS["सत्र<br/>लॉगिन बाद कुकी चुराएँ तो<br/>प्रमाणीकरण विधि निरर्थक"]
    A --x G
    A --> R
    A --> F
    A --> C
    A --> SS

चित्र 7: द्वार (प्रमाणीकरण) मज़बूत हो तो हमला पुनर्प्राप्ति प्रवाह, साथ बचे साधन, क्लाउड खाता, सत्र की ओर जाता है

व्यावहारिक रूप से चार अवशिष्ट जोखिम।

1. साथ बचा फ़ॉलबैक सबसे कमज़ोर कड़ी बनता है। पासकी «भी» चलने भर दें, पासवर्ड या SMS लॉगिन बचे तो हमलावर वही उपयोग करता है। फ़िशिंग प्रतिरोध खाते पूरे पर सबसे कमज़ोर लॉगिन साधन के स्तर से सीमित। लागू करने का केंद्र पासकी जोड़ना नहीं, फ़ॉलबैक नियोजित घटाना-समाप्त करना है।
2. पुनर्प्राप्ति प्रवाह नया हमला तल बनता है। «डिवाइस खोया» झूठ बोलकर सपोर्ट या ईमेल से पुनः सेट कर हमलावर अपनी पासकी पंजीकृत कराने की चाल। वास्तव में मज़बूत प्रमाणीकरण टालकर हेल्पडेस्क धोखा सामाजिक अभियंत्रण बड़े उल्लंघन का आम साधन बन गया। प्रमाणीकरण मज़बूत किया, अब पुनर्प्राप्ति प्रवाह की पहचान कैसे डिज़ाइन करें, यही पूछा जाता है।
3. सिंक प्रकार में क्लाउड खाता एकल विफलता बिंदु। पिछले अनुच्छेद के अनुसार। पासकी सौंपे खाते की रक्षा और संगठन में «किस प्लेटफ़ॉर्म पर सिंक अनुमति» नीति तय करनी चाहिए।
4. सत्र चोरी नहीं रुकती। पासकी लॉगिन के क्षण मात्र बचाती है; लॉगिन बाद सत्र कुकी मैलवेयर या XSS से चुराई जाए तो प्रमाणीकरण विधि निरर्थक। टोकन वैधता अवधि, बाइंडिंग, डिवाइस स्वास्थ्य प्रबंधन अलग परत का काम बचता है।

यह «पासकी छोड़ दें» की बात नहीं। द्वार का ताला नया करें, खिड़की बंद करना अलग काम — यही साधारण बात। उलटा कमजोरी का स्थान स्पष्ट हो तो रक्षा संसाधन पुनर्प्राप्ति प्रवाह और सत्र प्रबंधन पर केंद्रित किए जा सकते हैं।

7. व्यावहारिक लागू — WebAuthn API और Windows वातावरण

अंत में लागू करने वाले की दृष्टि से बिंदु।

अपनी वेब सेवा पर पासकी लॉगिन लगाना

ब्राउज़र पक्ष WebAuthn API के दो फ़ंक्शन मात्र। पंजीकरण navigator.credentials.create(), प्रमाणीकरण navigator.credentials.get()।

// पंजीकरण (ब्राउज़र पक्ष)
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: challengeFromServer,   // सर्वर द्वारा उत्पन्न एकबारगी यादृच्छिक संख्या
    rp: { id: "example.com", name: "Example" },
    user: { id: userIdBytes, name: "taro@example.com", displayName: "Taro" },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }],  // ES256
    authenticatorSelection: {
      residentKey: "required",        // डिस्कवरेबल क्रेडेंशियल (= पासकी) बनाता है
      userVerification: "required",   // बायोमेट्रिक/PIN से पहचान अनिवार्य करता है
    },
  },
});
// सार्वजनिक कुंजी credential.response से, credential ID शीर्ष स्तर के
// credential.id / credential.rawId से निकालें। पंजीकरण प्रतिक्रिया भी प्रमाणीकरण की तरह
// सहेजने से पहले सर्वर पक्ष पर चैलेंज, ओरिजिन, RP ID जाँचें

मुख्य पैरामीटर का अर्थ इस प्रकार।

तालिका 4: navigator.credentials.create() के मुख्य पैरामीटर

परीक्षण वातावरण की सावधानी: WebAuthn API सुरक्षित संदर्भ में ही प्रकाशित होता है, सादे http:// से दी पृष्ठ पर navigator.credentials कॉल विफल। अपवाद http://localhost (और 127.0.0.1) — विश्वसनीय ओरिजिन माने जाते हैं, विकास मशीन पर HTTPS बिना आज़मा सकते हैं। पर RP ID ओरिजिन का प्रभावी डोमेन (या उसका पैरेंट) होना चाहिए, इसलिए localhost पर बनी पासकी उत्पादन डोमेन पर नहीं चलती। हाथ में प्रमाणक न हो तो Chrome डेवलपर टूल के «WebAuthn» टैब से आभासी प्रमाणक सक्षम कर पंजीकरण से प्रमाणीकरण तक चला सकते हैं।

// प्रमाणीकरण (ब्राउज़र पक्ष)
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: challengeFromServer,
    rpId: "example.com",
    userVerification: "required",
  },
  // लॉगिन क्षेत्र के स्वतः भरण उम्मीदवार के रूप में पासकी दिखाता है। पहले
  // PublicKeyCredential.isConditionalMediationAvailable() से समर्थन जाँचें,
  // असमर्थित ब्राउज़र पर mediation बिना सामान्य कॉल पर फ़ॉलबैक करें
  mediation: "conditional",
  // (लक्ष्य <input> पर autocomplete="username webauthn" निर्दिष्ट करना आवश्यक)
});
// assertion.response के हस्ताक्षर सर्वर पक्ष पर जाँचें

मुख्य काम सर्वर पक्ष की जाँच है। न्यूनतम ये अवश्य करें।⁵

• चैलेंज मिलान: स्वयं जारी अप्रयुक्त चैलेंज है? एकबारगी रखा (रिप्ले रोक)? आगे जारी करते ब्राउज़र सत्र (लॉगिन प्रयास) से बाँधकर सहेजें, उसी सत्र की प्रतिक्रिया को ही खपत अनुमति। यहाँ ढीला हो तो हमलावर अपने चैलेंज का हस्ताक्षर पीड़ित के ब्राउज़र से भेजकर पीड़ित को हमलावर के खाते में लॉगिन करा सकता है (लॉगिन CSRF)।
• ओरिजिन मिलान: clientDataJSON का origin अपनी साइट का वैध ओरिजिन है (फ़िशिंग रोक की कुंजी)।
• RP ID हैश मिलान: authenticatorData का rpIdHash अपनी साइट के RP ID के SHA-256 से मेल खाता है।
• समारोह प्रकार और फ़्लैग पुष्टि: clientDataJSON का type प्रमाणीकरण पर webauthn.get, पंजीकरण पर webauthn.create है? authenticatorData का UP (उपयोगकर्ता उपस्थित) फ़्लैग लगा है? उपयोगकर्ता सत्यापन (UV) माँगा तो UV फ़्लैग भी लगा है?
• हस्ताक्षर जाँच: पंजीकरण पर सहेजी सार्वजनिक कुंजी से हस्ताक्षर सही सत्यापित होता है।
• खाते से बाँधना: प्रस्तुत credential ID (और userHandle) अपने डेटाबेस से खींचकर उस क्रेडेंशियल के स्वामी को सत्र जारी कर रहे हैं? अलग डाला उपयोगकर्ता नाम बिना शर्त मानें तो सही हस्ताक्षर से दूसरे के रूप में लॉगिन का छेद बनता है।
• हस्ताक्षर काउंटर सहेजना और तुलना: authenticatorData का signCount क्रेडेंशियल-दर सहेजें, अगला मान पिछले से बढ़ा हो पुष्टि करें। पिछले से कम या बराबर (समान सहित) हो तो प्रमाणक प्रतिलिपि (क्लोन) का संकेत मानें। पर सिंक प्रकार पासकी प्रायः हमेशा 0 लौटाती हैं, इसलिए 0 से 0 अपवाद के रूप में स्वीकारें।

यह जाँच हाथ से लिखना दुर्घटना का कारण है, सिद्ध लाइब्रेरी (.NET में fido2-net-lib, Node.js में SimpleWebAuthn आदि) उपयोग करें। विनिर्देश की बारीकियाँ (CBOR पार्स, एल्गोरिदम सहमति, चैलेंज प्रबंधन) लाइब्रेरी पर छोड़ें, स्वयं चैलेंज सहेजना-रद्द, कई पासकी प्रबंधन UI, पुनर्प्राप्ति प्रवाह डिज़ाइन पर केंद्रित रहें — सही शक्ति विभाजन यही है।

Windows वातावरण · आंतरिक सिस्टम

इस साइट के पाठक — «Windows व्यावसायिक सिस्टम सँभालने वाले» — के लिए तीन बिंदु काफी।

• Windows क्लाइंट समर्थित है। Windows 11 Windows Hello को प्रमाणक मानकर पासकी बनाना-उपयोग-प्रबंधन (सेटिंग > खाते > पासकी) समर्थित करता है, निजी कुंजी TPM हो तो हार्डवेयर सुरक्षित होती है।¹⁰ ब्राउज़र (Edge/Chrome) से WebAuthn Windows 10 पर भी चलता है।
• Entra ID वातावरण में «पासकी = FIDO2 प्रमाणीकरण विधि» सक्षम करें। Microsoft Entra ID सुरक्षा कुंजी और Microsoft Authenticator ऐप में पासकी (डिवाइस-बद्ध) समर्थित करता है, सशर्त पहुँच प्रमाणीकरण सामर्थ्य से «फ़िशिंग-प्रतिरोधी MFA» माँगें तो लक्ष्य संसाधन पहुँच पासकी आदि तक सीमित कर सकते हैं।⁹ NTLM या पासवर्ड समय-सीमा नीति की दुनिया से एक छलाँग नहीं जाता, इसलिए NTLM और Kerberos लेख वाली प्रमाणीकरण आधार सूची के साथ पहले व्यवस्थापक खातों से फ़िशिंग-प्रतिरोधी MFA अनिवार्य करना नियम है।
• आंतरिक वेब ऐप पर भी लाभ वही। पर HTTPS पूर्वापेक्षा। WebAuthn API सुरक्षित संदर्भ में ही चलता है, इसलिए इंट्रानेट ऐप पर भी (विकास के localhost छोड़) HTTPS और RP ID के रूप में चलने वाले आंतरिक डोमेन नाम पहले तैयार करें। वह हो तो RP ID आंतरिक डोमेन पर भी चलता है। पासवर्ड चिट्ठी से विदाई के अर्थ में बाहरी सेवा से आंतरिक पर प्रभाव जल्दी दिखना असामान्य नहीं।

8. सारांश

• पासवर्ड की कमजोरी सामर्थ्य नहीं, «रहस्य साझा कर हर प्रमाणीकरण पर भेजना» संरचना है। रहस्य उपयोगकर्ता, इनपुट क्षेत्र, पथ, सर्वर सब पर है, इसलिए हमले के लक्ष्य अधिक। वन-टाइम कोड जोड़ें तो भी AiTM फ़िशिंग रिले कर हरा देती है।
• पासकी साइट-दर सार्वजनिक-कुंजी क्रिप्टोग्राफ़ी कुंजी युग्म है, सर्वर को लीक हो तो भी दुरुपयोग न हो सकने वाली सार्वजनिक कुंजी मात्र सौंपती है, लॉगिन पर एकबारगी चैलेंज पर हस्ताक्षर मात्र भेजती है। सर्वर पर रहस्य नहीं, पथ पर भी रहस्य नहीं बहता।
• हस्ताक्षर में ब्राउज़र द्वारा पुष्ट ओरिजिन और RP ID पके होते हैं, इसलिए नकली साइट पर असली पासकी उम्मीदवार में नहीं आती, रिले भी जाँच गिरती है। उपयोगकर्ता को नकली साइट पहचानने की ज़रूरत नहीं — यही «फ़िशिंग प्रतिरोध» का असली रूप, रक्षा का आधार मानव सतर्कता से प्रोटोकॉल संरचना पर गया।
• सिंक प्रकार पासकी एंड-टू-एंड एन्क्रिप्शन से सिंक होती हैं, मॉडल बदलना-खोना मज़बूत। उसके बदले बचाने का स्थान क्लाउड खाते पर सिमटता है, इसलिए Apple ID/Google खाता स्वयं की रक्षा पूर्वापेक्षा। कॉर्पोरेट डिवाइस-बद्ध (सुरक्षा कुंजी, Entra ID Authenticator पासकी) भी चुन सकते हैं।
• पासकी हमले मिटाती नहीं कमज़ोर स्थान की ओर धकेलती है। साथ बचा पासवर्ड, खाता पुनर्प्राप्ति प्रवाह, सत्र चोरी बचे हमला तल हैं; लागू करने का केंद्र फ़ॉलबैक नियोजित घटाना और पुनर्प्राप्ति प्रवाह मज़बूत करना है।
• कार्यान्वयन WebAuthn API के create / get दो फ़ंक्शन + सर्वर जाँच। जाँच स्वयं न लिखें, सिद्ध लाइब्रेरी पर छोड़ें, चैलेंज प्रबंधन, कई पासकी UI, पुनर्प्राप्ति डिज़ाइन पर शक्ति लगाएँ।

संबंधित लेख

• Windows TPM क्या है — «कुंजी बाहर न निकालने वाला तिजोरी» और मापित बूट
• आरेखों से NTLM और Kerberos — प्रमाणीकरण NTLM पर क्यों गिरता है
• WinForms/WPF ऐप में Entra ID प्रमाणीकरण जोड़ना — MSAL.NET और WAM ब्रोकर का व्यावहारिक विन्यास
• PowerShell में क्रेडेंशियल का सुरक्षित व्यवहार — सादे पासवर्ड स्क्रिप्ट से निकालना
• Windows ऐप विकास की सुरक्षा न्यूनतम जाँच सूची
• छोटे-मध्यम व्यवसाय सुरक्षा, कहाँ से शुरू करें — IPA «छोटे-मध्यम व्यवसाय सूचना सुरक्षा दिशानिर्देश» संस्करण 4.0

संबंधित परामर्श क्षेत्र

KomuraSoft LLC आंतरिक वेब सिस्टम पर पासकी लॉगिन WebAuthn कार्यान्वयन सहायता, Entra ID वातावरण में फ़िशिंग-प्रतिरोधी MFA परिनियोजन डिज़ाइन, WinForms/WPF जैसे Windows व्यावसायिक ऐप में प्रमाणीकरण जोड़ना सहित Custom Software Development सँभालता है।

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

पासकी और पासवर्ड का मूल अंतर क्या है?

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

बायोमेट्रिक जानकारी (उंगली, चेहरा) सर्वर को भेजी जाती है?

नहीं। उंगली या चेहरे का डेटा डिवाइस के भीतर «निजी कुंजी वाले तिजोरी का द्वार खोलने» के लिए ही स्थानीय मिलान है; FIDO डिज़ाइन पर बायोमेट्रिक जानकारी डिवाइस से बाहर नहीं भेजी जाती। सर्वर को मिलता «उपयोगकर्ता सत्यापन (यूज़र वेरिफ़िकेशन) हुआ» फ़्लैग लगा हस्ताक्षर मात्र; उंगली स्वयं तो क्या, उसकी विशेषताएँ भी शामिल नहीं। बायोमेट्रिक न चलें तो PIN विकल्प है, पर यह PIN भी Windows Hello PIN जैसा केवल डिवाइस पर स्थानीय मिलान — नेटवर्क न बहना पासवर्ड से निर्णायक अंतर है।

पासकी फ़िशिंग के प्रति मज़बूत क्यों हैं?

उपयोगकर्ता को नकली साइट पहचानने की ज़रूरत तंत्र पर ही नहीं, इसलिए। पासकी साइट के डोमेन (RP ID) से बाँधकर बनती है, ब्राउज़र «अभी दिख रही साइट के डोमेन» से मेल खाती पासकी ही उम्मीदवार दिखाता है। असली जैसी नकली डोमेन पर जाएँ तो असली साइट की पासकी विकल्प में नहीं आती, उपयोगकर्ता धोखा नहीं खा सकता। आगे हस्ताक्षर में ब्राउज़र द्वारा पुष्ट ओरिजिन और RP ID हैश पका होता है, इसलिए हस्ताक्षर रिले भी करें तो असली सर्वर की जाँच गिरती है। पासवर्ड या SMS कोड जैसा «असली क्रेडेंशियल नकली साइट में डाल देना» दुर्घटना संरचनात्मक रूप से नहीं बनती — यही प्रशिक्षण और सतर्कता पर निर्भर उपायों से मूल अंतर है।

फ़ोन खो जाए तो खाते में नहीं घुस सकेंगे?

सिंक प्रकार की पासकी (iCloud कीचेन या Google पासवर्ड मैनेजर में संग्रहीत) हो तो उसी Apple ID/Google खाते से साइन-इन नए डिवाइस पर पुनर्स्थापित हो सकती है। पर एंड-टू-एंड एन्क्रिप्टेड तिजोरी पुनर्स्थापित करने को खाते का पासवर्ड भर नहीं, पिछले टर्मिनल का स्क्रीन लॉक (पासकोड) डालना जैसी अतिरिक्त पहचान चाहिए; ये पुनर्प्राप्ति साधन भी खोएँ तो पुनर्स्थापना न हो सके। सब कुछ एक फ़ोन पर न सौंपना महत्वपूर्ण है। डिवाइस-बद्ध प्रकार (सुरक्षा कुंजी, Windows Hello आदि) टर्मिनल की नियति साझा करते हैं, इसलिए महत्वपूर्ण खातों पर कई पासकी पंजीकृत रखना नियम है। अधिकतर सेवाएँ एक खाते पर कई पासकी पंजीकृत करने देती हैं। खोने पर अमान्य करना प्रकार से प्रक्रिया बदलता है। सिंक प्रकार में प्रत्येक डिवाइस की प्रति एक ही क्रेडेंशियल है, इसलिए पहले प्लेटफ़ॉर्म खाते पर खोए टर्मिनल हटाना या रिमोट वाइप कर टर्मिनल की प्रति बेकार करें (सेवा के खाता सेटिंग में वह पासकी हटाएँ तो सब डिवाइस की प्रति एक साथ अमान्य होती है)। डिवाइस-बद्ध हो तो सेवा पक्ष उस प्रमाणक की पासकी हटाकर खोई कुंजी मात्र अमान्य कर सकते हैं। संगठन में «उपयोगकर्ता स्वयं पुनर्प्राप्त कर सके दोहरीकरण» और «खोने पर व्यवस्थापक रद्द करे प्रक्रिया» एक सेट डिज़ाइन करना महत्वपूर्ण है।

पासकी की भी कमज़ोरियाँ हैं?

हैं। पर कमजोरी का स्थान बदलता है, यही सही कहना है। प्रमाणीकरण स्वयं सार्वजनिक-कुंजी क्रिप्टोग्राफ़ी से मज़बूत होता है, इसलिए हमलावर कमज़ोर परिधि निशाना बनाते हैं। ठोस: पासवर्ड या SMS जैसे पारंपरिक साधन साथ रहें तो वही सबसे कमज़ोर कड़ी; खाता पुनर्प्राप्ति प्रवाह दुरुपयोग कर हमलावर अपनी पासकी पंजीकृत कराने की चाल; सिंक प्रकार में क्लाउड खाता स्वयं का अधिग्रहण नया एकल विफलता बिंदु। साथ लॉगिन बाद सत्र कुकी चुराना पासकी नहीं रोकती, इसलिए असंबंधित खतरे गायब नहीं होते। लागू करते «पासकी जोड़ना» भर नहीं, पुनर्प्राप्ति प्रवाह मज़बूत करना और फ़ॉलबैक साधन नियोजित घटाना तक डिज़ाइन चाहिए।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।