पासकीज़ एक जाल हैं
पासकीज़—public-key cryptography पर आधारित लॉगिन क्रेडेंशियल्स, जिन्हें अक्सर Apple, Google, या password managers के साथ sync किया जाता है—को passwords और TOTP codes की तुलना में कहीं अधिक phishing-resistant और रोज़मर्रा के login UX को बहुत बेहतर बनाने के लिए सराहा जाता है। लेकिन आलोचकों का कहना है कि WebAuthn/FIDO standards “attested” passkeys को सक्षम करते हैं जो विशिष्ट hardware और OS stacks से जुड़े होते हैं; साइटें भविष्य में इन्हें अनिवार्य भी कर सकती हैं, जिससे उपयोगकर्ता बड़े platforms में lock-in हो जाएंगे और FOSS या non-approved devices बाहर हो सकते हैं। कई लोगों की नज़र में आज की सुविधाजनक, copyable passkeys एक संभावित Trojan horse हैं: अभी सुरक्षित और उपयोगी, लेकिन अगर attestation व्यापक रूप से लागू हुआ तो भविष्य में vendor control और कम user freedom का वास्तविक जोखिम मौजूद है।
पासकीज़ के कथित लाभ
- पासकीज़ के लिए फ़िशिंग‑प्रतिरोधी होने का मजबूत समर्थन: कुंजियाँ डोमेन‑बाउंड होती हैं, कभी ट्रांसमिट नहीं होतीं, और चोरी हुए सर्वर डेटाबेस से केवल पब्लिक कीज़ लीक होती हैं।
- बहुत से लोग इन्हें पासवर्ड+TOTP/SMS की तुलना में UX के लिहाज़ से कहीं बेहतर मानते हैं: “एक क्लिक और अंदर”, कोड टाइप करने की ज़रूरत नहीं, पासवर्ड जटिलता नियम नहीं, पासवर्ड दोहराने की समस्या नहीं।
- समर्थक बताते हैं कि ये मूलतः ब्राउज़र/OS UX में लिपटे “SSH‑style” पब्लिक की ऑथ हैं, जो उन समस्याओं को हल करते हैं जिन्हें यूज़र कभी मैन्युअली नहीं संभालेंगे।
- हार्डवेयर टोकन (FIDO/U2F keys, Yubikeys) और पासवर्ड‑मैनेजर‑समर्थित पासकीज़ को मज़बूत सुरक्षा के साथ कुछ यूज़र नियंत्रण देने के लिए सराहा जाता है।
मुख्य चिंताएँ: attestation, नियंत्रण, और “trap” फ्रेमिंग
- केंद्रीय चिंता: WebAuthn/Passkey स्पेसिफिकेशन्स remote attestation को सपोर्ट करती हैं, जिससे साइटें हार्डवेयर‑आधारित, नॉन‑एक्सपोर्टेबल, प्लेटफ़ॉर्म‑स्वीकृत क्रेडेंशियल्स की मांग कर सकती हैं।
- डर यह है कि एक बार पासकीज़ व्यापक रूप से अपनाई गईं, तो बड़े साइट्स (खासकर बैंक, स्ट्रीमिंग, सोशल) “स्विच पलट” देंगे और:
- गैर‑attested या सॉफ़्टवेयर‑मैनेज्ड पासकीज़ (Bitwarden, KeePassXC, आदि) को अस्वीकार करेंगे।
- FOSS डिवाइस, कस्टम ROM, rooted/bootloader‑unlocked फ़ोन, और non‑standard OSes को बाहर कर देंगे।
- कई लोग इसे व्यापक “trusted computing / secure boot / DRM / device attestation” प्रवृत्ति का हिस्सा मानते हैं, जो यूज़र नियंत्रण घटाती है।
- अन्य लोग तर्क देते हैं कि यह चिंता बढ़ा‑चढ़ाकर कही जा रही है: attestation पुरानी enterprise तकनीक है, consumer scale पर चलाना कठिन है, और फिलहाल कुछ बड़े प्लेटफ़ॉर्मों में इसका उपयोग नहीं होता या यह समर्थित भी नहीं है।
सुरक्षा तुलना: TOTP, SMS, passwords, hardware keys
- TOTP:
- फ़ायदा: यूज़र‑नियंत्रित, पोर्टेबल, किसी भी client के साथ काम करता है, बैकअप करना आसान।
- नुकसान: मूल रूप से फ़िशिंग‑योग्य; सर्वरों पर shared secrets exfiltrate हो सकते हैं; फिर भी passwords पर निर्भर रहता है।
- SMS और email OTP को व्यापक रूप से कमज़ोर कहा जाता है: SIM‑swap, interception, social engineering, और सुरक्षा का झूठा एहसास।
- कुछ लोग तर्क देते हैं कि “TOTP काफ़ी अच्छा है” और पासकीज़ मुख्यतः जटिलता और policy risk जोड़ती हैं; अन्य इसे “इस दशक का ‘बस बेहतर passwords इस्तेमाल करो’” कहते हैं।
उपयोगिता, पोर्टेबिलिटी, और lock‑in की चिंताएँ
- fragmented UX पर कई शिकायतें हैं: हर साइट का flow (username पहले बनाम passkey पहले, अतिरिक्त email codes, आदि) अलग होता है और भ्रमित कर सकता है।
- लोग platform passkey stores (Apple/Google/Windows) में मजबूर किए जाने और यह चुनने में असमर्थ होने को नापसंद करते हैं कि passkey कहाँ रहे या उसे आसानी से export किया जा सके।
- फ़ोन खोने या बड़े vendor का account लॉक/ban होने पर access खोने की चिंता।
- power users चाहते हैं:
- प्रति account कई स्वतंत्र authenticators।
- offline backups (जिसमें “metal safe” copies भी शामिल हों)।
- विकल्प के रूप में passwords/TOTP या FIDO keys का समर्थन जारी रहे।
Enterprise बनाम consumer और policy angle
- कई लोग मानते हैं कि attestation और सख्त hardware policies कुछ enterprise या critical‑infrastructure मामलों के लिए उपयुक्त हैं।
- बहस इस पर है कि क्या ये mechanisms general consumer web auth में भी घुसेंगे।
- कुछ इसे मुख्यतः policy समस्या मानते हैं (regulation, banking rules, corporate incentives), न कि passkeys की कोई विशिष्ट खामी।
- अन्य तर्क देते हैं कि lock‑in और attestation को आसान बनाने वाले standards स्वयं ही ख़तरनाक हैं, चाहे उनका वर्तमान उपयोग कुछ भी हो।