Passkeys credential phishing रोकते हैं, पर recovery, shared counters और fallback policy भी सही चाहिए। “Phishing-proof” वादों के बिना गाइड।
लेखक
Anichur Rahaman
दोपहर को payroll होना है। सुबह 8:50 पर finance lead पाती है कि उसका एकमात्र enrolled sign-in device गायब है। Help desk के पास भरोसेमंद लगने वाला caller और deadline है, सहमत recovery procedure नहीं। यह काल्पनिक business scene है, हर कंपनी में ऐसा होने का दावा नहीं।
Passkey login से reusable password हटा सकता है। वह तय नहीं करता कि caller वास्तव में finance lead है या emergency payroll approve कर सकता है। ये recovery और business permission के निर्णय हैं।
इसलिए सिर्फ “क्या staff passkey register कर सकता है?” नहीं, पूछें: “Loss के बाद सही व्यक्ति access पाए और impersonator न पाए, यह कैसे होगा?” Enforcement से पहले वह दिन तैयार करें।
FIDO passkey overview public-key sign-in समझाता है: service reusable password के बजाय private key से बना proof verify करती है। Local unlock biometric या PIN से हो सकता है।
Phishing resistance authentication को intended relying party से बाँधने से आती है। Look-alike site password/OTP की तरह typed passkey लेकर relay नहीं कर सकता। WebAuthn RP-ID scope और origin validation इस्तेमाल करता है, एक exact page URL का नियम नहीं।
“Phishing-resistant” को “phishing-proof” न बनाएं। Malware, stolen session, weak recovery, unlocked shared device या excessive permissions नुकसान कर सकते हैं। Public keys होने से breached system के बाकी customer data और sessions harmless नहीं बनते।
Key छूकर presence दिखाना PIN/biometric से user verification नहीं। Protected action की authentication strength लागू करें, जहाँ जरूरी user verification सहित। Successful login हर permission नहीं देता; payroll approval, export और bank change के controls अलग रहें।
Synced passkey replacement आसान कर सकता है; device-bound credential specific hardware पर key रखने की जरूरत पूरी कर सकता है। Label पूरा login assurance साबित नहीं करता। Table buying/policy aid है, compliance certificate नहीं।
NIST syncable-authenticator guide exported keys की protection माँगता है। Synced private key protected form में copy हो सकती है; पहली device कभी नहीं छोड़ती कहना गलत है।
NIST SP800-63B-4 qualifying synced authenticators AAL2 में मानता है, AAL3 में नहीं। Level के लिए सभी applicable controls चाहिए; hardware key खरीदना पर्याप्त नहीं।
High-impact account में अलग सुरक्षित रखा approved hardware backup और tested recovery सोचें। एक sync account पर दो devices दो independent recovery systems नहीं। Provider account recovery भी सुरक्षित रखें।
Microsoft current Entra FAQ synced copies रखने वाले devices देखने/नियंत्रित करने की सीमा बताता है। Provider controls जाँचें; device list को हर copy की सूची न मानें।
| विकल्प | उपयोगी गुण | क्या जाँचें |
|---|---|---|
| Synced Passkey | Approved provider devices पर मिल सकता है | Provider recovery, sharing/visibility limits और policy |
| Device-bound Credential | उस model में sync नहीं होता | Hardware, user verification, compatibility और spare |
| Backup/Recovery Route | Loss पर legitimate access लौटाता है | Independent dependencies, verification और privileges |
Policy में स्वीकार pre-enrolled alternative credential से शुरू करें। Incident से पहले test करें और main device से अलग रखें। Approved method बचा हो तो उससे login और documented replacement करें; unauthenticated caller को नया credential न दें।
कोई method न रहे तो account risk के अनुसार defined recovery लें। NIST recovery guidance recovery methods और notification अलग करता है। परिचित आवाज, manager message या video call अकेला impersonation के विरुद्ध भरोसेमंद proof नहीं।
Saved recovery codes supported हों तो सुरक्षित offline और primary device से अलग रखें। Allowed use व replacement test करें; used code permanent backup access नहीं।
Help desk को पहले स्थापित information/channels पर documented verification, escalation और restricted reset power दें। Replacement enrolment सुरक्षित करें, established channels पर notify और event review करें। Risk policy माँगे तो extra approvals/temporary restrictions रखें; payroll urgency में bypass न गढ़ें।
Lost-device management, app credential revocation और session revocation अलग काम हैं। Cloud account से device हटाना app sessions हटाना नहीं। App में synced credential revoke करने से उसकी सभी copies बंद हो सकती हैं; एक device delete करना बाकी copies invalid साबित नहीं करता। Identity/provider admin के साथ हर control का असर test करें।
Compromise शक हो तो replacement की प्रतीक्षा किए बिना incident procedure से contain करें। Identity स्थापित न हो तो account restricted और escalation रखें। Continuity में पहले से authorised alternate approver और duty separation हो सकता है; locked-out user बनना उचित नहीं।
Shared terminals पर individual accounts और handover में previous session समाप्त करें। Shared browser/provider profile में personal synced credential न रखें जिसे सहकर्मी इस्तेमाल कर सकें। OS profiles, kiosk, auto lock, peripherals तथा phone/Bluetooth policy जाँचें।
Approved hardware key या supported cross-device login मदद कर सकता है; actual terminal/browser test करें। Existing POS session में short cashier PIN अपने-आप WebAuthn passkey या phishing-resistant MFA नहीं। उसका सीमित purpose/permission समझें, high-assurance login का बराबर नहीं।
Contractors के scoped personal account, end date और offboarding में access/sessions revoke हों। Role change पर भी यही। Physical key वापस लेना पर्याप्त नहीं यदि app account, sync provider या active session access देता रहे।
Supported browsers, devices, identity providers, recovery channels और accessibility needs सूचीबद्ध करें। Requirement bypass करने वाले password, email link, TOTP, SMS, help-desk reset, legacy client और persistent session लिखें। Protected routes पर strength लागू करें, केवल enrolment reminder नहीं।
Supported group और accountable owners से शुरू करें। High-impact roles प्राथमिक हों, पर admin backup enforcement से पहले tested हो। Enrolment, normal login, lost device/backup, wrong domain, weak fallback, recovery impersonation, stolen-session response, counter handover और contractor removal approved test environment में जाँचें।
TOTP या email/SMS recovery transitional policy का हिस्सा हो सकते हैं, पर बराबर phishing-resistant विकल्प नहीं। Sensitive route weaker fallback पर समान privilege दे तो उस method का exposure रहता है। Limits, monitoring और retirement तय करें; enrolment अकेला blanket upgrade नहीं।
Customers को clear accessible adoption और usable recovery दें। Checkout में untested enrolment demand न थोपें। Business requirements अलग हो सकती हैं; हर account पर एक rule के बजाय पूरा journey साबित करें।
शिक्षण pilot में 40 staff में 32 enrolled हों तो 80% enrolment। उन्हीं 40 में 18 protected app में password alone से जा सकें तो अलग exposure 45%। Groups overlap कर सकते हैं। कोई संख्या बाकी accounts में weaker route न होने का प्रमाण नहीं।
Required method का successful use, device/browser failures, recovery completion/misuse, lockouts, active fallback permissions और support effort मापें। Cohort और period बताएं। Consumer-service benchmarks को अपनी speed या help-desk saving का वादा न बनाएं।
Payroll सुबह में उपयोगी evidence है: approved spare काम करे, impersonation fail हो, sessions/credentials contain हों और unresolved legitimate case owner तक पहुँचे। Ready कहने से पहले यह पूरा करें। Passkey access system का मजबूत हिस्सा है; recovery और permissions भी साथ टिकें।
समीक्षा: 5 नवंबर 2026। Anichur Rahaman StoreConsole के निर्माता हैं। Company और pilot figures उदाहरण हैं; actual app और provider capabilities जाँचें।
लेखक का परिचय
Anichur Rahaman
पढ़ना जारी रखें
