Passkey में अभी भी समस्याएँ हैं

• 2025 में भी Passkey सुरक्षा और सुविधा पर बहस के बीच अब भी user experience और vendor lock-in की समस्याएँ लेकर चल रहा है
• नया FIDO Credential Exchange providers के बीच migration संभव बनाता है, लेकिन platforms के बीच friction और fragmentation की समस्या अब भी बनी हुई है
• Apple, Google, Microsoft जैसे platform managers के साथ backup न कर पाने और lockout के जोखिम जारी हैं, और user choice को सीमित करने वाले UI design की भी आलोचना हो रही है
• Passkey की अवधारणा की जटिलता और services की भ्रामक communication आम users का भरोसा कम करती है
• महत्वपूर्ण accounts की सुरक्षा के लिए self-controlled Credential Manager और Yubikey जैसी hardware key का उपयोग महत्वपूर्ण है

---

TL;DR सारांश

• Passkey में अभी भी कमियाँ मौजूद हैं, और users को इन्हें समझकर अपनी जरूरतों के अनुसार इस्तेमाल करना चाहिए
  • केवल platform providers (Apple, Google, Microsoft) के Credential Manager का उपयोग करने पर backup न कर पाने और lockout का जोखिम रहता है
  • Bitwarden, Vaultwarden जैसे backup-सक्षम Credential Manager के उपयोग की सिफारिश की जाती है
  • FIDO Credential Exchange के जरिए बाहरी Credential Manager में नियमित sync करना आवश्यक है
  • email जैसे महत्वपूर्ण accounts के लिए Yubikey को passkey store के रूप में उपयोग करें, और मजबूत password + TOTP को सहायक साधन के रूप में बनाए रखें
  • Credential Manager तक पहुँच न होने की स्थिति में recovery path को पहले से जाँच लेना चाहिए

पिछले 1 वर्ष में हुए बदलाव

• सबसे बड़ा बदलाव FIDO Credential Exchange specification का परिचय है
  • इसके जरिए passkey providers के बीच credentials को स्थानांतरित करना संभव हुआ है
• लेकिन platforms के बीच friction और ecosystem fragmentation अब भी मौजूद है
  • अलग-अलग devices के बीच passkeys fragmented हो सकती हैं, और users को इसका पता भी न चले
  • Apple devices की passkeys non-Apple devices पर sync नहीं हो सकतीं, जबकि Google और Microsoft में कुछ हद तक यह संभव है
  • Apple users को और अधिक lock-in महसूस हो सकता है

Passkey की अवधारणा की जटिलता

• password को “जो मैं जानता हूँ” और SMS 2FA को “जो मैं प्राप्त कर सकता हूँ” के रूप में सहज रूप से समझा जा सकता है
• इसके विपरीत passkey एक अदृश्य authentication factor है, जिसे user सीधे देख, जाँच या print नहीं कर सकता
• Credential Manager पर भरोसा करने की प्रक्रिया जरूरी होती है, लेकिन passkey इस trust step को छलांग लगा देता है
• यहाँ तक कि security experts भी passkey के काम करने के तरीके को लेकर भ्रमित हो जाते हैं, इसलिए इसे समझने की बाधा ऊँची है

‘thought leadership’ और user education की समस्या

• उद्योग के कुछ लोग कहते हैं कि “password management सीखना industry की विफलता है”,
  लेकिन वास्तव में passkey के लिए भी Credential Manager की समझ जरूरी है
• password और TOTP को पसंद करने वाले users ऐसा घमंड से नहीं बल्कि usability की समस्या के कारण कर सकते हैं
• यह मानना कि passkey बिना user education के भी काम कर जाएगा, वास्तविकता से कटा हुआ दृष्टिकोण है
• अगर user पर्याप्त समझ के बाद भी passkey की बजाय दूसरा तरीका चुनता है, तो उस user के लिए passkey विफल है

अब भी कायम vendor lock-in

