Passkey सुरक्षित क्यों हैं — «secret न भेजने वाले authentication» का illustrated mechanism

«फिर किसी बड़ी service से passwords leak हुए» समाचार अब किसी को आश्चर्य नहीं देते। Phishing training हर वर्ष करें, फँसने वाले शून्य नहीं होते। «Passwords reuse न करें, लंबे करें, periodic change… अब नहीं चाहिए» — सलाह भी दो-तीन बार पलटी।

पिछले कुछ वर्षों में तेज़ी से फैली passkey इस स्थिति का उत्तर मानकर Apple, Google, Microsoft तीनों मिलकर आगे बढ़ा रहे authentication तरीका है।¹ «Fingerprint या चेहरे से login, सुविधाजनक» परिचय अधिक है, पर सार वहाँ नहीं। Passkey का असली मूल्य security का आधार «मानव सतर्कता» से «protocol की structure» पर ले जाना है।

• Password leak user की लापरवाही से, शिक्षा दें → मनुष्य अवश्य गलती करता है
• Fake site पहचानने का training दें → न पहचानी जा सकने वाली fake site बनाई जा सकती है
• Passkey हो तो → भेजने का secret ही नहीं, fake site पर signature बनता ही नहीं

यह लेख passkey सुरक्षित क्यों हैं, password में क्या टूटा है वहाँ से diagrams से पकड़ता है। फिर «sync होती passkey सच में सुरक्षित हैं?», «कमज़ोरी नहीं?» जैसे स्वाभाविक प्रश्नों का सीधा उत्तर देता है, अंत में web apps और Windows वातावरण में implement करने के practical points व्यवस्थित करता है।

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

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

1. Server पर secret मौजूद नहीं। Server stored केवल public key — leak हो तो भी misuse न हो सकने वाली जानकारी। Database पूरा बहे तो भी attacker «impersonation की सामग्री» घर नहीं ले जाता।²
2. Secret network पर नहीं बहता। Login पर भेजा जाता one-time random number (challenge) पर signature मात्र। Private key device के authenticator से बिलकुल नहीं निकलती, इसलिए path कहीं भी सुनें-relay करें secret हाथ नहीं आता।²
3. Fake site पर signature बनता नहीं। Passkey site के domain से बँधी है, browser domain matching बाध्य करता है। User fake site से धोखा खाए तो भी असली site की passkey candidate में नहीं आती, signature relay भी करें तो verification गिरती है।³

ये तीन स्वतंत्र तरकीब नहीं, «secret share कर भेजने» वाले authentication से «secret रखना signature से सिद्ध करने» वाले authentication एक design बदलाव से निकले सब परिणाम हैं। क्रम से देखते हैं।

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

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

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

यानी «passkey support» implementation की भाषा में «WebAuthn implement करना» है। CTAP बाहरी authenticator use पर browser और OS सँभालते हैं, web app बनाने वाला सीधे नहीं छूता।

Diagram में solid line हमेशा लागू रहने वाला relation दिखाती है और dashed line conditional relation दिखाती है (शर्तें detail page पर हर relation के explanation में दी गई हैं)। Relations की पूरी list (कुल 38, evidence और certainty सहित) तथा मुख्य concepts की definitions knowledge map की detail page पर संकलित हैं (जापानी में)। Data: JSON-LD / Turtle

2. Password authentication में क्या टूटा है

Passkey की security समझने का छोटा रास्ता password की कमजोरी «स्थान» से पकड़ना है। Password authentication में secret स्वयं हर authentication पर पूरा path यात्रा करता है।

sequenceDiagram
    participant U as User
    participant B as Browser
    participant S as Server
    Note over U: Secret (password) सिर में रखता है<br/>【कमजोरी ①】Guess / sites पर reuse होता है
    U->>B: Password डालता है
    Note over B: 【कमजोरी ②】Fake site पर भी वैसे ही<br/>डाल सकते हैं (दिखावट से भेद नहीं)
    B->>S: Password स्वयं भेजता है
    Note over B,S: 【कमजोरी ③】Secret path पर बहता है<br/>TLS से बचा पर अंत पर plaintext लौटता है
    S->>S: Stored hash से मिलाता है
    Note over S: 【कमजोरी ④】सब users का secret (hash) एकत्र<br/>Leak हो तो offline brute-force का निशाना

