Google अकाउंट में passkey अब डिफ़ॉल्ट लॉगिन विकल्प के रूप में सक्रिय

 (blog.google)
2 पॉइंट द्वारा GN⁺ 2023-10-12 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Google ने व्यक्तिगत Google Account में passkey को डिफ़ॉल्ट विकल्प के रूप में उपलब्ध कराया है, जिससे password-less लॉगिन पर स्विच करना और आसान हो गया है
  • अगली लॉगिन से passkey बनाने और इस्तेमाल करने का प्रॉम्प्ट दिखाई देगा, और अकाउंट सेटिंग्स में “Skip password when possible” विकल्प चालू दिखेगा
  • passkey से fingerprint, face scan, PIN जैसे डिवाइस अनलॉक तरीकों से लॉगिन किया जाता है, और Google के अनुसार यह password से 40% तेज़ और encryption के कारण अधिक सुरक्षित है
  • password लॉगिन फिलहाल बना रहेगा, और जो उपयोगकर्ता यह नहीं चाहते वे “Skip password when possible” बंद करके passkey इस्तेमाल से इनकार कर सकते हैं
  • YouTube, Search, Maps में passkey पहले से इस्तेमाल हो रहा है, Uber और eBay भी इसे सपोर्ट कर रहे हैं, और WhatsApp compatibility भी जल्द आने वाली है

व्यक्तिगत Google Account के लॉगिन डिफ़ॉल्ट में बदलाव

  • Google का कहना है कि इस साल की शुरुआत में passkey सपोर्ट लॉन्च करने के बाद उपयोगकर्ताओं की प्रतिक्रिया सकारात्मक रही
  • अब पूरे व्यक्तिगत Google Account में passkey को डिफ़ॉल्ट लॉगिन विकल्प के रूप में उपलब्ध कराया जा रहा है
  • अगली बार अकाउंट लॉगिन करते समय passkey बनाने और इस्तेमाल करने का प्रॉम्प्ट दिखाई देगा
  • Google Account सेटिंग्स में “Skip password when possible” विकल्प चालू स्थिति में दिखेगा

passkey का उपयोग और इसकी सुरक्षा विशेषताएँ

  • passkey से अकाउंट लॉगिन के समय डिवाइस अनलॉक की तरह fingerprint, face scan, PIN का उपयोग किया जाता है
  • Google के अनुसार passkey लॉगिन password की तुलना में 40% तेज़ है
  • यह encryption पर आधारित होने के कारण अधिक सुरक्षित है और phishing resistance भी देता है
  • इससे उपयोगकर्ताओं पर password के अंक और special characters याद रखने का बोझ कम हो सकता है

password और उपयोगकर्ता की पसंद बनी रहेगी

  • Google का मानना है कि नई तकनीक को स्थापित होने में समय लगता है, इसलिए password कुछ समय तक बना रह सकता है
  • उपयोगकर्ता अब भी password से लॉगिन कर सकते हैं
  • जो उपयोगकर्ता passkey नहीं चाहते, वे “Skip password when possible” विकल्प बंद कर सकते हैं

Google के बाहर भी बढ़ता passkey सपोर्ट

  • passkey लॉन्च होने के बाद से उपयोगकर्ता YouTube, Search, Maps जैसे Google ऐप्स में passkey का उपयोग करते आ रहे हैं
  • Google उद्योग भर में passkey अपनाने की बढ़ती प्रवृत्ति को सकारात्मक मान रहा है
  • Uber और eBay अपने प्लेटफ़ॉर्म लॉगिन में password के बिना विकल्प दे रहे हैं
  • WhatsApp compatibility भी जल्द उपलब्ध होने वाली है

password-less लॉगिन की ओर अगला कदम

  • Google आगे भी यह बताता रहेगा कि दूसरे ऑनलाइन अकाउंट्स में passkey कहाँ इस्तेमाल किए जा सकते हैं
  • कंपनी उद्योग को passkey की ओर बढ़ाने, password के उपयोग को घटाने और अंततः उसे दुर्लभ बनाने की दिशा में काम कर रही है
  • Google अकाउंट सुरक्षा से जुड़ी जानकारी myaccount.google.com/safer पर देखी जा सकती है

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