• FIDO Credential Exchange होने के बावजूद, वास्तविक उपयोग के दौरान friction और UI-driven design switching cost को बढ़ा देते हैं
• Apple का passkey creation modal डिफ़ॉल्ट रूप से Apple Keychain के उपयोग की ओर ले जाता है,
  जबकि दूसरे विकल्प (security key, Android आदि) ‘Other Options’ में छिपे रहते हैं
• user की पसंद याद नहीं रखी जाती, और हर बार फिर डिफ़ॉल्ट विकल्प पर लौट आती है
• Google Chrome में भी इसी तरह की संरचना है, जो platform ecosystem में बनाए रखने की दिशा में प्रेरित करती है
• यह सिर्फ storage location का मुद्दा नहीं, बल्कि पूरे user experience में निर्भरता पैदा करता है

cloud keychain data loss

• Apple Keychain से passkeys गायब हो जाने, या Android devices पर उन्हें create/use न कर पाने के मामले जारी हैं
• कुछ मामलों में device reset के बाद भी recovery संभव नहीं होती, और user का account access पूरी तरह बंद हो जाता है
• ऐसी समस्याएँ passkey पर भरोसा कम करती हैं

vendors द्वारा account lockout

• Apple account lockout के मामलों में सभी passkeys recovery के बाहर जाकर समाप्त हो गईं
• Google और Microsoft में भी ऐसे ही मामले मौजूद हैं
• एक ही account action के कारण सभी credentials नष्ट होने का जोखिम हो सकता है

authentication services की भ्रामक communication

• कुछ services यह समझाती हैं कि “passkey face/fingerprint data भेजता है”
• वास्तव में biometric data device के बाहर नहीं जाता,
  लेकिन आम user इसे ‘चेहरा/फिंगरप्रिंट इंटरनेट पर भेजा जा रहा है’ के रूप में गलत समझ सकता है
• ऐसे विवरण passkey के प्रति अविश्वास और असहजता पैदा करते हैं
• platform providers के UI भी इन गलतफहमियों को दूर नहीं कर पाते

user choice को सीमित करने वाली authentication services

• कुछ websites अब भी केवल एक passkey की अनुमति देती हैं, या
  authenticatorAttachment option के जरिए सिर्फ platform-bound passkey को मजबूर करती हैं
• इससे security key या non-platform Credential Manager का उपयोग रुक जाता है
• कुछ sites login के समय पूर्व सहमति के बिना auto passkey registration की कोशिश करती हैं, जो अनैतिक व्यवहार है

निष्कर्ष और सिफारिशें

• अधिकतर समस्याएँ platform providers-केंद्रित passkey management structure से पैदा होती हैं
• users को self-controlled Credential Manager के जरिए
  account lockout और data loss के जोखिम को कम करना चाहिए और नियमित backup करना चाहिए
• Yubikey (firmware 5.7 या उससे ऊपर) में अधिकतम 150 passkeys store की जा सकती हैं
  • कुछ accounts में यह software Credential Manager का विकल्प बन सकता है
• email account recovery path का केंद्र है, इसलिए
  hardware key + मजबूत password + TOTP का साथ में उपयोग करें और offline backup बनाए रखें
• Apple, Google जैसे platforms को user की पसंद याद रखनी चाहिए और
  security key और अन्य providers के विकल्प UI में समान रूप से देने चाहिए
• developers को WebAuthn API की pre-filtering से बचना चाहिए,
  और passkey registration से पहले users को स्पष्ट रूप से सूचित करना चाहिए
• मूल सिद्धांत user control और consent सुनिश्चित करना है

[roxie]

मुझे passkey पसंद हैं,,

[yeobi222]

अगर यूज़र सुरक्षा ढांचे की संरचना को समझ ही न पाएँ, तो उससे सिर्फ़ अविश्वास ही बढ़ेगा
यह भी नहीं कहा जा सकता कि इसकी usability अपने-आप में अच्छी है

[koxel]