चित्र 1: Password authentication में secret स्वयं पूरे path पर मौजूद है

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

• कमजोरी ① (user): याद रखने योग्य strength ही, कई sites पर reuse होता है। एक स्थान का leak सब accounts तक फैलता है (password-list attack / credential stuffing)।
• कमजोरी ② (डालने का क्षण): असली से अभिन्न fake site बनाएँ तो user स्वयं secret सौंप देता है (phishing)।
• कमजोरी ③ (path): TLS से path स्वयं सुनना कठिन, पर «valid दिखने वाला relay point» बीच में आ जाए तो अर्थ नहीं (बाद का AiTM)।
• कमजोरी ④ (server): Hash कर रखें, database बहे तो offline brute-force। कमज़ोर passwords से क्रम से टूटते हैं।

«तो one-time code (SMS या TOTP) जोड़ दें» traditional multi-factor authentication है, पर shared secret भेजने की structure नहीं बदलती। TOTP में server और authenticator app एक ही seed (secret) share करते हैं, बने 6 अंक user fake site में डाल सकता है। वास्तव में fake site असली server को real-time relay करने वाला AiTM (Adversary-in-the-Middle) phishing password+one-time code जोड़ी यों ही आगे भेजकर तोड़ता है। CISA (US cyber security agency) «phishing-resistant MFA» में FIDO/WebAuthn और smart card (PIV/CAC) जैसे PKI-based authentication दो ही गिनाती है, उनमें FIDO को gold standard रखती है — यही कारण।⁴

यानी समस्या password की «strength» नहीं, «secret share कर हर authentication पर भेजना» structure स्वयं है।

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

Passkey W3C के WebAuthn और FIDO Alliance के CTAP दो standards (मिलाकर FIDO2) पर बनी public-key cryptography based credential है।²¹ कठिन लगता है, structure सरल है।

flowchart LR
    subgraph DEV["User का device"]
        AUTH["Authenticator (vault)<br/>Windows Hello / Face ID /<br/>Android screen lock / security key"]
        SK["Private key<br/>यहाँ से बिलकुल नहीं निकलती"]
        BIO["Fingerprint · चेहरा · PIN<br/>= vault का दरवाज़ा खोलना मात्र<br/>यह भी बाहर नहीं जाता"]
        AUTH --- SK
        BIO -->|"Local matching"| AUTH
    end
    subgraph SRV["Server"]
        PK["Public key<br/>Leak हो तो भी misuse नहीं<br/>«केवल verification» की जानकारी"]
    end
    SK -.->|"गणितीय pair<br/>(signature बनाने वाला पक्ष)"| PK

चित्र 2: Passkey का पदार्थ site-दर key pair। Secret पक्ष device से नहीं निकलता, server के पास केवल verification की public key

• Private key signature बनाने वाला पक्ष, device के authenticator (Windows Hello, iPhone Face ID/Touch ID, Android screen lock, या YubiKey जैसी security key) में stored, बाहर नहीं जाती।
• Public key signature verify करने वाला पक्ष, इसे server पर सौंपते हैं। Public key से private key उलटी गणना computationally असंभव, इसलिए leak हो तो चले।
• Fingerprint-चेहरा आदि biometric जानकारी vault का दरवाज़ा local खोलने के लिए ही, यह भी device से नहीं निकलती। Server को biometric नहीं भेजी जाती।¹

Registration: public key «मात्र» सौंपना

Site पर passkey register करते flow।