1 टिप्पणियां

 
GN⁺ 2023-10-12
Hacker News टिप्पणियाँ

  • जैसा कई लोगों ने कहा है, डिवाइस खो जाने पर cryptographic authentication को फिर से शुरू करना बहुत मुश्किल होता है
    पिछले महीने मेरी पत्नी के iPhone का ग्लास टूट गया था और AppleCare के तहत उसकी मरम्मत कराई, लेकिन Apple ने यह नहीं बताया कि “ग्लास रिपेयर” में असल में अंदरूनी पार्ट्स बदलना और डिवाइस रीसेट करना शामिल है
    Apple iPhone backup में eSIM जैसी cryptographic secrets शामिल नहीं होतीं
    आखिर में eSIM activate करने के लिए email चाहिए, email के लिए MS Authenticator चाहिए, और MS Authenticator को SMS के बिना activate नहीं किया जा सकता—ऐसे loop में फँस गए
    फोटो ID के ढेर सारे दस्तावेज़ लेकर telecom operator के store तक जाना पड़ा और eSIM दोबारा जारी करवाना पड़ा; password सही होने के बावजूद फोन के किसी hardware lock की वजह से bank account तक lock हो गया
    इसे हल करने में कई दिन लगे और कई संस्थानों में खुद जाकर मिलना पड़ा। अगर यह विदेश यात्रा के दौरान हुआ होता, तो हम पूरी तरह फँस जाते
    समय बदल चुका है, और अब पूरी digital identity फोन के अंदर की smart card बन गई है। वह smart card चाहे SIM हो या onboard TPM chip, उसे खो देने पर दूसरों की नज़र में आप लगभग मृत व्यक्ति जैसे हो जाते हैं
    Passkey इस समस्या को बहुत बदतर बना देता है। physical SIM हो तो उसे एक फोन से दूसरे फोन में ले जाया जा सकता है, लेकिन Passkey को providers के बीच transfer नहीं किया जा सकता
    चीखते हुए भाग जाना चाहिए। hype पर भरोसा न करें, और तब तक इंतज़ार करें जब तक providers transfer और recovery के सही समाधान न दे दें

    • “चीखते हुए भागो” वाली बात से मैं पूरी तरह सहमत हूँ। authentication को ऐसे hardware से बाँधना जिस पर मेरा नियंत्रण नहीं है भविष्य में लगभग निश्चित service denial तक ले जा सकता है
      लोग passwords से नफरत करते हैं, लेकिन व्यावहारिक रूप से कई स्थितियों और threat models में password सबसे अच्छा compromise है। /dev/random से 32 bytes या उससे ज़्यादा निकालकर अपनी पसंद के तरीके से encode कर दें, तो इस ब्रह्मांड में कोई भी brute force से उसे तोड़ नहीं पाएगा, और password manager reuse की समस्या भी हल कर देता है
      ऊपर से इसका फायदा यह भी है कि storage का तरीका मेरे नियंत्रण में रहता है, और जितना भरोसा चाहिए उतने redundant backups रख सकता हूँ
    • आपने जिन समस्याओं की बात की है उन सब पर मुझे भरोसा है, लेकिन आमतौर पर हर service में कई Passkey जोड़ी जा सकती हैं। redundancy के लिए iPhone और सस्ते Android phone दोनों register किए जा सकते हैं, या 1Password में Passkey store करना भी संभव है
      iPhone backup में iCloud Keychain में stored items का backup शामिल होता है, और अगर आपके पास कोई दूसरा Apple device या recovery key है तो आप फिर से access पा सकते हैं। सिर्फ device passcode या recovery key हो तो सब कुछ फिर से bootstrap किया जा सकता है
      eSIM telecom operator की चीज़ है, इसलिए थोड़ा अलग मामला है; ऐसी चीज़ें पहले भी और आगे भी store और phone support से बंधी हुई झंझट भरी ही रहेंगी
    • इसके अलावा, आजकल कई websites customer support में इंसान न रखने को मानो गर्व की बात समझती हैं, और account lock होने पर recovery में मदद नहीं करतीं। Google और Meta इसी तरह हैं
    • किसी भी चीज़ की तरह backup ज़रूरी है। आपके पास एक से ज़्यादा Passkey होनी चाहिए
      मैं लगभग 3 इस्तेमाल करता हूँ। workstation की Yubikey, portable Yubikey, और phone। ये 3 email के लिए Google और phone के लिए Apple—दोनों को फिर से शुरू करा सकते हैं। बाकी सब 1Password में है, और इन्हीं तरीकों से access किया जा सकता है
      सबसे बुरी emergency में भी मुझे लगता है कि email किसी न किसी तरह वापस मिल सकता है। DNS provider के साथ identity verify करके MX records बदल दूँ तो फिर काम आगे बढ़ सकता है। फिर भी इसे रोज़मर्रा की ज़िंदगी के लिए अनिवार्य तक नहीं कहूँगा। access खोना बेहद असुविधाजनक होगा, लेकिन शायद मौत का फ़रमान नहीं
      SMS और Signal contacts दूसरी जगह भी हैं, और bank account का पैसा cheque लिखकर इस्तेमाल किया जा सकता है। company से जुड़े accounts के लिए office में खुद पहुँच जाऊँ तो access मिल सकता है
      लेकिन मुझे लगता है कि Passkey आम computer users के लिए बहुत जटिल हो सकता है। अफसोस की बात है कि “हर login पर email link भेज देंगे” वाला तरीका सबसे user-friendly passwordless authentication लगता है
      Passkey को 1Password में डालने की आदत भी मन को पूरी तरह शांत नहीं करती। पता है कि उससे हमेशा के लिए बंध जाता हूँ। फिर भी service पसंद है, और अगर कभी migrate करना चाहूँ तो कम से कम उन accounts की सूची तो है जिन्हें दोबारा बनाना होगा
      सबसे ज़्यादा डर उस स्थिति से है जब phone passcode भूल जाऊँ। एक बार नींद से उठा और बहुत खराब timing पर ध्यान भटक गया, तो 6-digit passcode बिल्कुल याद नहीं आ रहा था। workstation unlock करने के लिए भी वही code इस्तेमाल करता हूँ। थोड़ी देर किसी और चीज़ पर ध्यान लगाने के बाद muscle memory से बड़ी मुश्किल से याद आया
      सच में वह ऐसा पल था जैसे “क्या मुझे अभी-अभी stroke आया है?” अब मैंने वह passcode 1Password में save कर रखा है, ताकि अगर एक भी unlocked device हो तो याददाश्त वापस लाई जा सके। यह काफी समय पहले की बात है और मुझे नहीं लगता कि यह dementia था, बस कोई अजीब सा अस्थायी मामला था
      दूसरी तरफ, काम पर इस्तेमाल किए गए अधिकतम 1 साल की उम्र वाले सारे passwords मुझे पूरी तरह याद हैं। हालांकि 6-digit संख्या याद न आए तो उसका खास फायदा नहीं
    • चीखते हुए भागने से पहले लेख पढ़ने की ज़रूरत न पड़े, इसके लिए सार यह है कि लेख में लिखा है कि अभी भी password से login किया जा सकता है और “संभव हो तो password skip करें” को बंद करके Passkey को reject किया जा सकता है
      तो लगता है जल्द ही password भी “Killed by Google” में शामिल हो जाएगा, और मेरा account भी साथ में। मैं कोई भी logged-in device नहीं रखता
      अब बचे हुए कुछ इस्तेमाल भी migrate करने का समय काफी पहले आ चुका था। जब अपरिहार्य स्थिति आएगी, तो देखना है कि company मेरा work account Passkey reset कर पाएगी या नहीं

  • मुझे लगता है कि यह सही दिशा है, लेकिन मैंने Google या iCloud accounts से lock out हो जाने और उन्हें सच में वापस पाने का कोई तरीका न होने के डरावने किस्से बहुत ज़्यादा देखे हैं
    शायद सिर्फ मैं ही ऐसा नहीं सोचता, लेकिन लगता है किसी दिन शायद मेरी ही गलती से मैं Google से lock out हो जाऊँगा और मेरी digital ज़िंदगी खत्म हो जाएगी
    अगर कोई private company login.gov जैसी login व्यवस्था दे और lock out होने पर USPS की तरह किसी असली इंसान से बात करने की सुविधा दे, तो मैं खुशी-खुशी पैसे दूँगा

    • यह खासकर आम users और बुज़ुर्गों के लिए ज़्यादा बड़ी समस्या है, और Google का इतिहास support लगभग न के बराबर रखने का रहा है। ऊपर से Passkey खुद भी एक flawed system है
      https://mastodon.laurenweinstein.org/@lauren/111103819626952...
      https://mastodon.laurenweinstein.org/@lauren/111211366080459...
    • 2-factor authentication या multi-factor authentication में disaster recovery ही सबसे बड़ी चिंता है। मुझे लगता है PGP जैसी चीज़ें व्यापक रूप से न फैल पाने की एक वजह भी यही है। हमेशा कोई छोटी और कीमती चीज़ संभालकर रखनी पड़ती है, और अगर वह इस्तेमाल के लायक न रहे या कोई दुर्भावनापूर्ण व्यक्ति उसे इस्तेमाल कर ले, तो उसके असर की समस्या रहती है
    • “account से lock out हो सकते हैं” पुराने “hard drive कभी न कभी fail होगी” का नया version है
      यह if नहीं, when का मामला है। जिन्हें अपना data अहम लगता है, उनके लिए backup और पक्का disaster recovery plan ज़रूरी है। कोई न कोई company, मेरी गलती न होने पर भी, कुछ बिगाड़ देगी, और इससे बचा नहीं जा सकता
      अफसोस की बात है कि खोए हुए account के कुछ पहलुओं के लिए अच्छे disaster recovery विकल्प नहीं हैं, लेकिन कई accounts रखना और single point of failure से बचना कुछ हद तक मदद करता है
    • सबसे खराब scenario की कल्पना करना तब उपयोगी है जब उससे action निकले। इस मामले में सही action है Google account recovery options को समझना और उनका उपयोग करना
      login करने के कई स्वतंत्र तरीके होने चाहिए। जैसे backup codes print करके महत्वपूर्ण documents के साथ रखना
      लेकिन यह भी Google policy changes की वजह से account से lock out होने की स्थिति को नहीं रोकता, इसलिए ideally Google account के बिना टिके रहने की practice भी करनी चाहिए
    • 100% सहमत। password-less future को लेकर उत्साह है, लेकिन बिना explanation के एक block लगते ही यह physical wallet खोने जैसा हो जाता है

  • Lauren Weinstein चेतावनी दे रहे हैं कि Passkey flawed है और खासकर आम users के लिए बहुत बड़ा सिरदर्द बनने वाला है
    https://mastodon.laurenweinstein.org/@lauren/111103819626952...
    https://mastodon.laurenweinstein.org/@lauren/111211366080459...

    • सही है। मुझे भी कई सालों से ऐसी ही शिकायतें रही हैं
      privacy और vendor lock-in वाली समस्याओं को फिलहाल अलग रखें, तो Passkey उन लोगों के लिए बहुत खराब विकल्प नहीं है जो 2-factor authentication के बिना हर website पर वही basic password reuse करते हैं
      लेकिन जैसे ही आप किसी चीज़ को सच में protect करने के लिए इस पर निर्भर होने लगते हैं, यह जल्दी ही बहुत बड़ा nightmare बन जाता है। ऊपर से इसे password+2-factor authentication के बराबर मानने की वजह से बात और खराब हो जाती है
    • flaw क्या है, यह कहाँ समझाया है?
      कहते हैं “ढूँढना आसान है”, लेकिन लगता है खुद ढूँढ नहीं पा रहे
      https://mastodon.laurenweinstein.org/@lauren/111211489395997...
      अगर user वैसे भी weak service password इस्तेमाल करने की संभावना रखता है, तो समझ नहीं आता कि weak device password Passkey से बचने की वजह क्यों होनी चाहिए
    • यह साफ नहीं है कि सिरदर्द क्या है। अगर मुद्दा यह है कि Passkey के आम users पर क्या नतीजे होंगे, तो ज़्यादातर लोग mobile device पर Google account में logged in रहते हैं
      ऐसे में device authentication टूट जाए तो account तो वैसे भी compromised है
      खासकर Google में अभी ऐसा structure नहीं है कि password और Passkey में से केवल एक ही चुनना पड़े। अगर device पर Passkey नहीं है, तो password login flow पर वापस जा सकते हैं
    • यह debate data न होने की वजह से frustrating है। बस इस पर opinions भरे हैं कि कौन सा risk दूसरे से ज़्यादा खराब है
      risks और benefits की तुलना करने के लिए यह जानना होगा कि लोग असल में passwords कितना reuse करते हैं, 2-factor authentication इस्तेमाल करते हैं या नहीं, सभी account access के लिए सिर्फ phone screen lock पर निर्भर हैं या नहीं, biometric authentication इस्तेमाल करते हैं या नहीं, account recovery कितनी ज़रूरी पड़ती है, वगैरह
      वही data debate को सुलझा सकता है और हर व्यक्ति को अपनी स्थिति के अनुसार अलग निष्कर्ष निकालने में भी मदद कर सकता है
      Google के पास ऐसा ज़्यादातर data है। अपने दावे को support करने के लिए उसे इसे public करना चाहिए
    • “weak device authentication” से क्या मतलब? मुझे लगा आजकल सभी phones में fingerprint recognition या face recognition होता है

  • 1Password ने हाल ही में Passkey support चालू किया, लेकिन यह जानकर “हैरानी” हुई कि इसे 1Password से बाहर export करने का कोई तरीका नहीं है
    यह 1PUX format export में भी शामिल नहीं है, CSV में भी नहीं
    यानी सचमुच backup असंभव है। अगर 1Password down हो जाए, कंपनी बंद हो जाए, या ऐसा कुछ हो, तो Passkey बस गायब हो जाएगी। उसे recover करने का कोई तरीका बिल्कुल नहीं है

    • अभी Passkey क्षेत्र के बड़े players में से कोई भी Passkey export या import support नहीं करता। वजह यह है कि इसे सुरक्षित तरीके से करने की specification पर अभी सहमति नहीं बनी है, और कोई भी Passkey का plaintext export allow नहीं करना चाहता
      इस topic पर हाल की 1Password Passkey AMA post देखें:
      https://old.reddit.com/r/1Password/comments/16to6x7/hey_redd...
      1Password बंद होने की स्थिति की बात करें, तो passwords और Passkey, device पर sync होते समय दोनों locally भी store होते हैं। अगर किसी वजह से 1Password access नहीं कर पाते, तब भी vault के अंदर मौजूद सभी items तक access बना रहता है; बस devices के बीच sync नहीं हो पाएगा
    • क्या यही Passkey का मकसद नहीं है? users इसे सीधे handle न कर सकें, ताकि social engineering attacks से इसे चुराया न जा सके
      Passkey को devices के बीच move करने के बजाय, इसे SSH keys की तरह देखना चाहिए: हर device के लिए अलग Passkey बनाएं और related services में सभी को register करें
      बेशक, user को attacker की Passkey अपने account में add करने के लिए धोखा दिया जा सकता है
    • मां को बदलने के लिए कहते हुए एक बार बातचीत हुई थी; उनका email internet provider से बंधा है, इसलिए वे internet provider बदलने से डरती हैं
      mobile में हमने यह समस्या कई साल पहले हल कर ली थी, लेकिन email अभी भी गड़बड़ है। सबक यह है कि कभी भी dependent मत बनो
    • क्या third-party self-hosted password managers में कोई ऐसा है जो सच में export और safe backup के साथ compatible Passkey implementation देता हो?
    • 1Password का Passkey support काफी aggressive growth hacking जैसा लगता है
      यह window.credentials calls intercept करता है, और अगर आप Yubikey जैसे किसी दूसरे verification method के साथ 1Password use करना चाहते हैं, तो settings में जाकर पूरा Passkey feature बंद करना पड़ता है
      यह Google One Tap prompt को intercept करके globally disable करने और उसकी जगह अपना OAuth prompt दिखाने के तरीके जैसा भी है। मैं सिर्फ Chrome extension use करता हूं, इसलिए native app experience बहुत अलग है या नहीं, पता नहीं

  • user के नजरिए से यह अब भी समझ नहीं आता
    अगर घर में आग लग जाए या कुछ ऐसा हो और Google में logged-in सभी devices खराब हो जाएं, तो क्या होगा? account में दोबारा login कैसे करेंगे?

    • मेरे ससुराल पक्ष के परिवार में सच में ऐसा हुआ था। सीढ़ियों पर phone गिर गया, screen टूट गई और वह respond करना बंद कर गया
      मैंने उन्हें एक पुराना phone दिया, SIM तो ठीक से transfer हो गया, लेकिन Google account login किसी तरह नहीं हो पाया। क्योंकि Google लगातार “phone use करें” कहकर अड़ा रहा। laptop भी email से logged out था
      सौभाग्य से एक पुराने incident की वजह से मेरे पास backup token था, इसलिए मामला सुलझ गया। बाकी लोग क्या करेंगे, पता नहीं
    • Google ने इसे कैसे solve किया है, मुझे नहीं पता, लेकिन एक पुराना solution है: Shamir's Secret Sharing
      key को M टुकड़ों में बांटा जाता है, और उसे reconstruct करने के लिए उनमें से N टुकड़े चाहिए होते हैं। उदाहरण के लिए 3/8 में 8 टुकड़ों में से सिर्फ 3 टुकड़े हों तो key recover की जा सकती है। हर टुकड़ा भरोसेमंद लोगों को दिया जाता है, और recovery के समय उनमें से कम से कम 3 लोगों से टुकड़े लेकर key फिर से बनाई जाती है
      जब मैंने multipasskey नाम के YC demo में इसे implement किया था, तो trusted contacts चुनवाता था और background में key के टुकड़े उन्हें भेजता था। recovery चाहिए होती, तो उनसे request करते, और पर्याप्त टुकड़े मिलते ही device key reconstruct हो जाती। device key बनते ही remote server से encrypted key backup download होकर सब कुछ नए जैसा recover हो जाता
      2017/2018 में मैंने इस project को multipasskey नाम देकर working demo के तौर पर YC में apply किया था, लेकिन reject हो गया। मुझे लगा शायद मैं ठीक से समझा नहीं पाया
    • साथ ही, इस article में बुनियादी non-technical सवालों के जवाब देने वाली FAQ से link न करना काफी कमजोर है
      एक तकनीकी व्यक्ति के तौर पर मैं अनुमान लगाता हूं कि इसका मतलब है कि backup device किसी दोस्त के पास रखना चाहिए, या Passkey को Apple/Microsoft/password manager account में भी store करना चाहिए
      लेकिन Google को ज्यादा detail में explain करना चाहिए
    • मैंने सच में आग का सामना किया है। landlord ने मेरा phone बचाकर दे दिया, इसलिए बस वही बचा और बाकी सारी चीजें खो गईं। अगर ऐसा न होता, तो TOTP apps सब उसी में थे और मैं पूरी तरह lock out हो जाता
      और अपना phone number कभी मत खोना। username, password, recovery email होने पर भी SMS code नहीं मिल पाने की वजह से Google account में वापस नहीं जा पाते
    • Passkey एक नई technology है, और users, service providers, organizations—सभी को सीखने और adapt करने में समय लगेगा
      इस transition period में, पहले से दिए जा रहे तरीकों के alternative के रूप में Passkey provide करना recommended है। Google और कई service providers यही कर रहे हैं
      हालांकि आपने जो सवाल उठाया है, वह Passkey न होने पर भी सभी को पूछना चाहिए: account recovery। अगर password भूल जाएं, password manager access न कर पाएं, या second authentication device खो दें, तो login कैसे करेंगे—इसकी planning होनी चाहिए। Passkey अपनाने से account recovery की चिंता पूरी तरह खत्म नहीं होती
      फिर भी कुछ खास cases में Passkey account recovery को बेहतर बना सकती है। Apple devices पर iCloud Keychain use करते हुए अगर Google account के लिए Passkey बनाते हैं, तो वह Passkey iCloud में sync हो जाती है। ऐसे में घर जल जाए और सभी devices खो जाएं, तब भी अगर iCloud account access कर सकते हैं, तो Google account और दूसरी websites की Passkeys वापस मिल सकती हैं
      बेशक, “अगर Apple iCloud account का access खो जाए तो?” यह सवाल जायज है। इसलिए account recovery की समस्या पूरी तरह गायब नहीं होती, लेकिन कई cases में Passkey इसे काफी कम कर सकती है

  • यहाँ सिम्पसन का विरोधाभास है
    औसतन, इससे सुरक्षा बढ़ सकती है। क्योंकि ज़्यादातर users passwords का बहुत ही खराब इस्तेमाल करते हैं
    लेकिन जो advanced users passwords को सुरक्षित तरीके से इस्तेमाल करते हैं, उनके लिए अगर इसे ज़बरदस्ती लागू किया जाए तो सुरक्षा बहुत तेज़ी से गिर जाती है
    ज़बरदस्ती phone number 2-step authentication का भी यही असर है। Big G के मामले में, ज़बरदस्ती phone number 2-step authentication सुरक्षा के नाम पर पैक की गई anti-anonymity policy है। इस बार यह biometric information हासिल करने की कोशिश जैसा दिखता है

    • “ज़बरदस्ती phone number 2-step authentication सुरक्षा के नाम पर पैक की गई anti-anonymity policy है” — यह दोनों हो सकता है। असल में इसकी संभावना बहुत ज़्यादा है
      phone number ज़्यादातर लोगों के पास मौजूद सबसे अच्छी long-term identity है, और Google को अरबों users के account recovery को बेहिसाब बड़े scale पर support करना पड़ता है
      बहुत लोग password और devices खो देते हैं, लेकिन phone number खोने वाले बहुत कम होते हैं
      इसलिए Google का अपने platform पर identity देने और delegate करने के लिए phone number का इस्तेमाल करना तार्किक रूप से जुड़ता है। privacy के लिए यह बुरा है, लेकिन security के लिए बहुत अच्छा है, क्योंकि यह users को खुद manage किए बिना third-party authentication “credential” के रूप में data control करने देता है
    • अगर advanced users passwords को सुरक्षित तरीके से इस्तेमाल करते हैं तो सुरक्षा तेज़ी से क्यों गिरती है? क्योंकि device चोरी हो सकता है और PIN guess किया जा सकता है? अगर चाहें तो PIN की जगह लंबा password इस्तेमाल नहीं कर सकते क्या?
      और इस हिस्से को लेकर मैं पक्का नहीं हूँ, इसलिए जिसे पता हो वह सुधार दे। कमजोर passwords, reuse और phishing से immune advanced user मान भी लें, तो मेरी समझ में security का एक फायदा है। अगर Google Passkey leak हो भी जाए, तो leak सिर्फ public key होती है, और public key से login नहीं किया जा सकता, इसलिए leak लगभग बेकार हो जाती है
    • biometric information local device के अंदर key store को unlock करने के लिए इस्तेमाल होती है, और उसके अंदर private key होती है। उससे public key derive की जा सकती है, और Passkey का सार वेबसाइट login verify करने के लिए इस्तेमाल होने वाला public key/private key pair है
      अगर Google biometric information collect कर रहा होता, तो वह पहले से ही ऐसा कर रहा होता, और इसका इस feature से कोई संबंध नहीं होता
      इस security model की बहुत basic details iPhone के Secure Enclave इस्तेमाल शुरू करने के समय से ही लंबे समय से सच रही हैं। मुझे समझ नहीं आता कि इस site पर लोग जिन चीज़ों को बिल्कुल नहीं समझते, उनके बारे में इतने पक्केपन से क्यों बोलते हैं, और सच कहूँ तो यह हैरान करने वाला है
      Passkey नैतिक रूप से server पर login करते समय SSH password की जगह SSH key इस्तेमाल करने के बराबर है, बस इसे वेबसाइट पर लागू किया गया है। इसके अलावा objectively भी एक सरल तथ्य है जिसे “password सुरक्षित तरीके से इस्तेमाल करने” के विचार से बदला नहीं जा सकता। Passkey सचमुच phishing-resistant है
    • Passkey Google या Apple पर निर्भर नहीं है। कंपनियों और सरकारों को जैसे चाहिए होता है, वैसे आप अपना खुद का custodian या manager रख सकते हैं

  • यह देखकर हैरानी है कि वे इसे पहले ही push कर रहे हैं। पिछले हफ्ते तक भी implementation में काफी rough edges बचे थे, इसलिए मैंने अपने Workspace tenant में इसे disable कर दिया था
    सबसे परेशान करने वाली दो बातें हैं: Advanced Protection अभी Passkey support नहीं करता, इसलिए फिलहाल U2F बनाए रखना होगा; और अगर account में U2F key set है, तो Google पहले उसे Passkey की तरह इस्तेमाल करने को कहता है, फिर बताता है कि यह Passkey नहीं है, इसलिए password से login करें
    नतीजतन phishing-resistant multi-factor authentication इस्तेमाल करने वाले लोग device पर multi-factor authentication step को “remember” कराने की सुविधा खो देते हैं। क्योंकि Google हमेशा password से पहले U2F authentication factor मांगता है
    इससे अलग, कुछ छोटे customers के लिए Okta-based passwordless login deploy करने की तैयारी करते हुए मैंने security keys और Passkeys के साथ FIDO2 flows को device types और platforms पर काफी test किया है। authentication flow खुद कुल मिलाकर पसंद है, लेकिन सावधानी रखने लायक कई pitfalls हैं
    happy path को व्यवस्थित करने, onboarding material बनाने और business continuity scenarios document करने में काफी समय लगा। personal use case कुछ मायनों में और कठिन है, क्योंकि एक single IdP नहीं बल्कि हर service के बारे में सोचना पड़ता है
    अगर आपको कई environments support करने हैं, तो अभी आसान रास्ता 1Password या Passkey support करने वाले किसी दूसरे password manager में invest करना है। यह सबसे consistent user experience देता है और अधिकांश platforms पर काम करता है, लेकिन Android 14 में अभी भी समस्याएँ हैं
    high-privilege accounts के लिए मैं hardware keys ही इस्तेमाल करता रहूँगा, इसलिए admins को FIDO2 keys की एक जोड़ी मिलेगी। बाकी लोगों को एक Yubikey मिलेगी, जो device access खोने या untrusted device से login करना पड़े तो backup का काम करेगी। Android यहाँ भी समस्या है। 14 में भी ऐसा लगता है कि passwordless FIDO2 flows support नहीं करता

    • Android क्यों support करेगा? Passkey Google को customers को lock-in effect में बाँधे रखने का एक और मौका देता है

  • दिलचस्प दिशा है। लेकिन यह बात कहने लायक है कि fingerprint या face recognition जैसी biometric information असल में “secret” नहीं होती
    इसे user की जानकारी या consent के बिना observe या use किया जा सकता है, और कई मायनों में यह password की बजाय username की तरह काम करती है

    • password भी definition के हिसाब से share होता है, इसलिए पूरी तरह secret नहीं है। Passkey public key cryptography इस्तेमाल करता है और हर मायने में ज़्यादा सुरक्षित है
    • क्या device तक physical access और fingerprint या face भी होना ज़रूरी नहीं है?
    • Passkey खुद biometric authentication नहीं है। उदाहरण के लिए, TouchID इस्तेमाल करने का मतलब यह नहीं कि Google fingerprint से user को authenticate कर रहा है
      fingerprint सिर्फ authentication में इस्तेमाल होने वाली cryptographic key pair को unlock करता है
      मैं Yubico Security Key को Passkey के रूप में इस्तेमाल कर रहा हूँ, और यह 6-digit PIN से protected है। वह PIN केवल device-local है, और इसका काम device को physical रूप से रखने वाले व्यक्ति को तुरंत login करने से रोकना है। PIN लगातार 10 बार गलत डालने पर key मिट जाती है
      PIN डालने पर key unlock होती है, और Google account में जाने देती वही key है

  • passwords वाले ज़्यादातर accounts में “company को अपनी identity साबित कर दें तो reset कर देंगे” वाला safety net होता है। जैसे अगर bank password याद न हो तो bank के पास reset करने का रास्ता होता है
    Google द्वारा control की जाने वाली चीज़ों में problem solve करने के लिए contact करने का कोई तरीका ही नहीं है। यह पहले से ही सभी Google products में समस्या है
    सभी access को Google द्वारा control किए गए दरवाज़े के पीछे lock करना भविष्य का nightmare खुद तैयार करना है

  • अफसोस है कि अभी Bitwarden में Passkey store नहीं कर सकते। फिर भी इस page के top message के मुताबिक लगता है कि October में यह आ जाएगा
    https://bitwarden.com/blog/bitwarden-passkey-management/