मैंने एक बार Google Password Manager को डिलीट किया था, तो सब कुछ उड़ गया। उसके बाद फिर से जारी करवाने के बाद मैं bitwarden पर चला गया..

[GN⁺]

Hacker News की राय

• लेखक अभी भी passkey को लेकर गलतफहमी में है। बहुत से लोग सोचते हैं कि passkey खो जाए तो रिकवरी असंभव है, लेकिन असल में यह पासवर्ड खोने जैसा ही है। ज़्यादातर services में email या SMS से password reset किया जा सकता है। लेकिन Apple, Google, Facebook जैसे accounts की recovery प्रक्रिया जटिल होती है, इसलिए backup codes को प्रिंट करके सुरक्षित रखना चाहिए। साथ ही password manager में login करने के लिए आख़िरी password या YubiKey जैसे बाहरी साधन की भी ज़रूरत होती है

  • सोच रहा हूँ कि passkey आने से पहले भी Apple और Google accounts में lockout problem थी या नहीं। अभी passkey को user खुद backup या export नहीं कर सकता, और security engineers ने सिर्फ key cloning prevention पर ध्यान दिया है, जिसकी वजह से अरबों लोग lockout risk में हैं। यह approach regulatory risk भी पैदा कर सकती है
  • passkey को reset किया जा सकता है या नहीं, यह service provider implementation पर निर्भर करता है। कहीं-कहीं सिर्फ phone call से recovery होने की शिकायत भी थी
  • Apple और Google accounts में बाकी ज़्यादातर passwords और passkeys stored होते हैं, इसलिए इन्हें खोना कहीं ज़्यादा गंभीर समस्या है
  • passkey हर device पर स्वतंत्र रूप से मौजूद होता है, और इसे हर device पर सेट करना ज़रूरी नहीं है। दूसरे devices पर बस password से login किया जा सकता है

• passkey में मैं दो चीज़ें बेहतर देखना चाहता हूँ.

  1. registered device सिर्फ एक होने पर भी UI बेकार के options दिखाता है
  2. अगर शुरुआत से इसमें SSH key जैसी portability और flexibility होती तो बेहतर होता। अभी vendor dependency बहुत ज़्यादा है
  • Mac में security key button पहले दबाकर selection step को skip किया जा सकता है
  • options को छिपाने के बजाय greyed out दिखाना चाहिए और “registered key नहीं है” बताना चाहिए। तभी user को समझ आएगा कि समस्या क्या है
  • passkey system को phishing-proof बनाने के लिए इस तरह design किया गया है कि user credentials को खुद export न कर सके। नतीजा आखिरकार vendor lock-in ही है। उदाहरण के लिए Safari में passkey इस्तेमाल करने के लिए iCloud Keychain अनिवार्य है, इसलिए local-only use संभव नहीं है
  • जो users तकनीक से ज़्यादा परिचित नहीं हैं, उनके लिए passkey अच्छा विकल्प हो सकता है। लेकिन recovery code को कागज़ पर लिखकर सुरक्षित रखने में उनकी मदद करनी चाहिए

• KeePass से जुड़ा issue देख कर लगता है कि industry में users के private key export को रोकने का दबाव बढ़ रहा है। यह चिंताजनक है
  संबंधित GitHub issue

  • उस issue में comment लिखने वाला मैं ही हूँ। default रूप से encrypted backup की माँग करना export को रोकना नहीं है, बल्कि user को key पर सीधा control देना है

• जब तक service providers passkey storage के तरीके (hardware/software) को force कर सकते हैं, या Touch ID जैसी MFA को अनिवार्य बना सकते हैं, तब तक मैं password + TOTP को ही prefer करूँगा

  • (1) यह पहले से ही संभव नहीं है। service passkey storage method को force नहीं कर सकती
  • (2) यह MFA नहीं बल्कि biometric verification (liveness check) के ज़्यादा क़रीब है। यह बस साबित करता है कि login करते समय कोई असली इंसान मौजूद है
  • emergency situation में manual input वाली backup method चाहिए। आखिर में बात फिर पासवर्ड जैसी ही किसी चीज़ पर लौट आती है