sequenceDiagram
    participant S as Server (example.com)
    participant B as Browser
    participant A as Authenticator
    S->>B: Registration request (random challenge + site जानकारी)
    B->>A: इस site (example.com) की key बनाओ
    A->>A: Fingerprint · चेहरा · PIN से पहचान (local)
    A->>A: नया key pair generate<br/>Private key भीतर stored
    A->>B: Public key + credential ID (key का nameplate)
    B->>S: Public key + credential ID भेजता है
    S->>S: इस account की public key के रूप में सहेजता है
    Note over S: Server को मिला<br/>«leak हो तो भी misuse न हो सकने वाली जानकारी» मात्र

चित्र 3: Registration पर network बहता और server stored केवल public key

महत्वपूर्ण: इस समय key pair site के domain (RP ID) से bind करके बनता है। example.com के लिए बनी passkey example.com site पर ही चलती है (RP ID domain इकाई है, इसलिए login.example.com जैसे उसी domain के subdomain पृष्ठ से चलती है, unrelated domain से नहीं)। यही binding बाद की phishing resistance का आधार है।³

साथ key pair site-दर हर बार नया बनता है। Site A और site B की passkeys गणितीय रूप से unrelated, इसलिए «reuse» अवधारणा ही नहीं, sites के बीच user मिलाने की सामग्री भी नहीं।

Authentication: one-time signature लौटाना

Login का flow। Password authentication (चित्र 1) से तुलना करें।

sequenceDiagram
    participant S as Server (example.com)
    participant B as Browser
    participant A as Authenticator
    S->>B: Login request (one-time random challenge)
    B->>A: example.com पर signature request
    A->>A: Fingerprint · चेहरा · PIN से पहचान (local)
    A->>A: Private key से signature बनाता है<br/>Challenge + origin + RP ID hash शामिल करता है
    A->>B: Signature (private key स्वयं नहीं)
    B->>S: Signature भेजता है
    S->>S: Stored public key से signature verify करता है<br/>Challenge · origin · RP ID भी confirm
    Note over B,S: Path पर बहता one-time signature मात्र<br/>चोरी करें तो अगले challenge पर काम नहीं

चित्र 4: Authentication पर भी secret नहीं चलता। बहता «one-time proof» मात्र

Server हर बार नया random number (challenge) देता है, authenticator «उस challenge + अभी browser देख रहा origin + RP ID hash» पर signature करता है। Server stored public key से signature verify करता है, challenge अपना दिया हुआ है, origin और RP ID अपनी site के हैं, confirm करता है।⁵

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

• Server पर secret नहीं: Stored केवल public key। बहे तो attacker signature नहीं बना सकता, password hash जैसा «घर ले जाकर तोड़ना» नहीं।
• Secret नहीं बहता: Path का signature चुराएँ, challenge one-time इसलिए reuse (replay) नहीं।

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

4. Phishing «structure से» न बनने का कारण

Password पर phishing सफल इसलिए है कि असली secret fake site में डाला जा सकता है। मनुष्य example.com और examp1e.com भेद (थके तो विशेषकर) नहीं करता, पर password field दोनों sites पर वैसे ही चलता है।

Passkey में यह matching मनुष्य नहीं browser यांत्रिक रूप से करता है। WebAuthn spec पर browser «अभी दिख रहे origin का domain» और «passkey का RP ID» match खाएँ तभी authenticator बुला सकता है।³ Fake site पर जाने पर क्या होता है, diagram में।

sequenceDiagram
    participant U as User
    participant B as Browser
    participant P as Fake site (examp1e.com)<br/>असली को relay करने वाला AiTM proxy
    participant S as असली server (example.com)
    U->>P: दिखने में अभिन्न login screen पर जाता है
    P->>S: (पीछे) असली login प्रक्रिया शुरू
    S->>P: Challenge
    P->>B: Challenge आगे भेजकर signature माँगता है
    B->>B: अभी का origin examp1e.com है<br/>example.com की passkey candidate नहीं बना सकता
    B--xP: Signature नहीं बनता (user धोखा नहीं खा सकता)
    Note over B,S: किसी विधि से signature बने तो भी,<br/>signature में examp1e.com शामिल होता है इसलिए<br/>असली server की verification अवश्य गिरती है

