Passkeys का बढ़ता हाइप security keys को बेकार कैसे बना रहा है

 (fy.blackhats.net.au)
1 पॉइंट द्वारा GN⁺ 2023-07-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • अगर Passkeys को resident key के रूप में परिभाषित कर अनिवार्य करने का चलन फैलता है, तो Yubikey·Feitian·Nitrokey जैसी security keys सीमित storage space के कारण जल्दी अपनी सीमा पर पहुँच जाएँगी
  • non-resident credential में Relying Party द्वारा दिया गया credential ID security key डिक्रिप्ट करती है और RP-विशिष्ट private key प्राप्त करती है, इसलिए डिवाइस के भीतर केवल master key ही stored रहती है
  • इसके उलट resident/discoverable credential में private key स्वयं security key में stored होती है, इसलिए हर account एक slot लेता है; Nitrokey 8 और Yubikey आम तौर पर केवल 20~32 तक support करती है
  • CTAP2.0 security keys में resident key को अलग-अलग delete नहीं किया जा सकता, इसलिए पूरा reset करना पड़ता है; इस दौरान master key भी बदल जाती है और मौजूदा non-resident key भी काम करना बंद कर देती हैं
  • अगर services और libraries resident key को default requirement बना दें, तो 150 से अधिक accounts इस्तेमाल करने वाले users को कई security keys और backup keys संभालनी पड़ेंगी, जिससे अपनी पसंद का authenticator चुनना कठिन हो जाएगा

resident key समस्या के केंद्र में क्यों है

  • Passkeys को लेकर बढ़ती उम्मीदें security keys को पुराने डिवाइस जैसा बना सकती हैं—इस चिंता के केंद्र में resident key है
  • यह धारणा कि security key accounts की संख्या को “असीमित” रूप से support करती है, कई मामलों में non-resident credential मॉडल पर आधारित है
  • resident key वास्तव में security key की internal storage को consume करती है, इसलिए accounts बढ़ते ही डिवाइस की सीमा तुरंत सामने आ जाती है

non-resident credential कैसे काम करता है

  • non-resident credential में authentication के समय Relying Party, browser के जरिए credential ID security key को भेजती है
  • credential ID एक encrypted blob होता है जिसे केवल security key ही डिक्रिप्ट कर सकती है, और डिक्रिप्शन का परिणाम उस Relying Party की dedicated private key होता है
  • security key इस डिक्रिप्ट की गई private key से challenge पर signature करती है और signature को browser तथा Relying Party को लौटा देती है
  • इस संरचना में private key security enclave के अंदर स्थायी रूप से stored नहीं रहती; security key के भीतर केवल master key होती है
  • credential ID को AES-128 से encrypt किया जाता है और उस पर HMAC लागू होता है, इसलिए बाहर से उसमें छेड़छाड़ करना या उसे डिक्रिप्ट करना कठिन माना जाता है
    • तुलना यह दी जाती है कि अगर AES-128 टूट जाए और security key के बिना private key डिक्रिप्ट की जा सके, तो TLS encryption और SSH भी हमले के दायरे में आ जाएँगे

resident/discoverable credential का अंतर

  • resident key या discoverable credential वह तरीका है जिसमें private key security key के भीतर stored होती है
  • जब Relying Party एक खाली credential ID सूची भेजती है, तो security key उस RP के लिए उपलब्ध key खोजती है, एक चुनती है और फिर signature करती है
  • यह संरचना बाहर से credential ID लेकर उसे master key से डिक्रिप्ट करने वाले तरीके पर निर्भर नहीं करती
  • लेकिन हर credential security key के अंदर जगह घेरती है, इसलिए resident key slots की संख्या ही व्यावहारिक account limit बन जाती है

userVerification, resident key से अलग है

  • यह भ्रम है कि अगर किसी credential में userVerification अनिवार्य करनी हो तो वह resident होना ही चाहिए, जबकि दोनों अवधारणाएँ अलग हैं
  • security key केवल touch से presence verify नहीं करती, बल्कि अंदर ही PIN या biometrics verify करके यह भी जाँच सकती है कि वास्तविक user वही है
  • यह व्यवहार userVerification flag से नियंत्रित होता है और key residency से स्वतंत्र रूप से काम करता है
  • इसलिए resident key न होने पर भी डिवाइस को अपने-आप में multi-factor authenticator की तरह इस्तेमाल किया जा सकता है

security key की storage और CTAP सीमाएँ

  • resident key डिवाइस के भीतर stored होती है, इसलिए security key में slots की संख्या महत्वपूर्ण है
    • Nitrokey 8 resident keys support करती है
    • Yubikey आम तौर पर 20~32 support करती है
    • कुछ keys resident key को बिल्कुल support नहीं करतीं
  • security key द्वारा implement किया गया CTAP standard manageability पर बड़ा असर डालता है
    • CTAP2.1 और CTAP2.1PRE में resident key को individually manage, update और delete किया जा सकता है
    • CTAP2.0 में resident key हटाने के लिए पूरे डिवाइस को reset करना पड़ता है
  • CTAP2.0 डिवाइस reset के दौरान master key भी reset हो जाती है, इसलिए पहले की non-resident keys भी आगे काम नहीं करतीं
  • कई security keys के CTAP2.0 होने की संभावना है; Yubico के मामले में CTAP version firmware version पर निर्भर करता है

