Passkeys के बारे में सपना क्यों टूटा
सपना
- 2019 में लेखक ने Rust के लिए Webauthn लाइब्रेरी का विकास शुरू किया
- उस समय आशावाद था कि यह तकनीक पासवर्ड की जगह ले सकती है
- उम्मीद थी कि यह 2-फैक्टर ऑथेंटिकेशन, passwordless authentication, username-less authentication आदि को सपोर्ट कर सकेगी
- लेखक द्वारा विकसित लाइब्रेरी का इंडस्ट्री पर बड़ा प्रभाव पड़ा
चेतावनी संकेत
- Chrome बाजार पर हावी है, इसलिए यदि Chrome किसी चीज़ को सपोर्ट नहीं करता तो उसके standard से बाहर होने की समस्या है
- Authenticator Selection Extension इसका प्रतिनिधि उदाहरण है
- अमेरिका में होने वाली आमने-सामने की बैठकों में प्रमुख निर्णय लिया जाना भी एक समस्या है
- इससे अंतरराष्ट्रीय प्रतिभागी बाहर रह जाते हैं
गिरावट
- 2022 में Apple ने Passkeys की घोषणा की
- शुरुआत में यह अच्छी तरह डिज़ाइन किया गया लगा, लेकिन बाद में एक नेता की घोषणा के कारण Passkey को Resident Key के रूप में परिभाषित किया गया
- इसका नतीजा यह हुआ कि कम स्टोरेज स्पेस वाली security keys बाहर हो गईं
- इसके बाद Passkey उपयोगकर्ताओं को platform में बंद करने के साधन में बदल गया
बिगड़ती स्थिति
- Chrome और Safari, security keys की जगह caBLE के इस्तेमाल पर जोर देते हैं
- यह उपयोगिता के लिहाज़ से बहुत खराब तरीका है
- Android, Passkey सपोर्ट करने वाली वेबसाइटों पर security keys के इस्तेमाल को रोकता है
- developer examples भी केवल Google Passkey इस्तेमाल करने की ओर ले जाते हैं
- उपयोगकर्ताओं को Passkey इस्तेमाल करने में बहुत कठिनाइयों का सामना करना पड़ रहा है
- bugs, जटिल प्रक्रिया, key खो जाने जैसी समस्याएँ सामने आ रही हैं
- Apple Keychain में Passkey के delete हो जाने की घटनाएँ बार-बार होती हैं
आगे की तस्वीर
- लेखक का अनुमान है कि Passkey आम उपभोक्ताओं के लिए असफल होगा
- कंपनियों के मुनाफ़ा-केंद्रित रवैये के कारण user experience खराब हो रहा है
- यहाँ तक कि लेखक के पार्टनर का कहना है कि पासवर्ड तरीका Passkey से बेहतर है
- एंटरप्राइज़ में अब भी security keys की ज़रूरत है, लेकिन usability की समस्या बनी हुई है
- लेखक webauthn-rs प्रोजेक्ट को जारी रखेंगे, लेकिन Passkey की जगह दूसरे विकल्प तलाश रहे हैं
GN⁺ की राय
- यह चिंताजनक है कि Passkey, security keys को बाहर करते हुए platform dependence को और गहरा करने की दिशा में जा रहा है। उपयोगकर्ताओं की पसंद की स्वतंत्रता को सीमित करना उचित नहीं लगता।
- तकनीक को आगे बढ़ाने के साथ-साथ usability में सुधार भी ज़रूरी लगता है। यह ज़रूरत से ज़्यादा जटिल या सीमित नहीं होना चाहिए।
- कुछ कंपनियों का प्रभाव बढ़ने से standardization प्रक्रिया में समस्याएँ पैदा होना भी ऐसा मुद्दा है जिसे तुरंत सुलझाने की ज़रूरत दिखती है। अधिक खुली और पारदर्शी निर्णय-प्रक्रिया बननी चाहिए।
- विकल्प के तौर पर सुझाए गए device certificates या smartcard तरीके दिलचस्प लगते हैं। ये मौजूदा Passkey की सीमाओं को पार करते हुए usability बेहतर करने का तरीका बन सकते हैं।
- चूँकि यह अभी संक्रमणकालीन चरण में है, आगे भी लगातार तकनीकी विकास और user feedback को शामिल किया जाना चाहिए। उम्मीद है कि अलग-अलग हितधारक मिलकर बेहतर authentication framework बनाएँगे।
3 टिप्पणियां
पासवर्ड-रहित भविष्य आ रहा है
Chrome में Passkey का परिचय
Hacker News राय
Passkeys के साथ सबसे बड़ी समस्या यह है कि उन्हें उपलब्ध कराने वाली कंपनियों पर भरोसा नहीं किया जा सकता। सुरक्षा कारणों से वे platform में बंद रहते हैं, लेकिन कई बार यह platform lock-in से अलग नहीं लगता। अगर आप Apple डिवाइस पर Passkey बनाते हैं, तो वह उस डिवाइस से कभी बाहर नहीं जा सकता और इसे बदलने का भी कोई तरीका नहीं है। यह phishing से सुरक्षित है, लेकिन अगर Apple key हटा दे या आप iPhone छोड़ना चाहें, तो क्या होगा यह स्पष्ट नहीं है.
Passkeys पर लंबी चर्चा में सुरक्षा के "जो आप जानते हैं" वाले हिस्से से एक अजीब तरह की बचने की प्रवृत्ति दिखती है। अमेरिका में अदालतें और law enforcement उपयोगकर्ता नाम, उंगलियों के निशान, retina scan, Face ID आदि कानूनी रूप से प्राप्त कर सकती हैं, लेकिन उन्हें आपके दिमाग से कुछ निकालने का अधिकार नहीं है। Passkeys "जो आप जानते हैं" को "जो आपके पास है" से बदलने को प्राथमिकता देते हैं, और यह सुरक्षा के लिए एक दुःस्वप्न है.
विपरीत राय: मुझे Passkeys बहुत पसंद हैं। मैं Firefox browser और 1Password manager इस्तेमाल करता हूँ, और iPhone पर 1Password + Firefox उपयोग करता हूँ। passkeys.directory देखकर मैंने GitHub, Google, Microsoft आदि की login को Passkeys में बदल दिया। "Passkey से login" की जगह "Touch ID से login" जैसे शब्द भ्रमित करते हैं। 1Password डिवाइसों के बीच Passkeys sync करता है। अगर public computer पर login करना पड़े तो यह असुविधाजनक हो सकता है, लेकिन ऐसा मैं बहुत कम करता हूँ.
Passkeys से अभी बच रहा हूँ क्योंकि इनके लिए कोई साफ mental model नहीं है। मैं पहले से password manager द्वारा बनाए गए random passwords इस्तेमाल कर रहा हूँ, इसलिए बदलने की ज़रूरत महसूस नहीं होती। username/email + password समझ में आता है, लेकिन "app-specific password" वाली परेशानी याद है, इसलिए चिंता है कि कुछ open source/CLI tools शायद Passkeys के साथ अच्छे से integrate न हों। स्थिति स्थिर होने तक इंतज़ार करना बेहतर लगता है.
मैंने Apple Keychain ecosystem में पूरी तरह निवेश किया है और मेरे पास कई Apple डिवाइस हैं, इसलिए Passkeys शानदार हैं। एक developer के रूप में मैं हर दिन कमजोर SMS 2FA की सीमाएँ देखता हूँ। users को आसानी से social engineering के जरिए धोखा देकर 2FA code दिलवाया जा सकता है। Passkeys अधिक सुरक्षित समाधान देते हैं, इसलिए developer को यह चिंता नहीं करनी पड़ती कि user CS को फोन करके code ज़ोर से पढ़ देगा। SIM swapping से Passkey प्रभावित नहीं होता, और Passkey को किसी ठग के साथ साझा भी नहीं किया जा सकता.
एक तकनीकी व्यक्ति होने के बावजूद मुझे ठीक से नहीं पता कि Passkeys कैसे काम करते हैं, क्यों बेहतर हैं, या वास्तव में क्या हैं। अगर कोई security feature उतना सरल नहीं है जितना username और password याद रखना और उन्हें सुरक्षित जगह पर रखना, तो वह काम नहीं करेगा। डिवाइस पर मौजूद key का ज़िक्र होता है, लेकिन अगर कोई phone और PC दोनों इस्तेमाल करता है तो उसे access कैसे किया जाता है, क्या शुरुआत में username/password चाहिए, या क्या कोई ऐसा key चाहिए जिसे डिवाइस में plug in करना पड़े — यह सब सवाल हैं.
Usernameless थोड़ा ज़्यादा optimization जैसा लगता है। login के समय user का username इस्तेमाल करना उचित और अच्छी बात है। इससे यह याद रहता है कि कौन सा username उपयोग हो रहा है। ऐसा हो सकता है कि कोई user Usernameless Passkey से किसी service में access ले रहा हो, फिर किसी कारण से Passkey खो दे और service का username भी भूल जाए, जिससे account recovery process शुरू ही न कर सके.
जो लोग Passkeys की तकनीकी कार्यप्रणाली नहीं जानते, वे यह implementation guide देख सकते हैं: https://webauthn.guide/ Passkeys के प्रति इतनी नफरत समझ नहीं आती। authentication के लिए public-key challenge की ओर जाना web security के लिए एक बड़ा कदम है। हर browser/OS private key को सुरक्षित रखता है और उसका backup भी करता है। अगर key खो भी जाए, तो "password reset" flow का उपयोग करके authentication credential फिर से सेट किया जा सकता है.
Passkeys के उपयोग पर विचार करने के लिए ये शर्तें पूरी होनी चाहिए:
मैंने यह जाँच नहीं की कि Firefox या Linux के Chrome में WebAuthn implementation इन आवश्यकताओं को पूरा करता है या नहीं.
मैं 2FA क्षेत्र में हो रही प्रगति को follow करने की कोशिश कर रहा हूँ, और Passkeys सबसे अधिक भ्रमित करने वाले रहे। Passkeys को next-generation technology बताने वाला बहुत hype देखा, लेकिन यह वास्तव में क्या हैं और कैसे काम करते हैं, इसकी स्पष्ट व्याख्या मिलना मुश्किल था। जब पता चला कि ये security key में संग्रहीत key हैं, तो निराशा हुई। domain name के आधार पर तुरंत key generate करने का विचार मुझे पसंद है। Passkeys का लाभ यह है कि website पर इस्तेमाल होने वाला username याद रखने की ज़रूरत नहीं रहती, लेकिन यह एक छोटा लाभ है।
domain name के आधार पर keys को तुरंत calculate और reconstruct करने वाली technology (FIDO2-based? WebAuthn-based?) का आधिकारिक नाम क्या है — इस संबंधित प्रश्न का उत्तर मुझे यहाँ मिला: https://fy.blackhats.net.au/blog/… तुरंत पुनर्निर्मित की गई key को "non-resident credential" कहा जाता है.