चित्र 5: AiTM phishing password+one-time code तोड़ती है, passkey पर signature चरण पर नहीं बनती

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

1. Candidate में नहीं आती: Browser origin से match RP ID की passkey ही list करता है। Fake domain पर असली site की passkey option में नहीं, user «भूल से use» भी नहीं कर सकता।
2. Signature नहीं चलता: Signature target में browser द्वारा confirm origin और RP ID hash शामिल। असली server verify करते मिलाता है, इसलिए दूसरे origin पर बना signature अवश्य rejected।⁵

Password phishing रोक «user URL ध्यान से देखे» human effort पर निर्भर थी। Passkey में user को fake site पहचानने की ज़रूरत ही नहीं। यही «phishing resistance (phishing-resistant)» शब्द का सटीक अर्थ है, CISA और NIST (US standards institute) FIDO/WebAuthn को विशेष रखने का कारण।⁴⁶

अब तक attack method-दर व्यवस्थित करें।

तालिका 2: Attack method-दर resistance तुलना। Passkey के «○» operations या सतर्कता नहीं, structure से आते हैं

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

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

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

तालिका 3: Synced type और device-bound त्वरित तालिका। कौन चुनें «खोने पर मज़बूती» और «key का स्थान manage कर सकना» में से क्या लें, उसी से तय

flowchart TB
    subgraph SYNC["Synced passkey (consumer default)"]
        S1["iCloud Keychain /<br/>Google Password Manager /<br/>1Password जैसे password managers"]
        S2["उसी account के devices के बीच<br/>End-to-end encrypt कर sync<br/>Provider भी सामग्री नहीं पढ़ सकता"]
        S3["लाभ: model बदलना · खोना मज़बूत<br/>सावधान: cloud account स्वयं की रक्षा चाहिए"]
        S1 --> S2 --> S3
    end
    subgraph BOUND["Device-bound passkey"]
        B1["Security key (YubiKey आदि) /<br/>Windows Hello /<br/>Microsoft Authenticator (Entra ID)"]
        B2["Private key उस hardware से<br/>भौतिक रूप से नहीं निकलती (TPM आदि से सुरक्षित)"]
        B3["लाभ: key का स्थान एक जगह स्पष्ट<br/>सावधान: खोने के लिए कई registration अनिवार्य"]
        B1 --> B2 --> B3
    end
    SYNC ~~~ BOUND

चित्र 6: Synced type और device-bound। दोनों «private key server को न भेजें» समान, रक्षा का भार केंद्र अलग

Synced passkey iCloud Keychain या Google Password Manager private key उसी account के devices के बीच sync करते हैं। यहाँ महत्वपूर्ण: sync end-to-end encrypted है। Apple और Google दोनों कहते हैं passkey device पर encrypt होकर sync होती है, provider स्वयं सामग्री नहीं पढ़ सकता।⁷⁸ यानी «private key device से नहीं निकलती» सिद्धांत सटीक रूप से «private key plaintext में device से नहीं निकलती» तक ढीला होकर उसके बदले model बदलना और खोना resistance मिलता है।

यह ढील threat model कैसे बदलती है, स्पष्ट कहना चाहिए। बचाने का स्थान «प्रत्येक site का server» से «एक cloud account» पर सिमटता है। प्रत्येक site के DB leak और phishing पर पहले जैसी मज़बूती, अब Apple ID/Google account स्वयं का takeover single point of failure बनता है। इसलिए passkey सौंपे platform account पर सबसे मज़बूत security (मज़बूत screen lock, recovery means व्यवस्थित, संभव हो तो भौतिक security key) पूर्वापेक्षा है। NIST ने अप्रैल 2024 में NIST SP 800-63B का Supplement (Supplement 1: Incorporating Syncable Authenticators Into NIST SP 800-63B) निकाला, यह synced passkey (syncable authenticator) आवश्यकताएँ पूरी करे तो सरकारी standard AAL2 (Authenticator Assurance Level 2) पूरी कर सकती है, औपचारिक रूप से। पर private key export हो सकती है इसलिए hardware-isolated वातावरण माँगने वाले AAL3 पर synced type न use कहता है।⁶