passkeys नाम और resident key परिभाषा का फैलाव

  • Apple ने 2022 में macOS/iOS पर Touch ID और Face ID को WebAuthn authenticator की तरह इस्तेमाल करने वाली passkeys सुविधा की घोषणा की
  • passkeys नाम को “webauthn authenticator” या “security key” की तुलना में users के लिए अधिक परिचित माना गया
  • इसके बाद passkeys का अर्थ स्पष्ट रूप से तय हुए बिना कई व्याख्याएँ सामने आईं
    • Rust WebAuthn library और Relying Party implementers passkeys को उन सभी authenticators के नाम के रूप में परिभाषित करते हैं जिन्हें user चुन सकता है
    • कुछ community members passkeys को ऐसे credentials कहते रहे जो कई devices के बीच sync होते हैं
    • FIDO Authenticate conference में “passkey is resident key” जैसी परिभाषा सामने आई, और बाद में FIDO ने भी अपने FAQ में यही परिभाषा अपनाई
  • resident key परिभाषा के चर्चा में आने का एक कारण browser का प्रस्तावित feature conditional UI भी है
    • अगर credential resident key हो, तो username और WebAuthn credential को autofill किया जा सकता है
    • इससे ऐसा अनुभव मिलता है जिसमें user को username manually टाइप नहीं करना पड़ता

resident key requirement से पैदा होने वाली user समस्याएँ

  • अगर WebAuthn libraries सभी registrations में resident key की मांग करने लगें, तो सीमित storage वाली security keys बहुत जल्दी भर सकती हैं
  • उदाहरण के लिए, अगर किसी password manager में 150 से अधिक saved passwords हैं, तो उन सबको resident key में बदलने के लिए कम से कम 5 Yubikey चाहिए होंगी
  • backup को भी शामिल करें, तो 10~15 Yubikey manage करनी पड़ सकती हैं
  • यह security key चुनने वाले users के लिए खराब user experience है, और passkeys की resident key requirement security key के इस्तेमाल को ही कठिन बना सकती है
  • FIDO authentication key marketing में “unlimited key pair storage” या “registered accounts की संख्या पर कोई सीमा नहीं” जैसे दावे किए जाते हैं, लेकिन यह non-resident key के लिए सही होने पर भी resident key requirement से टकराते हैं
  • WebAuthn Work Group के लक्ष्यों में से एक यह है कि users अपनी पसंद का authenticator बिना किसी नुकसान के स्वतंत्र रूप से चुन सकें, लेकिन resident key को मजबूर करना इस लक्ष्य के अनुकूल नहीं है
  • passkey ecosystem में ठीक से काम करने वाले authenticator types के रूप में Apple passkeys, Android passkeys, WebAuthn support करने वाले password managers, TPM 2.0 इस्तेमाल करने वाला Windows, और Touch ID को TPM की तरह इस्तेमाल करने वाले macOS के Chromium-आधारित browsers का उल्लेख किया गया है

संभावित समाधान की दिशाएँ

  • rk=preferred के व्यवहार को बदलकर security keys पर resident key न बनाने का एक तरीका हो सकता है
    • अभी Relying Party resident key request level को discouraged, preferred, required में से एक के रूप में सेट कर सकती है
    • मौजूदा rk=preferred roaming authenticator जैसे Yubikey पर भी resident key बना देता है, और नतीजतन rk=required जैसा व्यवहार करता है
    • अगर preferred को “केवल तब resident key बनाएँ जब storage practically unlimited हो” जैसा नरम किया जाए, तो Android/iOS resident key बना सकते हैं और security key storage consume नहीं होगी
    • WebAuthn WG अभी इस बदलाव के प्रति प्रतिरोधी है, और अगर browser अलग से इसे implement करे तो व्यवहारिक रूप से यह Chrome team के निर्णय पर निर्भर करेगा
  • passkey libraries से rk=discouraged इस्तेमाल कराने का तरीका भी हो सकता है
    • rk=required security keys को बाहर कर सकता है
    • rk=discouraged Android users को conditional UI नहीं दे पाएगा
    • लेकिन username के लिए पहले से autofill के विकल्प मौजूद हैं, इसलिए security key को बाहर करने से यह बेहतर माना जाता है
  • FIDO से resident key storage capacity को certification requirement बनाने की मांग भी की जा सकती है
    • फिलहाल FIDO certified devices के लिए storage capacity को अनिवार्य नहीं करता
    • तर्क यह है कि अगर FIDO resident key को बढ़ावा देना चाहता है, तो certified authenticators को हजारों resident keys store करने में सक्षम होना चाहिए

निष्कर्ष

  • Passkeys को resident key मानने वाला बढ़ता चलन security key users के लिए online अपनी पसंद का authenticator चुनना रोक सकता है या बहुत कठिन बना सकता है
  • समस्या Passkeys से अधिक, सीमित storage और सीमित management features वाली security keys पर resident key requirement को एकसाथ लागू करने में है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-07-14