• मैं passkey कभी इस्तेमाल नहीं करूँगा क्योंकि “vendor user को lock कर सकता है”। खासकर user की मौत के बाद heirs access नहीं कर पाएँ, यह बहुत बड़ी समस्या है

  • इससे जुड़े उदाहरण हैं: Apple ID recovery failure case, HN discussion
  • कुछ password managers offline root of trust देते हैं। उदाहरण के लिए 1Password का Emergency Kit प्रिंट किए गए recovery code के ज़रिए heirs या family को access दे सकता है
  • password हो या passkey, अगर vendor policy एक जैसी है तो access restriction भी एक जैसी ही होगी
  • अच्छा होता अगर ऐसे contract को legal trust के रूप में बदला जा सकता, लेकिन कंपनियाँ शायद ऐसा नहीं चाहेंगी
  • passkey registration को force करने वाला dark pattern UI बहुत परेशान करता है। सिर्फ company account के लिए इस्तेमाल करने पर भी बार-बार register करने को कहता है। पहले से SSO और 2FA इस्तेमाल कर रहा हूँ, फिर भी passkey क्यों चाहिए समझ नहीं आता

• passkey का UX बहुत ख़राब है। कितने active हैं यह भी नहीं पता चलता, और कभी-कभी authenticator app passkey को भूल भी जाता है। सब कुछ बस उलझाऊ है

• Password + TOTP अभी भी सबसे practical combination है। devices के बीच जाना हो तो बस Bitwarden login काफ़ी है। दूसरी तरफ passkey में device खोने पर recovery process साफ़ नहीं है। iPhone पर सेट किया गया passkey Linux desktop पर क्यों काम करता है, यह भी स्पष्ट नहीं है। यह सिर्फ single-platform users के लिए फ़ायदेमंद लगता है

  • अगर कई devices register किए हों या sync चालू हो तो recovery संभव है, नहीं तो account recovery process के अलावा कोई रास्ता नहीं। आखिरकार यह पासवर्ड से बेहतर नहीं है

• अंत में passkey ज़रूरत से ज़्यादा जटिल design है। lock-in स्वीकार कर लो तो कुछ समस्याएँ कम होती हैं, लेकिन नई सीमाएँ पैदा हो जाती हैं। TOTP एक व्यावहारिक विकल्प है

  • TOTP झंझट वाला है, लेकिन इसमें user control होता है। इसी वजह से मैंने अपना LazyOTP Chrome extension बनाया, ताकि इसे single authentication की तरह इस्तेमाल कर सकूँ

• passkey ज़्यादातर आम users के लिए बेहतरीन solution है। यह जटिल password management और password reuse की समस्या खत्म करता है, और login process भी आसान बनाता है.
  तकनीकी समझ रखने के बावजूद भी मुझे तेज़ और seamless login experience कहीं बेहतर लगता है

  • लेकिन अगर device खो जाए या खराब हो जाए तो सभी accounts का access रुक सकता है। कागज़ पर लिखा पासवर्ड में यह समस्या नहीं होती
  • passkey का सबसे बड़ा फ़ायदा phishing resistance है। गलत domain पर credentials submit ही नहीं किए जा सकते
  • लेकिन PC और phone के बीच secret key sync process स्पष्ट नहीं है। आखिर में यह पूरी तरह Apple ecosystem से बँधा हुआ लगता है
  • अभी तक मैंने ऐसा implementation नहीं देखा जो कई platforms पर पूरी तरह seamless तरीके से काम करे

• मैंने पहले से password manager और 2FA system तैयार कर रखा था, लेकिन अब passkey पर shift करने का जो दबाव है उससे लगता है कि वह सारी मेहनत बेकार हो गई। मुझे ऐसा tech environment पसंद नहीं जिसमें पहले से तैयारी करने वाले लोगों को ही नुकसान उठाना पड़े