Device-bound passkey private key hardware से न निकलने वाला type है। YubiKey जैसी security key प्रतिनिधि, corporate में Microsoft Entra ID passkey (Microsoft Authenticator में बनने वाली) भी device-bound है।⁹ Windows का Windows Hello TPM हो तो private key TPM के नीचे सुरक्षित करता है। यह «key बाहर न निकालने वाला hardware vault» mechanism स्वयं TPM लेख में विस्तार से समझाया आधार है।

«फ़ोन की passkey से PC browser में login» पर QR code scan कराने पर आश्चर्य हुआ हो सकता है। वह केवल screen संक्रमण नहीं, Bluetooth से फ़ोन और PC की भौतिक proximity confirm करने वाला hybrid तरीका (FIDO का cross-device authentication) है। दूर के attacker अपने PC पर login QR code से किसी और से स्वीकृत कराने वाला attack proximity confirmation से काटता है।¹

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

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

flowchart LR
    A["Attacker"]
    G["Authentication स्वयं<br/>Challenge signature<br/>【मज़बूत】"]
    R["Account recovery flow<br/>«Passkey खोई» कहकर<br/>SMS या email से पुनः set करवाकर<br/>Attacker की passkey register करना"]
    F["साथ बचा fallback<br/>Password · SMS login<br/>बचे तो सबसे कमज़ोर कड़ी वहाँ"]
    C["Cloud account<br/>Synced type हो तो Apple ID /<br/>Google account single point of failure"]
    SS["Session<br/>Login बाद cookie चुराएँ तो<br/>Authentication method निरर्थक"]
    A --x G
    A --> R
    A --> F
    A --> C
    A --> SS

चित्र 7: द्वार (authentication) मज़बूत हो तो attack recovery flow, साथ बचे means, cloud account, session की ओर जाता है

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

1. साथ बचा fallback सबसे कमज़ोर कड़ी बनता है। Passkey «भी» चलने भर दें, password या SMS login बचे तो attacker वही use करता है। Phishing resistance खाते पूरे पर सबसे कमज़ोर login means के स्तर से सीमित। Implement करने का केंद्र passkey जोड़ना नहीं, fallback नियोजित घटाना-समाप्त करना है।
2. Recovery flow नया attack surface बनता है। «Device खोया» झूठ बोलकर support या email से पुनः set कर attacker अपनी passkey register कराने की चाल। वास्तव में मज़बूत authentication टालकर helpdesk धोखा social engineering बड़े breach का आम साधन बन गया। Authentication मज़बूत किया, अब recovery flow की identity कैसे design करें, यही पूछा जाता है।
3. Synced type में cloud account single point of failure। पिछले अनुच्छेद के अनुसार। Passkey सौंपे account की रक्षा और संगठन में «किस platform पर sync अनुमति» policy तय करनी चाहिए।
4. Session theft नहीं रुकती। Passkey login के क्षण मात्र बचाती है; login बाद session cookie malware या XSS से चुराई जाए तो authentication method निरर्थक। Token validity period, binding, device health management अलग परत का काम बचता है।

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

7. Practical implementation — WebAuthn API और Windows वातावरण

अंत में implement करने वाले की दृष्टि से points।

अपनी web service पर passkey login लगाना

Browser पक्ष WebAuthn API के दो functions मात्र। Registration navigator.credentials.create(), authentication navigator.credentials.get()।

// Registration (browser पक्ष)
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: challengeFromServer,   // Server द्वारा generate one-time random number
    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",        // Discoverable credential (= passkey) बनाता है
      userVerification: "required",   // Biometric/PIN से पहचान अनिवार्य करता है
    },
  },
});
// Public key credential.response से, credential ID शीर्ष स्तर के
// credential.id / credential.rawId से निकालें। Registration response भी authentication की तरह
// सहेजने से पहले server पक्ष पर challenge, origin, RP ID verify करें

मुख्य parameters का अर्थ इस प्रकार।