Hacker News टिप्पणियां

  • यह encryption से थोड़ा अलग मामला है, लेकिन मेरी मां ने panic में फोन किया कि वे Gmail में login नहीं कर पा रही हैं. पता चला कि Google ने उनके नए Android फोन को अपने-आप passkey के रूप में register कर दिया था, और उसे default login तरीका बना दिया था, लेकिन interface बेहद confusing था
    password से login करने के लिए दूसरे option पर click करना होगा या passkey क्या है यह समझना होगा—ऐसी उम्मीद करना मुझे ज्यादा लगता है. उसने कहा कि “Android पर passkey भेज दी गई है”, लेकिन फोन पर कोई notification नहीं आया, और 30 मिनट देखने के बाद भी हल नहीं निकला. अपने-आप register हुई passkey को delete भी नहीं किया जा सकता था और default authentication flow को बंद भी नहीं किया जा सकता था. Google का UX भयानक है, और बड़े पैमाने के authentication system की नींव के तौर पर सस्ते Samsung फोन के बदले हुए Android पर भरोसा करना मूर्खतापूर्ण फैसला लगता है

    • Google 2-Step Verification में भी यही समस्या है. वह कहता है “S21 पर notification भेजा गया है”, लेकिन असल में unlocked S21 हाथ में होने पर भी 3 में से 1 बार notification नहीं आता या 5 मिनट बाद पहुंचता है
      हाल में Google के साथ हुई कई समस्याओं में से यह सिर्फ एक है. पहले privacy की वजह से मैं उन्हें बस थोड़ा avoid करने की कोशिश करता था, अब Google का इस्तेमाल जितना हो सके उतना कम करने के लिए पूरी ताकत लगा रहा हूं. Google Maps पर बिना किसी वजह के business हटा दिया गया और उसे फिर से register कराने में 2 हफ्ते लगे, और किसी इंसान से बात करना असंभव था. हर support email में phone number दिया जाता है, लेकिन वह ads support number है, जो suspended business account के लिए कुछ नहीं कर सकता, और वे यह मानने को भी तैयार नहीं थे कि Google Business team वही number support के लिए देती है. Google Ads support staff से यह मनवाने में कि Google Business से जुड़े किसी व्यक्ति से बात करने का कोई तरीका नहीं है, मुझे 30 मिनट तक सवाल दोहराने पड़े. अब मैं बस anti-Google evangelist बन गया हूं
    • बिना चाहे बार-बार आने वाली “आपके फोन पर notification भेजा गया है” verification demand की वजह से मैं गंभीरता से अपने business को Google ecosystem से बाहर निकालने पर विचार कर रहा हूं. अगर मैं दुनिया के दूसरी तरफ से अचानक login कर रहा होता, या हमेशा Linux इस्तेमाल करने के बाद browser Windows के रूप में पहचाना जाता, तो समझ आता, लेकिन privacy-focused browser ungoogled chromium इस्तेमाल करने पर same IP से भी हर authentication पर यह होता है
      अगर फोन की battery खत्म हो जाए तो? अगर फोन खो जाए और location service credentials recover करने के लिए email पर password reset भेजना पड़े, लेकिन email में login ही न कर पाएं तो? वहीं से “सवालों के जवाब दें” वाली प्रक्रिया शुरू होती है. कोई छिपा हुआ, जवाबदेही से मुक्त algorithm Linux पर ungoogled chromium को suspicious मानता है, और अगर “अभी उपलब्ध storage का कितने percent इस्तेमाल हो रहा है?” जैसे सवाल का जवाब गलत याद हो जाए, तो access recovery किस्मत पर छोड़नी पड़ती है. बता दूं कि मैं paid Google user हूं
    • छोटी-सी correction: passkey Android पर “transmit” नहीं होती. Gmail login का तरीका यह है कि browser में दिख रहे QR code को scan कराकर साबित किया जाए कि Android में मौजूद passkey आपके पास है
      फिर भी मूल बात पूरी तरह समझ आती है. UX और terminology दोनों confusing हैं. हर step explanation देता भी हो, तब भी लोग—खासकर जल्दी में—छोटे explanation text को छोड़कर सबसे बड़े और चमकदार button पर click करने के लिए trained होते हैं, इसलिए वह ज्यादा मदद नहीं करता. UX design के लिहाज से यह सचमुच कठिन समस्या है
    • इस घटना ने हद पार कर दी. मुझे एहसास हुआ कि Google users के हिसाब से decisions नहीं लेता. वह advertisers से पैसा कमाता है, users को बस इतना service देता है कि वे छोड़कर न जाएं, और competitors को रोकने जितना ही maintain करता है
      जब तक users छोड़कर नहीं जाते, Google को परवाह नहीं है, और परवाह करने की जरूरत भी नहीं है. अगर कुछ अलग चाहिए, तो ऐसी service चाहिए जिसका खर्च advertisers न उठाते हों. Google users का एक तरीके से शोषण करता है तो Apple बस दूसरे तरीके से करता है, और जहर चुनना कोई विकल्प नहीं है
    • निष्पक्ष रूप से देखें तो यह passkey की अपनी समस्या नहीं, बल्कि Google के product UX की बेवकूफी ज्यादा है. अगर Google login UX को अचानक ऐसे तरीके में बदल दे जिससे users परिचित नहीं हैं, तो ज्यादातर लोग भ्रमित होंगे ही

  • Apple ने इसे असल में define नहीं किया, इसलिए “passkey आखिर है क्या?” जानना चाहने वाले users के लिए विचारकों ने खाली जगह भरनी शुरू कर दी
    मेरी समझ रही है कि Apple ने passkey को iCloud Keychain से sync होने वाली key pair के रूप में define किया था. WWDC 2021 presentation में भी passkey को security key से अलग बताया गया था, क्योंकि यह “हमेशा आपके पास होती है”, यानी device sync और “recoverable” होने की वजह से. बाद में definition शायद दूसरे cloud sync तरीकों तक expand हो गई. मुझे लगता है यह लेख गलत trade-off कर रहा है. Security keys महत्वपूर्ण नहीं हैं[1]. क्योंकि इन्हें बहुत थोड़े technical users और security को सच में महत्व देने वाली कुछ companies ही इस्तेमाल करती हैं. Web safety बढ़ानी है तो लोगों को passwords से दूर करना होगा, और 99% population security key तब तक इस्तेमाल नहीं करेगी जब तक मजबूर न किया जाए. Passkeys खासकर operating system में deep integration की वजह से passwords की जगह लेने की बड़ी संभावना रखती हैं. 1% से कम users के resident key slots कम पड़ रहे हैं, इसलिए authentication को उसी हिसाब से optimize नहीं करना चाहिए. [1] मेरे पास 3 Yubikey, 3 Yubico security keys, और 1 SoloKey है

    • लक्ष्य Apple Passkey product नहीं, बल्कि industry-wide initiative था. 2022 में launch होने तक definition ढीली हो गई थी; उदाहरण के लिए, यह discoverable होने और user verification choices देने वाले “experience” के ज्यादा करीब हो गई थी
      user चुन सकता है कि backup और recovery वाली passkey provider इस्तेमाल करनी है या नहीं, और relying party को वह signal मिलता है. इस signal को देखकर यह भी तय किया जा सकता है कि password login option हटाने का सुझाव देना है या नहीं
    • Passkey को असल में FIDO Alliance define करता है
      FIDO standard के अनुसार, passkey password की जगह लेती है और users को उनकी कई devices पर websites और apps में तेज, आसान और अधिक सुरक्षित login करने देती है. passwords के विपरीत, passkeys हमेशा strong और phishing-resistant होती हैं. https://fidoalliance.org/passkeys/

  • समझ नहीं आता कि rk=required मौजूद ही क्यों है। इसे शुरू से option के तौर पर होना ही नहीं चाहिए था
    ऐसी ही चीज़ों की वजह से मैं passkeys और उनसे जुड़े लोगों को लेकर लगातार चिंतित और संशय में रहा हूँ। इनकी ज़िम्मेदारी है कि protocol को इस तरह design करें कि यह Microsoft जैसी बड़ी कंपनियों के लिए security और compatibility को गंभीर रूप से बिगाड़ने और competition को खत्म करने वाली तरह-तरह की दुर्भावनापूर्ण market practices का आसान tool न बन जाए। लेकिन लेखों और posts में बार-बार दिखने वाला रवैया लगभग ऐसा है: “भाड़ में जाओ, हम दुरुपयोग को और आसान बना देंगे।” समस्या सिर्फ resident keys की नहीं है; उदाहरण के लिए attestation को handle करने का तरीका भी कंपनियों को खत्म करने के लिए आसानी से abuse किया जा सकता है

    • यहाँ लक्ष्य शायद phone को passkey बनाना और उसके अलावा कुछ भी इस्तेमाल न होने देना है। उस नजरिए से देखें तो लेख में कही गई हर बात समझ आती है
    • मुझे लगता है यह attestation abuse से कम बुरा है
      अगर कोई service rk=required set करती है और platform इसे enable या support नहीं करना चाहता, या कर ही नहीं सकता, तो प्रक्रिया हमेशा fail होगी और registration तक नहीं हो पाएगा। अगर लक्ष्य users को onboard करना और business बढ़ाना है, तो यह अपने ही पैर पर कुल्हाड़ी मारने जैसा लगता है
    • मुझे जानना है कि “attestation को handle करने का तरीका कंपनियों को आसानी से खत्म करने के लिए abuse किया जा सकता है” से कौन-सी समस्या मतलब है

  • मैं security या cryptography वाला व्यक्ति बिल्कुल नहीं हूँ, इसलिए यह लेख follow करना मेरे लिए बहुत मुश्किल था, और शायद दूसरों के लिए भी होगा
    जिनके पास पर्याप्त background knowledge है, उन्हें ये अजीब सवाल लग सकते हैं, लेकिन मैं हर एक-दो वाक्य पर अटक रहा था। “आखिरकार सब एक चीज़, resident keys, पर आकर टिकता है” — यह कैसे और क्यों है, समझ नहीं आया, और passkeys या HSM से इसका connection भी समझ नहीं आया। “discoverable/resident key क्या है, यह समझना होगा” का मतलब यह है कि सभी resident keys discoverable keys हैं, या सभी discoverable keys resident keys हैं, या दोनों — यह अस्पष्ट है। “आपने देखा होगा कि अधिकांश keys ‘unlimited’ accounts support करती हैं” — यहाँ key से passkey मतलब है, HSM में stored key, या दोनों, यह समझ नहीं आया। “key-wrapped key को security key को भेजना” — क्या इसका मतलब है कि HSM unlimited accounts पर इसलिए लागू हो सकता है क्योंकि किसी key को दूसरी key से wrap करके store किया जा सकता है? यह भी उलझा रहा

    • मुख्य बात यह लगती है कि WebAuthn को ऐसे passkey model की ओर धकेला जा रहा है जहाँ हर site storage consume करने वाली credentials बनाती है। दिखने योग्य site name और user account name, user record handle, private key और अन्य items — सब storage लेते हैं
      Phone 10,000 passkeys भी बिना समस्या store कर सकता है, लेकिन modern hardware key usable flash में कुल 25 ही store कर सकती है। यह storage discoverability के कारण चाहिए। उदाहरण के लिए GitHub.com login page पर नए passkey support को दबाएँ तो account name तक डाले बिना login कर सकते हैं। Browser password manager जैसा experience देता है, और password manager के passwords की तरह passkey भी local तौर पर site account का record बन जाती है। लेकिन WebAuthn में passkey के अलावा कई modes भी हैं। Non-discoverable credentials के लिए किसी specific user account के handles की list देनी होती है, और ये handles registration के समय key ने दिए थे। Authentication के समय केवल handle से match होने वाली credentials ही options के रूप में दिखाई जाती हैं। Hardware security keys इसका फायदा उठाकर आगे की cryptographic operations के लिए जरूरी record को handle में ही store करती हैं, और यह mode flash storage का उपयोग नहीं करता। User username डालता है, तो कोई API handles की list लौटाता है, और इसे security key पर apply करके storage limit के बिना authenticate किया जा सकता है। हालांकि कई sites account existence expose न करने की policy अपनाती हैं। हमने “अगर यह account मौजूद है तो आपको जल्द email मिलेगा” जैसी recovery procedures देखी हैं। Login process अगर ऐसा API दे जो detect करे कि username या email से जुड़ा account है या नहीं, और कितनी credentials record हैं, तो site के लिए इसे accept करना मुश्किल हो सकता है। आखिरकार, sites द्वारा इस process को व्यापक रूप से अपनाकर मौजूदा hardware limits को प्रभावित करने की बजाय, 10 गुना ज्यादा storage वाली security keys आने की संभावना अधिक लगती है
    • मैं सहमत हूँ कि लेख की argumentation अच्छी नहीं है। मुख्य दावा यह है कि WebAuthN protocol में relying party को rk=required specify करने की क्षमता harmful है। क्योंकि इसके कारण बहुत-सा TPM hardware passkey wallet/database की तरह काम नहीं कर पाता
      Comments में अधिकांश लोग शायद इस बात से सहमत होंगे। लेकिन इससे यह confusion justify नहीं होता जो लेखक ने लेख का आधा हिस्सा passkey की definition पर बहस में खर्च करके पैदा किया
    • लेख FIDO2 के बारे में काफी knowledge assume करता है, इसलिए confusion होना स्वाभाविक है
      Passkey FIDO2 के ऊपर implement होती है, और खास तौर पर FIDO2 specification की resident key capability का उपयोग करती है। FIDO2 hardware authenticator ठीक-ठीक HSM नहीं होता, लेकिन मिलता-जुलता है, और Yubikey जैसे devices HSM भी हैं और FIDO2 authenticator भी। FIDO2 में “resident key” और “discoverable key” synonyms हैं। Specification में “resident key” लिखा है, लेकिन “discoverable key” भी आम तौर पर इस्तेमाल होता है; यह FIDO द्वारा बनाई गई confusing terminology में से एक है। “Key” से passkey या HSM में stored key नहीं, बल्कि Yubikey जैसे FIDO2 hardware authenticator का मतलब है, जिसे अक्सर “security key” कहा जाता है। FIDO2 hardware authenticator, जब तक resident key का उपयोग न करे, व्यावहारिक रूप से stateless होता है और कुछ भी store नहीं करता, इसलिए unlimited accounts में register किया जा सकता है। Account में register होते समय device EdDSA जैसी key pair generate करता है, लेकिन उसे store नहीं करता; private key को embedded master key, जैसे AES256 key, से encrypt करता है। फिर plaintext public key और encrypted private key को google.com जैसी relying party को भेजता है ताकि वे उसे store करें। Authentication के समय encrypted private key, यानी “wrapped” key, authenticator को भेजी जाती है, device के अंदर decrypt होती है, और digital signature बनाने में इस्तेमाल होती है। हालांकि FIDO2 वास्तव में non-resident key implementation method specify नहीं करता; wrapped key सिर्फ एक तरीका है। FIDO2 केवल यह मांगता है कि private key credential ID से securely derive की जा सके, और credential ID arbitrary data है जो wrapped key हो भी सकता है और नहीं भी

  • लगता है स्थिति को कुछ ज़्यादा ही सख्ती से देखा जा रहा है। अगर आप नए authentication standard के फायदे लेना चाहते हैं, जो कमज़ोर password और password reuse को खत्म करके रोज़मर्रा के 99% account compromises रोकता है, तो यह भी कहा जा सकता है कि 2013 से चल रही पुरानी Yubikey से आगे बढ़कर 30 डॉलर खर्च करके upgrade करना होगा

    • समझ नहीं आता कि upgrade करने के लिए मजबूर क्यों किया जाना चाहिए। non-resident keys भी कमज़ोर password और password reuse को खत्म करती हैं। resident key बस इतना छोटा-सा सुधार जोड़ती है कि key लगाते ही service को पता होता है कि यह किस account की है, और यह मौजूदा सभी authentication devices को फेंक देने की वाजिब वजह नहीं लगती
    • 5 series technical manual देखने पर पता चलता है कि यह सिर्फ 25 को support करती है। अभी तो सिर्फ 2 हैं, लेकिन TOTP मेरे पास 25 से कहीं ज़्यादा हैं
      Bio FIDO model का क्या हाल है, पता नहीं, लेकिन अगर वैसा ही है तो YubiCo के पास बड़ी संख्या में resident keys के लिए ठीक बैठने वाला product नहीं हो सकता। सुधार: Bio में भी वही 25 की सीमा है
    • उल्टा, यह व्याख्या तो बहुत उदार लगती है
      साझा की जाने वाली resident keys short-term temporary use को छोड़कर अस्तित्व में ही नहीं होनी चाहिए। यह liability है, security risk है, और खराब security practices को बढ़ावा देती है। इसका सबसे अच्छा उदाहरण TOTP है, जिसमें security के नज़रिए से कई flaws हैं। आपको shared secret को कई devices पर share या backup करना चाहना ही नहीं चाहिए, लेकिन यह संभव है और ढीले-ढाले two-factor authentication implementations अपवाद नहीं बल्कि standard बन गए हैं, इसलिए practically ऐसा करने को मजबूर किया जाता है। अभी का trend देखकर लगता है कि passkeys भी उसी flawed और user-hostile दिशा में जाएंगी
    • फिर भी बहुत बड़ा फर्क नहीं पड़ता। मेरी key सिर्फ 25 resident keys रख सकती है, जबकि मेरे password manager में stored passwords 25 से ज़्यादा हैं
    • चिंता है कि आगे चलकर इस “फायदे” को चुनने के अलावा कोई विकल्प ही न बचे। जब sites नया authentication standard implement करेंगी, तो क्या वे मौजूदा username/password/two-factor authentication को भी alternative के रूप में बनाए रखेंगी?

  • “ऐसी चीज़ जो आपके पास है लेकिन खो भी सकती है” पर आधारित authentication बुनियादी तौर पर टूटा हुआ है। अगर device खो जाए तो access खो देते हैं, या फिर सबसे कमज़ोर कड़ी कहीं और होनी पड़ती है, जिससे उसकी बेहतरीन security का मतलब ही खत्म हो जाता है

    • backup codes print करके रख दें या दूसरी drawer key जोड़ दें। idea खुद शानदार है, लेकिन marketing बहुत खराब है, आम users के लिए setup flow अजीब है, और AirDrop हो सकने वाली या cloud-synced keys को push करना भी खराब idea है। सबसे अहम समस्या key की cost है
    • क्या passwords भी इसमें शामिल नहीं हैं? लोग passwords भी अक्सर खो देते हैं
      नतीजे साबित करेंगे, लेकिन passkeys व्यापक रूप से adopt होने पर मुझे लगता है कि ज्यादातर लोगों के लिए account lockout ज़्यादा आम होने के बजाय कम आम होगा

  • सोचता हूँ hardware keys में storage इतनी सीमित क्यों होती है। key के अंदर security processor के access वाली large-capacity storage साथ में डालने में कितना extra cost आएगा
    इस large-capacity storage को जाहिर है security processor से strongly encrypt करवा दें, और जब सब कुछ delete हो तो वह key भी साथ में wipe हो जाए

    • क्योंकि सुरक्षित tamper-resistant storage महंगा होता है
      security perspective से तो यह तक कहा जा सकता है कि zero storage वाली security key ही सबसे अच्छी security key है। जिन protocols में security token को shared secret आदि से derive करने के बजाय security key या secure enclave आदि में inject करके store किया जाता है, उनमें आम तौर पर गंभीर flaws रहे हैं। कभी-कभी TOTP की तरह fundamental security flaw, और कभी complexity flaw। इसी तरह HSK/two-factor authentication के लिए security key को कई devices पर share करना कभी नहीं चाहना चाहिए। इसका मतलब है कि एक device से leak हुआ तो सब टूट गए। इसके बजाय हर device पर अलग key होनी चाहिए, और login provider या server side पर यह overhead बड़े परिप्रेक्ष्य में negligible है
    • यह ऐसे devices को जितना हो सके “dumb” बनाए रखने का conscious design choice लगता है। जैसे ही storage जोड़ते हैं, वैसे ही दूसरे storage devices जैसी vulnerability surface खुल जाती है, फिर अगली बार compute capability जुड़ती है, और अंत में यह dumb Yubikey नहीं बल्कि पूरा computer बन जाती है
    • storage बढ़ाई जा सकती है, लेकिन जितना ज़्यादा डालेंगे failure की संभावना भी उतनी बढ़ेगी। आज की keys काम करना बंद करने से पहले काफी rough use झेल लेती हैं
      छोटी storage का एक फायदा यह भी है कि audit करना थोड़ा आसान होता है। हालांकि आज के standards से देखें तो वह छोटा size भी शायद practical auditability की सीमा को push कर रहा हो
    • बात memory limited होने की नहीं, बल्कि यह है कि इसे शुरू से ही memory limit न रहने के लिए design किया गया है
      TPM को देखें तो किसी चीज़ पर sign करते समय हर बार input होता है sign किया जाने वाला data और sealed private key। sealed key वह private key है जिसे TPM ने generate किया है और TPM में embedded key से symmetrically encrypt किया गया है। इस sealed key को large-capacity storage में store रखते हैं, और हर signing operation पर TPM को provide करते हैं। इस design की वजह से आपके पास उतनी keys हो सकती हैं जितनी large-capacity storage allow करती है
    • इसे modular भी बनाया जा सकता है। USB memory जैसा दिखने वाला product बेचना, लेकिन पीछे की तरफ YubiKey Nano जैसे छोटे form factor वाली security key लगाने के लिए slot हो
      security key को slot में लगाने पर USB memory security key को storage provide करे, और computer को वह security key जैसी दिखे। security key न लगी हो तो यह सामान्य USB memory की तरह काम करे। आम तौर पर security key लगी रहने दें, और जब ज़्यादा storage चाहिए हो तो बड़ा storage module खरीदें, पुराने module से security key निकालकर computer में लगाएं, encrypted file copy करें, उसे नए module में move करें और security key वापस लगा दें

  • शुरू से ही physical security key को passkey के तौर पर इस्तेमाल करना अच्छा विचार है या नहीं, मुझे नहीं पता। passkey को password replacement के रूप में सोचा गया था, और इसके लिए आम तौर पर “जो आपके पास है” के साथ-साथ unlock करने के लिए “जो आप जानते हैं” या “आप स्वयं” की मांग करने वाले phone या desktop से मिलने वाली 2-factor property की जरूरत लगती है
    मेरे हिसाब से physical security key को कुछ खास high-security context में passkey के अलावा इस्तेमाल होने वाले 2-step authentication के रूप में रखना बेहतर है। खासकर जब clone resistance मुख्य feature हो। उस उपयोग के लिए, जब आप दूसरे step तक पहुंचते हैं तो आपको पहले से पता होता है कि किस account में login करना है, इसलिए resident key की जरूरत नहीं होती। साथ ही मुझे लगता है कि resident key द्वारा दी जाने वाली autocomplete सुविधा passkey UX के लिए अहम है। सिर्फ security geeks द्वारा इस्तेमाल की जाने वाली मुट्ठीभर keys के साथ backward compatibility बनाए रखने के लिए उसे कुर्बान करना समझदारी नहीं है। बेशक, अगर resident key के बिना भी उस UX को बनाए रखने का कोई तरीका हो तो ठीक है

    • कुल मिलाकर मेरी भी यही सोच है। अभी जिस idea पर सब converge कर रहे हैं, वह है एक भरोसेमंद local encrypted security vault रखना, और उस system में अपनी identity verify करनी। यह password भी हो सकता है और key भी
      account बनाने वाली दुनिया की हर service को सुरक्षित या phishing-proof मानने के बजाय, यह मानना आसान है कि आपका चुना हुआ password manager ज्यादा सुरक्षित है। इसलिए जब आप passkey इस्तेमाल करने तक पहुंचते हैं, तब अक्सर आप पहले से ही operating system या passkey रखने वाले password manager आदि में अपनी identity establish कर चुके ज्यादा सुरक्षित context में होते हैं। साथ ही, जो जगहें अभी या हाल तक hardware key support नहीं करती थीं, उनकी निकट भविष्य में भी support करने की संभावना कम है। इसके उलट passkey solution अपनाना काफी आसान है, क्योंकि deployment cost मोटे तौर पर software support जितनी है, इसलिए investment के मुकाबले असर ज्यादा हो सकता है। बेशक यह बात मुख्य रूप से websites पर लागू होती है, और passkey websites के लिए “standardized SSH key” जैसी है। hardware key उस vault को सच में खोलने के 2-step factor के रूप में ज्यादा उपयोगी लगती है जिसमें passkeys रखी हैं, और इस समय password की भी जरूरत हो सकती है। लगता है hardware key की उम्र अभी कुछ बाकी है। GitHub, Gmail आदि में इसे default method के रूप में इस्तेमाल करके देखा, तो passkey login flow सच में बहुत अच्छा है
    • password manager ने पहले ही passwords को बेकार बना दिया है। master password एक को छोड़कर मुझे अपने कोई भी password नहीं पता। passkey एक हद से ज्यादा जटिल solution है जिसकी हमें असल में जरूरत नहीं है
      browser में एक simple HATEOAS API होना चाहिए जिससे password manager जुड़ सके, और web app को ऐसा HTML expose करना चाहिए जो browser को trigger करे। फिर password manager तय करे कि user को कैसे authenticate करना है, यानी user जैसा चाहता है वैसा, और उस website का secret value auto-inject कर दे ताकि user auto-login हो जाए। समस्या हो तो email reset इस्तेमाल कर लें। “बहुत fancy security” चाहने वाली websites के नजरिए से, मुझे समझ आता है कि वे कुछ ज्यादा complex चाहती हैं। लेकिन users को optional रूप से higher security level enable करने में सक्षम होना चाहिए। उदाहरण के लिए, ज्यादातर websites के लिए, अगर यह माना जाए कि password manager random passwords इस्तेमाल करता है, तो simple password hash काफी है। कोई भी website इसे implement कर सकती है, सभी password managers इसे implement कर सकते हैं, और यह आम users के 99% के मौजूदा password usage से बेहतर है। इसे default authentication method रखा जा सकता है। उसके बाद अगर TOTP, OIDC, public key encryption आदि चाहिए, तो server advertise करे और client optional रूप से participate करके authentication जारी रखे। हर site और हर user को सबसे सुरक्षित तरीका इस्तेमाल करने की जरूरत नहीं है। पहले security baseline बढ़ाना आसान बनाया जाए, और stronger security को धीरे-धीरे optional बनाया जाए
    • Yubikey से passwordless authentication (FIDO2) करते समय, device को touch करने को कहने से पहले PIN मांगा जाता है। PIN बहुत ज्यादा बार गलत डालने पर Yubikey lock हो जाती है और device reset करना पड़ता है, जिससे उस key को authentication के लिए इस्तेमाल करने वाली सभी existing registrations invalid हो जाती हैं
      कोई मेरा hardware token चुरा भी ले तो यह बहुत बड़ी समस्या जैसा नहीं लगता। https://support.yubico.com/hc/en-us/articles/4402836718866-U...
    • सोचें तो core problem को “किसी biological being को electronic system में authenticate करना” कहा जा सकता है
      password इस्तेमाल करने पर authentication interface keyboard होता है, और password डालने वाला व्यक्ति वही है जो वह होने का दावा कर रहा है, इसकी कोई वास्तविक guarantee नहीं होती। password आसानी से transfer हो सकने वाले knowledge पर निर्भर करता है, इसलिए उसे कई तरीकों से extract किया जा सकता है। authentication interface को device-to-device पर shift करना कहीं बेहतर है। आसानी से transfer होने वाला knowledge transfer नहीं हुआ है, यह मानने के बजाय हम मानते हैं कि biological being authentication device को manage कर सकता है, और लोग स्वाभाविक रूप से इस काम में काफी अच्छे होते हैं। authentication channels की संख्या बढ़ाकर इसे और मजबूत भी बनाया जा सकता है, और remote system authentication में इस्तेमाल होने वाले device और biological being के बीच authentication को FaceID की तरह constrain भी किया जा सकता है। मूल रूप से phone या key जैसे device को ही उस व्यक्ति के बराबर मानना स्वाभाविक लगता है। घर में हम Netflix password ही नहीं, एक credit card भी share करते हैं। practical कारणों से एक credit card spare key के साथ रखा है, और घर के लिए कुछ खरीदना हो तो कोई भी उसे उठा कर इस्तेमाल कर सकता है। हम भरोसा करते हैं कि सब card का सही इस्तेमाल करेंगे, और सभी को PIN पता है, लेकिन contactless payments आम हैं इसलिए उसकी शायद ही जरूरत पड़ती है। खर्च track करके बाद में आपस में settle करने से यह कहीं ज्यादा natural है। शायद यह illegal होगा और bank को पता चला तो वह card cancel कर देगा, लेकिन ऐसा ही है। IT systems को real world जैसे तरीकों से काम करते हुए human behavior के करीब आने की सख्त जरूरत है। IT systems से जुड़े होने के कारण ज्यादातर लोग somehow संभाल लेते हैं, लेकिन tech-savvy नहीं होने वाले लोग iPhone password क्या है, iCloud password क्या है, Gmail password क्या है, WhatsApp में code क्यों डालना है जैसी रोजमर्रा की चीजों में भी जूझते हैं। सच कहूं तो मैंने भी Mastadon नहीं समझा। मुझे लगता है Mastadon phishing के सामने मैं बेबस रहूंगा, और screen जो भी enter करने को कहेगी, मैं शायद वही enter कर दूंगा
    • यह कहना सही नहीं है कि passkey password replacement है