तालिका 4: navigator.credentials.create() के मुख्य parameters

Test वातावरण की सावधानी: WebAuthn API secure context में ही published होता है, सादे http:// से दी पृष्ठ पर navigator.credentials call विफल। अपवाद http://localhost (और 127.0.0.1) — trusted origin माने जाते हैं, development machine पर HTTPS बिना आज़मा सकते हैं। पर RP ID origin का effective domain (या उसका parent) होना चाहिए, इसलिए localhost पर बनी passkey production domain पर नहीं चलती। हाथ में authenticator न हो तो Chrome Developer Tools के «WebAuthn» tab से virtual authenticator सक्षम कर registration से authentication तक चला सकते हैं।

// Authentication (browser पक्ष)
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: challengeFromServer,
    rpId: "example.com",
    userVerification: "required",
  },
  // Login field के autofill candidate के रूप में passkey दिखाता है। पहले
  // PublicKeyCredential.isConditionalMediationAvailable() से support जाँचें,
  // unsupported browser पर mediation बिना सामान्य call पर fallback करें
  mediation: "conditional",
  // (लक्ष्य <input> पर autocomplete="username webauthn" निर्दिष्ट करना आवश्यक)
});
// assertion.response के signature server पक्ष पर verify करें

मुख्य काम server पक्ष की verification है। न्यूनतम ये अवश्य करें।⁵

• Challenge matching: स्वयं जारी unused challenge है? One-time रखा (replay रोक)? आगे जारी करते browser session (login attempt) से बाँधकर सहेजें, उसी session की response को ही consume अनुमति। यहाँ ढीला हो तो attacker अपने challenge का signature पीड़ित के browser से भेजकर पीड़ित को attacker के account में login करा सकता है (login CSRF)।
• Origin matching: clientDataJSON का origin अपनी site का valid origin है (phishing रोक की कुंजी)।
• RP ID hash matching: authenticatorData का rpIdHash अपनी site के RP ID के SHA-256 से match खाता है।
• Ceremony type और flags confirm: clientDataJSON का type authentication पर webauthn.get, registration पर webauthn.create है? authenticatorData का UP (user present) flag लगा है? User verification (UV) माँगा तो UV flag भी लगा है?
• Signature verification: Registration पर सहेजी public key से signature सही verify होता है।
• Account से बाँधना: प्रस्तुत credential ID (और userHandle) अपने database से खींचकर उस credential के owner को session जारी कर रहे हैं? अलग डाला username बिना शर्त मानें तो सही signature से दूसरे के रूप में login का छेद बनता है।
• Signature counter सहेजना और तुलना: authenticatorData का signCount credential-दर सहेजें, अगला मान पिछले से बढ़ा हो पुष्टि करें। पिछले से कम या बराबर (समान सहित) हो तो authenticator copy (clone) का संकेत मानें। पर synced passkey प्रायः हमेशा 0 लौटाती हैं, इसलिए 0 से 0 अपवाद के रूप में स्वीकारें।

यह verification हाथ से लिखना incident का कारण है, सिद्ध library (.NET में fido2-net-lib, Node.js में SimpleWebAuthn आदि) use करें। Spec की बारीकियाँ (CBOR parse, algorithm negotiation, challenge management) library पर छोड़ें, स्वयं challenge सहेजना-रद्द, कई passkeys management UI, recovery flow design पर केंद्रित रहें — सही शक्ति विभाजन यही है।

Windows वातावरण · internal systems

इस साइट के पाठक — «Windows business systems सँभालने वाले» — के लिए तीन points काफी।

• Windows client supported है। Windows 11 Windows Hello को authenticator मानकर passkey बनाना-use-management (Settings > Accounts > Passkeys) support करता है, private key TPM हो तो hardware सुरक्षित होती है।¹⁰ Browser (Edge/Chrome) से WebAuthn Windows 10 पर भी चलता है।
• Entra ID वातावरण में «passkey = FIDO2 authentication method» सक्षम करें। Microsoft Entra ID security key और Microsoft Authenticator app में passkey (device-bound) support करता है, Conditional Access authentication strength से «phishing-resistant MFA» माँगें तो लक्ष्य resource पहुँच passkey आदि तक सीमित कर सकते हैं।⁹ NTLM या password expiry policy की दुनिया से एक छलाँग नहीं जाता, इसलिए NTLM और Kerberos लेख वाली authentication आधार सूची के साथ पहले admin accounts से phishing-resistant MFA अनिवार्य करना नियम है।
• Internal web apps पर भी लाभ वही। पर HTTPS पूर्वापेक्षा। WebAuthn API secure context में ही चलता है, इसलिए intranet apps पर भी (development के localhost छोड़) HTTPS और RP ID के रूप में चलने वाले internal domain name पहले तैयार करें। वह हो तो RP ID internal domain पर भी चलता है। Password चिट्ठी से विदाई के अर्थ में बाहरी service से internal पर प्रभाव जल्दी दिखना असामान्य नहीं।

8. सारांश

• Password की कमजोरी strength नहीं, «secret share कर हर authentication पर भेजना» structure है। Secret user, input field, path, server सब पर है, इसलिए attacks के target अधिक। One-time code जोड़ें तो भी AiTM phishing relay कर हरा देती है।
• Passkey site-दर public-key cryptography key pair है, server को leak हो तो भी misuse न हो सकने वाली public key मात्र सौंपती है, login पर one-time challenge पर signature मात्र भेजती है। Server पर secret नहीं, path पर भी secret नहीं बहता।
• Signature में browser द्वारा confirm origin और RP ID पके होते हैं, इसलिए fake site पर असली passkey candidate में नहीं आती, relay भी verification गिरती है। User को fake site पहचानने की ज़रूरत नहीं — यही «phishing resistance» का असली रूप, रक्षा का आधार मानव सतर्कता से protocol structure पर गया।
• Synced passkey end-to-end encryption से sync होती हैं, model बदलना-खोना मज़बूत। उसके बदले बचाने का स्थान cloud account पर सिमटता है, इसलिए Apple ID/Google account स्वयं की रक्षा पूर्वापेक्षा। Corporate device-bound (security key, Entra ID Authenticator passkey) भी चुन सकते हैं।
• Passkey attacks मिटाती नहीं कमज़ोर स्थान की ओर धकेलती है। साथ बचा password, account recovery flow, session theft बचे attack surfaces हैं; implement करने का केंद्र fallback नियोजित घटाना और recovery flow harden करना है।
• Implementation WebAuthn API के create / get दो functions + server verification। Verification स्वयं न लिखें, सिद्ध library पर छोड़ें, challenge management, कई passkeys UI, recovery design पर शक्ति लगाएँ।

संबंधित लेख

• Windows TPM क्या है — «key बाहर न निकालने वाला vault» और measured boot
• Diagrams से NTLM और Kerberos — authentication NTLM पर क्यों गिरता है
• WinForms/WPF apps में Entra ID authentication जोड़ना — MSAL.NET और WAM broker का practical config
• PowerShell में credentials का सुरक्षित व्यवहार — plaintext passwords script से निकालना
• Windows app development की security न्यूनतम checklist
• SME security, कहाँ से शुरू करें — IPA «SME information security guideline» version 4.0

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

KomuraSoft LLC internal web systems पर passkey login WebAuthn implementation सहायता, Entra ID वातावरण में phishing-resistant MFA deployment design, WinForms/WPF जैसे Windows business apps में authentication जोड़ना सहित Custom Software Development सँभालता है।

संबंधित लेख

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

संबंधित विषय

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

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

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

Passkey और password का मूल अंतर क्या है?