Passkeys नाम के मुताबिक दूसरे factor के रूप में विकसित FIDO2 U2F standard पर ही टिके हैं। Resident keys, PIN के साथ device में 2-step authentication के लिए हैं, और smart card का functional replacement हैं। किसी ने, शायद Apple ने, सोचा लगता है कि सिर्फ WebAuthn ही एकमात्र authentication factor बनने के लिए काफी है। न resident key है, न hardware binding, और key iCloud के जरिए move करती है, लेकिन device पर TouchID/FaceID से protected रहती है—कुछ ऐसा। और इसे Passkeys के रूप में brand कर दिया गया। 2-step authentication अपने-आप में लक्ष्य नहीं है। लक्ष्य है user authentication जो phishing, brute force और credential stuffing attacks से सुरक्षित हो और smart card जितना implement करना मुश्किल न हो। FIDO2 यह कर देता है। Apple, Google, Microsoft implementations की समस्या यह नहीं है कि authentication site और user device के बीच protocol-level security कम है। Protocol वही है। समस्या यह है कि site को अब user के personal platform account पर भरोसा करना पड़ता है, यह मानना पड़ता है कि user ने उसे सही तरीके से set up किया है, और platform आगे भी हमेशा सही व्यवहार करेगा और user के personal account पर attacks को ठीक से handle करेगा।

  • संदर्भ जोड़ें तो, मैं YC-समर्थित एक passwordless authentication कंपनी चलाता/चलाती हूँ और इसे बड़े संगठनों में deploy करता/करती आया/आई हूँ। यह साफ दिखता है कि passkeys consumer passwordless authentication का जवाब बनेंगे, लेकिन enterprise environment में अभी यह बात उतनी लागू होती नहीं दिखती
    Passkeys consumers के लिए शानदार हैं। वजह यह है कि इनका उद्देश्य iCloud default backup या AirDrop जैसे तरीकों से credentials को दूसरे devices पर backup करना है, ताकि लोग खुद emergency access पा सकें। तकनीकी रूप से, जिन devices के साथ ये credentials share किए गए हैं वे attestation नहीं दे सकते। Attestation का मतलब वह “सबूत” है कि key pair किसी खास device, जैसे Yubikey या Apple device, पर generate हुआ था। Yubico जैसे manufacturers non-extractable key pairs और certificates को key में embed करके ship करते हैं, और इस key pair तक पहुँचने के लिए कोई external interface नहीं होता, इसलिए admin को काफी भरोसा हो सकता है कि यह सचमुच Yubikey है। Attestation न हो और key share की जा सके, तो समस्या कहाँ से शुरू होती है, यह दिखता है। Enterprises AirDrop किए जा सकने वाले credentials के जरिए privileged employee account access expose होने का जोखिम नहीं लेना चाहते। Yubikey में digital theft का जोखिम व्यावहारिक रूप से नहीं है। आखिरकार passkeys device या server unlock करने के लिए भी इस्तेमाल नहीं हो सकते। FIDO2, और उससे भी ज्यादा operating system developers को passwords पूरी तरह खत्म करने के लिए अभी लंबा रास्ता तय करना है। मौजूदा enterprise market के बड़े हिस्से में Yubikey इस gap को भर रहा है, और कुछ ने hardware पर करोड़ों डॉलर खर्च किए हैं। मौजूदा स्थिति में passkeys बेचना मुश्किल होगा

    • Passkey कोई technical term नहीं, बल्कि experience term है। इसलिए technical argument में इस्तेमाल करने पर यह कुछ हद तक बिखर जाता है
      Apple भी passkeys support करता है, Android और Chrome भी, Microsoft भी, और Yubikey भी passkeys support करता है। लेकिन user verification के लिए authentication process और clonability जैसी capabilities और constraints बहुत अलग हो सकती हैं। सरकारी एजेंसियां passkeys support कर सकती हैं, लेकिन उन्हें केवल तब allow कर सकती हैं जब वे AAL2 requirements पूरी करने वाले FIPS-certified authenticator device से मिलें। कम से कम फिलहाल Apple या Google से ऐसा नहीं आएगा। Enterprises MDM-managed products द्वारा दिए गए software और configuration से बनाए गए passkeys support करने का विकल्प चुन सकते हैं, और Apple ने इसके लिए beta support announce किया है। हालांकि government-to-citizen services में किसी खास hardware authenticator device को अनिवार्य करने की कोशिश करेंगे तो काफी परेशानी होगी। नागरिकों को 80 डॉलर से ज्यादा का hardware खरीदने के लिए मनाना भी मुश्किल है, और web technology user choice के इर्द-गिर्द बनी है, इसलिए WebAuthn API और user experience के user choice को सीमित करने में मदद करने की दिशा में optimize होने की संभावना भी कम है
    • अगर Google या Apple bot prevention, fraud detection जैसे बेतुके कारणों से गलती से account block कर दें तो क्या होगा?
    • yubikeys 5 को passkey के रूप में इस्तेमाल किया जा सकता है

  • Security के नजरिए से मुझे यह सचमुच बहुत खराब solution लगता है
    सरकारों और Apple, Google जैसी कंपनियों के लिए यह digital life control करने की सपने जैसी संरचना है। Password इस्तेमाल करने पर यह कुछ हद तक stateless जैसा होता है; आप personal email account या कोई भी account लेकर सीमा पार कर सकते हैं, और कोई यह जान नहीं पाता कि आपके पास account है, access सौंपने के लिए मजबूर करना या hardware से access factor निकालना या device access खोने पर lock कर देना मुश्किल होता है। Master keys आदि TPM या secure element में store हों तब भी कुछ सरकारें access कर सकती हैं, इसलिए यह बस कुछ वर्षों और compute power का मामला है। ज्यादातर मामलों में वही अपने आप इस बात का सबूत भी बन जाता है कि आपके पास किसी खास account के credentials हैं। Device या operating system manufacturers को authorities द्वारा security enclave access देने के लिए आसानी से मजबूर किया जा सकता है, और वे स्वेच्छा से या मजबूरी में ऐसा कर सकते हैं