Password «user और server एक ही secret share करें, login हर बार वह secret भेजें» mechanism है। Secret user के सिर, input field, communication path, server के database — हर जगह है, इसलिए सब attack के target बनते हैं। Passkey public-key cryptography का key pair use करती है, private key server को नहीं भेजी जाती। Device-bound type में private key authenticator से बिलकुल नहीं निकलती; synced type में भी end-to-end encrypted form में ही बाहर जाती है। Server पर stored केवल public key — «leak हो तो भी misuse न हो सकने वाली जानकारी» — है, login पर भेजा जाता one-time challenge पर signature मात्र। यानी password की कमजोरी वाला «shared secret» स्वयं मौजूद नहीं। साथ key pair site-दर अलग बनता है, इसलिए reuse की अवधारणा भी नहीं बनती।

Biometric जानकारी (fingerprint, चेहरा) server को भेजी जाती है?

नहीं। Fingerprint या चेहरे का data device के भीतर «private key वाले vault का दरवाज़ा खोलने» के लिए ही local matching है; FIDO design पर biometric जानकारी device से बाहर नहीं भेजी जाती। Server को मिलता «user verification हुआ» flag लगा signature मात्र; fingerprint स्वयं तो क्या, उसकी features भी शामिल नहीं। Biometric न चलें तो PIN विकल्प है, पर यह PIN भी Windows Hello PIN जैसा केवल device पर local matching — network न बहना password से निर्णायक अंतर है।

Passkey phishing के प्रति मज़बूत क्यों हैं?

User को fake site पहचानने की ज़रूरत mechanism पर ही नहीं, इसलिए। Passkey site के domain (RP ID) से bind करके बनती है, browser «अभी दिख रही site के domain» से match करती passkey ही candidate दिखाता है। असली जैसी fake domain पर जाएँ तो असली site की passkey option में नहीं आती, user धोखा नहीं खा सकता। आगे signature में browser द्वारा confirm origin और RP ID hash पका होता है, इसलिए signature relay भी करें तो असली server की verification गिरती है। Password या SMS code जैसा «असली credential fake site में डाल देना» incident structure से नहीं बनती — यही training और सतर्कता पर निर्भर उपायों से मूल अंतर है।

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

Synced type की passkey (iCloud Keychain या Google Password Manager में stored) हो तो उसी Apple ID/Google account से sign-in नए device पर restore हो सकती है। पर end-to-end encrypted vault restore करने को account का password भर नहीं, पिछले terminal का screen lock (passcode) डालना जैसी extra identity verification चाहिए; ये recovery means भी खोएँ तो restore न हो सके। सब कुछ एक फ़ोन पर न सौंपना महत्वपूर्ण है। Device-bound type (security key, Windows Hello आदि) terminal की नियति share करते हैं, इसलिए महत्वपूर्ण accounts पर कई passkeys register रखना नियम है। अधिकतर services एक account पर कई passkeys register करने देती हैं। खोने पर invalidate करना type से प्रक्रिया बदलता है। Synced type में प्रत्येक device की copy एक ही credential है, इसलिए पहले platform account पर खोए terminal हटाना या remote wipe कर terminal की copy बेकार करें (service के account settings में वह passkey हटाएँ तो सब devices की copy एक साथ invalidate होती है)। Device-bound हो तो service पक्ष उस authenticator की passkey हटाकर खोई key मात्र invalidate कर सकते हैं। संगठन में «user स्वयं recover कर सके redundancy» और «खोने पर admin revoke करे प्रक्रिया» एक सेट design करना महत्वपूर्ण है।

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

हैं। पर कमजोरी का स्थान बदलता है, यही सही कहना है। Authentication स्वयं public-key cryptography से मज़बूत होता है, इसलिए attacker कमज़ोर periphery निशाना बनाते हैं। ठोस: password या SMS जैसे traditional means साथ रहें तो वही सबसे कमज़ोर कड़ी; account recovery flow misuse कर attacker अपनी passkey register कराने की चाल; synced type में cloud account स्वयं का takeover नया single point of failure। साथ login बाद session cookie चुराना passkey नहीं रोकती, इसलिए unrelated threats गायब नहीं होते। Implement करते «passkey जोड़ना» भर नहीं, recovery flow harden करना और fallback means नियोजित घटाना तक design चाहिए।

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

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

Go Komura

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

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