Pass-ta-key: Google Passkey पर हमले का असली अर्थ

क्या Passkey आखिरकार असुरक्षित हैं? Pass-ta-key ठीक यही सवाल उठाता है।

Palo Alto Networks Unit 42 ने तीन attack chain बताए हैं, जिनसे malware Google के synced Passkey का दुरुपयोग कर सकता है, User Verification को पार कर सकता है और सबसे गंभीर स्थिति में किसी account की सभी private Passkey key निकाल सकता है।

इन तीनों तकनीकों में से कोई भी WebAuthn, FIDO2 या इस्तेमाल की गई public-key cryptography को नहीं तोड़ती। सभी के लिए पीड़ित के Windows PC पर पहले से malware चलना जरूरी है। यह एक महत्वपूर्ण सीमा है।

फिर भी, यह कहना कि “compromised endpoint पर तो सब कुछ पहले ही खत्म है”, बहुत सुविधाजनक विश्लेषण होगा। Golden Pass-ta-key स्थानीय घुसपैठ को सभी synced Passkey के लंबे समय तक इस्तेमाल और export किए जा सकने वाले पैकेज में बदल सकता है। इसका असर एक browser session की चोरी से कहीं आगे जाता है।

संक्षिप्त आकलन

हाँ, यह एक नया और स्वतंत्र security विषय है। लेकिन यह Passkey हटाने या फिर केवल password पर लौटने का कारण नहीं है।

सही निष्कर्ष यह है:

• Protocol कायम है: Origin Binding, Challenge-Response और asymmetric cryptography नहीं टूटे हैं।
• विशिष्ट implementation पर हमला है: Unit 42 द्वारा जाँचे गए Google Password Manager, Chrome, Windows और TPM के संयोजन पर असर पड़ता है।
• Endpoint पहले से compromised होना चाहिए: Internet की कोई भी website साफ कंप्यूटर पर सीधे यह हमला नहीं कर सकती।
• संभावित नुकसान फिर भी गंभीर है: नतीजे चुपचाप बने login assertion से लेकर सभी synced Passkey की private key निकालने तक हो सकते हैं।
• Synced और device-bound Passkey के risk profile अलग हैं: दोनों Passkey हैं, लेकिन समान security level नहीं देते।
• Password अब भी बदतर विकल्प हैं: उन्हें phish, reuse, guess और server database से चोरी किया जा सकता है।

इसलिए मेरा risk assessment “कुछ नहीं हुआ” नहीं, बल्कि यह है: तकनीकी दायरा सीमित और पूर्वशर्त कठिन है, लेकिन सफलता पर संभावित प्रभाव बहुत बड़ा है।

तकनीकी दायरा और प्रमाण

31 अगस्त 2026 तक प्रमाणित स्थिति में Unit 42 के दर्ज attack flow, WebAuthn specification, Google का Passkey documentation, सार्वजनिक Chromium issue और sync किए जा सकने वाले authenticator के लिए मौजूदा NIST निर्देश शामिल हैं। Attack surface के आकलन में SpecterOps का Pass-the-Passkey, CVE-2026-34348, Proofpoint का FIDO downgrade और Expel तथा SquareX के तकनीकी निष्कर्ष भी प्रासंगिक हैं।

यह शोध 3 अगस्त को प्रकाशित हुआ और Unit 42 ने इसे 14 अगस्त को update किया। यह स्पष्ट रूप से TPM वाले Windows device पर Chrome में Google Password Manager से संबंधित है। अन्य browser, operating system और Passkey provider में ऐसे architecture प्रश्न हो सकते हैं, लेकिन इन तीन हमलों से वे प्रमाणित नहीं हुए हैं।

इन विशिष्ट तकनीकों के सक्रिय इस्तेमाल वाला कोई वास्तविक attack campaign दर्ज नहीं है। वर्तमान प्रमाण शोध, Proof of Concept और Responsible Disclosure पर आधारित है। Risk assessment के लिए यह अहम है: तकनीकी demonstration का मतलब यह नहीं कि हमला पहले से बड़े पैमाने पर हो रहा है।

Passkey वास्तव में किस चीज की सुरक्षा करता है

Passkey कोई बहुत लंबा password नहीं है। यह asymmetric cryptography पर आधारित WebAuthn credential है।

Registration के समय authenticator एक key pair बनाता है:

private key -> remains with the authenticator
public key  -> is registered with the online service

WebAuthn में “Relying Party” कहलाने वाली online service public key को Credential ID और user account के साथ रखती है। बाद में login पर service एक नया random challenge भेजती है। Authenticator ऐसे data को sign करता है जिसमें यह challenge और request करने वाली website का context बँधा होता है। Server रखी हुई public key से signature जाँचता है।

इसलिए private key को password की तरह server पर नहीं भेजा जाता। आदर्श स्थिति में service का data leak हमलावर को केवल public key देता है। उससे वैध signature नहीं बन सकता।

Relying Party ID और Web Origin से binding भी निर्णायक है। example.com का Passkey उससे मिलते-जुलते phishing domain पर example.com के लिए वैध assertion नहीं बनाता। User के पास ऐसा secret नहीं है जिसे वह गलत website पर type कर दे या फोन पर हमलावर को बता दे।

यही phishing-resistant होने का अर्थ है। NIST इसे सख्ती से परिभाषित करता है: धोखेबाज verifier को न authentication secret मिलना चाहिए, न असली service पर इस्तेमाल योग्य authentication response। WebAuthn verifier के नाम से cryptographic binding के जरिए इसे हासिल करता है।

Pass-ta-key में यह गुण कायम रहता है। Malware बेहतर phishing site नहीं बनाता। वह पहले से उस device पर चलता है जिसे user trusted authenticator मानता है।

User Presence और User Verification एक चीज नहीं हैं

तीनों हमले समझने के लिए दो WebAuthn signal अलग करने होंगे:

• User Presence, UP: User ने मौजूदगी की कोई action की, जैसे Security Key छूना या dialog confirm करना।
• User Verification, UV: Authenticator ने user को स्थानीय रूप से verify किया, जैसे Windows Hello, PIN या biometrics से।

WebAuthn assertion के authenticatorData में ये नतीजे flag के रूप में होते हैं। Server केवल इस बात पर भरोसा नहीं कर सकता कि login शुरू करते समय उसने क्या माँगा था। अगर वह userVerification: "required" माँगता है, तो response में UV flag वास्तव में set है या नहीं, इसे भी जाँचना होगा।

यह एक check बहुत महत्वपूर्ण है। जरूरी User Verification न मिलने के कारण Unit 42 साधारण Pass-ta-key attack को GitHub पर सफलतापूर्वक पूरा नहीं कर पाया। eBay पर User Verification माँगे जाने के बावजूद शुरू में login सफल हुआ। Report के बाद eBay ने server-side validation ठीक किया।

यह अंतर दिखाता है कि cryptographically सही signature हमेशा सही तरह implement किए गए multi-factor authentication के लिए पर्याप्त नहीं है। Authenticator ने वास्तव में कौन सी security condition प्रमाणित की, Relying Party को यह भी validate करना होगा।

Synced Passkey अतिरिक्त trust boundary क्यों बनाते हैं

Device-bound Passkey किसी खास authenticator पर रहता है, जैसे hardware Security Key या स्थानीय रूप से सुरक्षित platform authenticator। इसके विपरीत synced Passkey कई device पर उपलब्ध होने के लिए बनाया जाता है। इसलिए उसके private key material का encrypted backup, Sync Infrastructure से transport और दूसरे authorized device पर restore संभव होना चाहिए।

यह implementation का मामूली अंतर नहीं है। Synchronization system को बढ़ाता है:

Relying Party
    |
browser and WebAuthn client
    |
local platform authenticator
    |
passkey manager and recovery logic
    |
cloud sync and additional devices

हर अतिरिक्त layer को device trust, onboarding, recovery, key encryption और revocation के अपने नियम चाहिए।

इसीलिए NIST sync किए जा सकने वाले authenticator को अलग category मानता है। वे Authentication Assurance Level 2 तक के scenario के लिए उपयुक्त हो सकते हैं। AAL3 के लिए NIST hardware-protected environment या अलग authenticator में non-exportable key माँगता है। इसका अर्थ synced Passkey कमजोर होना नहीं है। इसका अर्थ है कि सुविधा और key portability अलग assurance model बनाते हैं।

Pass-ta-key इसी अतिरिक्त trust boundary पर हमला करता है।

शोध का सटीक दायरा

Unit 42 ने कई पूर्वशर्त बताई हैं जिन्हें बहुत सी headline ने कम महत्व दिया:

• प्रभावित synced Passkey को Google Password Manager manage करता है।
• Chrome Windows पर चल रहा है।
• Device में TPM है।
• Malware पहले से पीड़ित के user context में चल रहा है।
• User संबंधित Chrome और Google environment में setup है।
• कुछ variant में malware को स्थानीय Chrome data पढ़ना, state file बदलना या Chrome process memory देखना पड़ता है।

हर Passkey के विरुद्ध universal attack नहीं दिखाया गया। यह भी नहीं दिखाया गया कि बिना पहले endpoint compromise किए कोई remote attacker TPM से आसानी से WebAuthn key निकाल सकता है।

इसलिए “Passkey crack हो गए” कहना गलत होगा। सटीक बात यह है: Unit 42 ने compromised Windows endpoint पर synced Google Passkey के trust, onboarding और recovery mechanism के खिलाफ तीन attack chain दिखाए।

Phase zero: स्थानीय Passkey नक्शा

Unit 42 के अनुसार तीनों variant से पहले malware स्थानीय Chrome Sync Database पढ़ता है। वहाँ WebauthnCredentialSpecifics record होते हैं। उनमें Relying Party information, username, Credential ID और encrypted private key material जैसी चीजें शामिल हैं।

शोध में दिया path है:

%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB

Test में इन record तक पहुँचने के लिए elevated privilege जरूरी नहीं था। Private key material सीधे plaintext में नहीं है, लेकिन metadata malware को target list देता है: किन service के लिए Passkey हैं, वे किन account के हैं और किस Credential ID को इस्तेमाल करना है?

Detection के लिहाज से भी यह प्रासंगिक है। Infostealer को target का अनुमान नहीं लगाना पड़ता। वह पहले inventory बना सकता है और फिर चुनकर high-value account पर हमला कर सकता है।

Pass-ta-key: User action के बिना वैध assertion

पहला variant उस device key का दुरुपयोग करता है जिससे Chrome, Google Cloud Authenticator को Windows device की identity साबित करता है।

इसके लिए Chrome TPM-backed Identity Key बनाता है। Unit 42 के अनुसार Chrome private key को साधारण plaintext key की तरह store नहीं करता। इसके बजाय वह Windows CNG से इसे NCRYPT_OPAQUE_KEY_BLOB के रूप में export करता है। TPM blob को इस तरह सुरक्षित रखता है कि उसी physical TPM पर cryptographic operation के लिए फिर import किया जा सके।

Cryptography के हिसाब से यह उचित है, लेकिन authorization problem अपने आप हल नहीं होती। शोध के अनुसार सामान्य user context में malware stored wrapped_identity_private_key पढ़ या Chrome memory से निकाल सका और नियमित Windows CNG function call कर सका। Request तकनीकी रूप से सही device से आने के कारण TPM signature बनाता है। API को Chrome ने call किया या malware ने, TPM यह नहीं जानता।

सरल रूप में flow ऐसा है:

attacker requests a fresh challenge from the online service
    -> malware on the victim PC uses the TPM-bound identity key
    -> Google Cloud Authenticator accepts the device identity
    -> Cloud Authenticator creates a valid passkey assertion
    -> attacker submits the assertion to the online service

इस variant में private Passkey file को export करना जरूरी नहीं है। Malware compromised device और Google के Cloud Authenticator को signing service की तरह इस्तेमाल करता है।

प्राकृतिक सीमा UV flag है। Identity Key device possession साबित करता है, सफल PIN या biometric check नहीं। User Verification अनिवार्य करने और नतीजा जाँचने वाली सही तरह implement की गई service को UV = 0 assertion reject करना चाहिए।

इससे variant harmless नहीं हो जाता। Compatibility या UX के कारण कई service User Verification को केवल preferred configure करती हैं। कुछ इसे माँगती हैं, लेकिन response गलत ढंग से जाँचती हैं। ऐसे मामलों में multi-factor के रूप में सोचा गया login व्यवहार में एक factor रह जाता है: device identity तक access।

Silver Pass-ta-key: हमलावर अपनी UV identity register करता है

Silver Pass-ta-key अभी बताई सीमा को पार करता है। हमलावर Windows Hello या पीड़ित की biometrics तोड़ने की कोशिश नहीं करता। वह Cloud Authenticator से अपनी key को आगे User Verification के वैध प्रमाण के रूप में स्वीकार करवाता है।

शुरुआत Re-Onboarding process से होती है। शोध के अनुसार malware Cloud Authenticator को पुरानी device state भुलवा सकता है या स्थानीय passkey_enclave_state file delete कर सकता है। अगली Passkey operation पर Chrome को device फिर register करना पड़ता है।

Windows पर पहले चरण में User Verification Key बनना जरूरी नहीं। Chrome पहले Google Password Manager Recovery PIN इस्तेमाल करके uv_key_pending state set कर सकता है। असली UV Key अगली Passkey use पर आती है। User experience आसान करने वाली यह intermediate state समय की एक खिड़की खोलती है।

तैयारी में पीड़ित को अचानक शुरू हुई recovery या Re-Onboarding प्रक्रिया पूरी करके GPM PIN डालना पड़ता है। Malware को PIN चुराना नहीं पड़ता। वह उसके बाद बनी uv_key_pending state इस्तेमाल करता है। बाद के दुर्भावनापूर्ण login बिना आगे interaction और पीड़ित का device उपलब्ध हुए बिना हो सकते हैं।

हमलावर अपने environment में key pair बनाता है और public key को नई UV Key के रूप में भेजता है। Unit 42 के नतीजों के अनुसार Google Cloud Authenticator ने यह validate नहीं किया कि नई key सचमुच trusted hardware से आई है। System ने वैध device identity के साथ हमलावर की key भी store कर ली।

अब हमलावर अपनी private key से request sign कर सकता है। Cloud Authenticator उन्हें locally हुई User Verification की तरह मानता है और UV flag set किए assertion बनाता है। बाद के login पर पीड़ित का PC online नहीं रहना पड़ता।

सार्वजनिक Chromium issue इस behavior को “GPM Passkeys Are Vulnerable to User Verification Key Abuse” कहता है। मेरी जाँच के समय यह WAI marked था। Internal assessment से अलग, मामला एक महत्वपूर्ण architecture rule दिखाता है: नई trusted key bind करने वाली recovery या onboarding प्रक्रिया अपने आप में अत्यंत critical authentication event है।

Golden Pass-ta-key: Cloud Sync से export योग्य key material

Golden Pass-ta-key सबसे गंभीर variant है। इसका लक्ष्य Security Domain Secret, संक्षेप में SDS है। 32 byte का यह secret Google Password Manager account की synced private Passkey key को सुरक्षित करता है।

सरल रूप में architecture का वादा यह है: Client के पास केवल encrypted wrapped_secret होता है। Device-specific key से decryption Cloud Authenticator में होती है। इसलिए client पर malware होने पर भी private Passkey key आसानी से नहीं मिलनी चाहिए।

Onboarding और recovery के दौरान Sync Infrastructure को device फिर Security Domain में जोड़ने होते हैं। Unit 42 ने पाया कि इस प्रक्रिया में Chrome को client के लिए accessible रूप में SDS मिलता है। शुरू में यह Chrome के FIDO diagnostic log में भी दिखा। Report के बाद Google ने यह log output हटा दिया। प्रक्रिया के दौरान SDS अब भी Chrome process memory तक पहुँचता है।

इसलिए Golden Pass-ta-key किसी भी समय किया गया साधारण memory dump नहीं है। Malware पहले security-critical onboarding या recovery path शुरू करवाता है और उसे वह सही समय पकड़ना होता है जब SDS Chrome process में मौजूद हो। इससे हमला कठिन होता है, लेकिन सफल extraction के बाद चुराए secret का दायरा कम नहीं होता।

इसलिए attack chain कई चरण जोड़ता है:

1. Malware नया onboarding अनिवार्य करवाता है।
2. वह स्थानीय Enclave state के फिर बनने या बदलने का इंतजार करता है।
3. सही समय पर Chrome process memory पढ़कर SDS खोजता है।
4. SDS को पहले पढ़े Sync record से जोड़ता है।
5. उनमें मौजूद private Passkey key decrypt करता है।
6. फिर पीड़ित के device से स्वतंत्र authenticator वैध assertion बना सकता है।

चुराए गए Session Cookie से गुणात्मक अंतर यहाँ है। Session expire या server-side revoke हो सकता है। Golden Pass-ta-key इसके विपरीत पहले से synced सभी Passkey की private key export कर सकता है। Unit 42 ने यह भी लिखा कि वही SDS भविष्य में बने synced Passkey को सुरक्षित करता है और जाँचे गए architecture में SDS को rotate या revoke करने का कोई स्पष्ट तरीका नहीं था।

यह कथन जाँचे गए Google implementation की स्थिति बताता है। यह प्रमाण नहीं कि हर Passkey provider वही Master Key architecture इस्तेमाल करता है या Google इसे कभी बदल नहीं सकता।

स्थानीय malware के बावजूद हमला महत्वहीन क्यों नहीं है

Logged-in PC के user context में मनचाहा malware चला सकने वाले हमलावर के पास कई आसान रास्ते होते हैं। वह Session Cookie चुरा, browser content पढ़, transaction बदल, file exfiltrate या active account में user की जगह काम कर सकता है। कोई authentication method पूरी तरह compromised client पर बिना शर्त भरोसा नहीं कर सकता।

मूल attack class भी नई नहीं है। Compromised Password Manager और browser से secret या active session निकालना वर्षों से Infostealer के toolkit का हिस्सा है। Pass-ta-key पहले से मौजूद endpoint compromise को कोई जादुई remote attack नहीं बनाता।

फिर भी इसे महत्वहीन कहना अधूरा होगा। शोध ने implementation-specific ऐसी बातें दिखाईं जो पहले स्वतः स्पष्ट नहीं थीं:

• Unprivileged process signature के लिए TPM-bound Chrome device key इस्तेमाल कर सका।
• Device possession और User Verification की सीमा Relying Party द्वारा UV flag के सही evaluation पर निर्भर थी।
• Re-Onboarding state ने attacker-controlled UV Key register होने दी।
• Central Sync secret पहले log में दिखी और शोध के अनुसार बाद में process memory में accessible रही।
• सबसे गंभीर path ने synced private key को मूल device के बाहर reuse योग्य बना दिया।
• कई वैध device एक credential इस्तेमाल करते हैं, इसलिए synced Passkey में classical signature counter अक्सर भरोसेमंद cloning signal नहीं होता।

“Endpoint compromised” एक पूर्वशर्त है, पूरी damage description नहीं। Incident Response में इस बात से बड़ा फर्क पड़ता है कि हमलावर ने अस्थायी session चुराया या कई service के लिए लंबे समय तक इस्तेमाल योग्य private key material पाया।

नए attack surface का केवल एक हिस्सा है Pass-ta-key

Pass-ta-key अकेला नहीं आया। 2025 और 2026 के शोध कई रास्ते दिखाते हैं जिनसे हमलावर private key को mathematically तोड़े बिना Passkey की सुरक्षा घटा सकता है।

Sync और recovery के दुरुपयोग में Pass-ta-key को Windows endpoint पर पहले से malware चाहिए। Pass-the-Passkey logged assertion तक access को server-side replay flaw से जोड़ता है। FIDO downgrade के लिए एक अतिरिक्त active phishable login method पर्याप्त है, जबकि Passkeys Pwned को browser context में malicious extension या script execution चाहिए। अंत में Infostealer Passkey पर हमला नहीं करता, बल्कि compromised browser या endpoint से पहले से authenticated session चुराता है।

इनमें से कोई public-key cryptography नहीं तोड़ता। सभी WebAuthn के आसपास की किसी trust layer पर हमला करते हैं: Sync और recovery, server-side validation, browser या login के बाद का session।

यह अंतर शब्दों का खेल नहीं है। Protocol टूटता तो सभी conforming implementation बुनियादी रूप से संदेह में आते। यहाँ हर मामले को endpoint, browser, identity और server side पर अलग countermeasure चाहिए।

Pass-the-Passkey: जब वैध assertion फिर इस्तेमाल हो सके

Black Hat USA 2026 के लिए SpecterOps ने Windows 11 और Microsoft Entra ID में तीन vulnerability तथा उनसे निकली 20 से अधिक attack technique पहचानीं। सबसे महत्वपूर्ण chain अनपेक्षित जगह से शुरू हुई: Windows पूरे WebAuthn assertion को Microsoft-Windows-WebAuthN/Operational Event Log में लिख रहा था।

ऐसे assertion में Credential ID, Challenge, Authenticator Data और Signature शामिल होते हैं। वह private key नहीं है और सही Verifier implementation में केवल एक बार, संबंधित login session में चलना चाहिए। लेकिन SpecterOps ने पाया कि Entra ID ने सीमित समय के भीतर recorded assertion फिर स्वीकार किया। दो flaw एक साथ आए:

Windows logs a complete assertion
    -> an attacker reads it
    -> the verifier does not bind the challenge and assertion tightly enough to the session
    -> the same signed response is accepted again

Windows वाले भाग को CVE-2026-34348 identifier मिला। Microsoft ने 14 जुलाई 2026 को update जारी किया, जिसने logged signature को कुछ byte तक छोटा करके replay source हटा दिया। कुछ FIDO2 Security Key के लिए server-side signature counter check भी जोड़ा गया। पर signature counter universal protection नहीं है। कुछ platform और synced credential हमेशा zero देते हैं या कई device पर state share करते हैं।

यह exploit chain अब बंद है, लेकिन तकनीकी सबक व्यापक है। WebAuthn assertion diagnostic या Event Log में नहीं होने चाहिए। Challenge random, short-lived, single-use और खास login session से बँधा होना चाहिए। अकेला वैध signature पूरे login flow के सही होने का प्रमाण नहीं है।

एक और technique Windows WebAuthn API के Parent Window Handle से जुड़ी है। Local process असली Passkey dialog इस तरह रख सकता है कि वह browser या mail client जैसे trusted program का लगे। System UI असली है, लेकिन उसे शुरू करने वाला context भ्रामक हो सकता है। इसलिए अचानक आए Passkey और Windows Hello request को user को अनचाहे MFA push notification की तरह लेना चाहिए।

सबसे कमजोर fallback ही वास्तविक security level तय करता है

Proofpoint ने 2025 में Microsoft Entra ID के खिलाफ FIDO downgrade दिखाया। बदला हुआ Evilginx flow स्वयं को FIDO support न करने वाला browser बताता था। Target platform ने तब alternative login method दिए। पीड़ित ने SMS, OTP या दूसरी phishable method चुनी तो Adversary-in-the-Middle flow में credential और session लिए जा सकते थे।

हमला Origin Binding को bypass नहीं करता। वह WebAuthn ceremony को शुरू ही नहीं होने देता। यह तभी चलता है जब account में Passkey के साथ कमजोर method अनुमत हो। इस downgrade का वास्तविक हमलों में इस्तेमाल दर्ज नहीं है।

संगठनों के लिए नियम असुविधाजनक लेकिन साफ है: केवल Passkey register होने से policy phishing-resistant नहीं बनती। वह तभी ऐसा है जब संबंधित सुरक्षा जरूरत के लिए login में phishable fallback स्वीकार न हो। Recovery और Helpdesk Reset भी इसी आकलन में होने चाहिए।

Browser भी security model का हिस्सा है

SquareX ने Passkeys Pwned नाम से दिखाया कि browser context में malicious extension या script execution, navigator.credentials.create() और navigator.credentials.get() call को कैसे प्रभावित कर सकता है। Registration खास तौर पर महत्वपूर्ण है: सही समय पर हमलावर अपना key material डाल दे तो user असली biometric dialog देख सकता है, जबकि background में attacker-controlled credential bind हो रहा होता है।

यह शोध security provider का है और इसे universal browser exploit नहीं मानना चाहिए। पूर्वशर्त ही बड़ी है: extension या script context को WebAuthn path में जगह बनानी होती है। फिर भी architecture का सबक वैध है। Browser Extension, Content Script और वैध WebAuthn Proxy function Trusted Computing Base का हिस्सा हैं। Managed environment में Extension Allowlist और privileged Browser API का नियंत्रण केवल browser hygiene नहीं, identity protection है।

Passkey login को बचाता है, बाद के session को स्वतः नहीं

सफल login के बाद Web service आम तौर पर Session Cookie या Token से चलती है। Infostealer यह session artifact browser से चुरा ले और server दूसरे device से reuse स्वीकार करे, तो हमलावर को password या Passkey नहीं चाहिए। वह पहले से authenticated session पर हमला करता है।

बताए गए कई research Proof of Concept की तुलना में यह आज अधिक व्यावहारिक attack path है। Passkey login से पहले और उसके दौरान attack surface काफी कम करता है। लेकिन वह secure Token storage, risk के अनुसार कम session lifetime, critical action पर Re-Authentication, Token Revocation और जहाँ संभव हो high-value session को device से cryptographically bind करने का विकल्प नहीं है।

इसलिए session theft में “MFA bypass हुआ” कहना अक्सर भ्रामक है। MFA सफलतापूर्वक पूरा हुआ था। उसका परिणाम बाद में चुराया गया।

PoisonSeed दिखाता है कि शोध कितनी जल्दी hype बनता है

Expel ने जुलाई 2025 में पहले Passkey के Cross-Device Authentication पर कथित हमला बताया। हमलावर वैध QR code को phishing page से पीड़ित तक भेजकर दूर से login ले सकता था। कुछ दिन बाद Expel ने मुख्य दावा सार्वजनिक रूप से वापस लेकर माफी माँगी।

बाद के विश्लेषण में पता चला कि Cross-Device Authentication की local proximity check सफलतापूर्वक पार नहीं हुई थी। जरूरी निकटता के बिना flow expire हो गया, सभी MFA attempt विफल रहे और हमलावर को access नहीं मिला।

आज की बहस में मामला खास उपयोगी है। QR code, phishing और Passkey का हर विश्वसनीय लगने वाला मेल काम करने वाला FIDO bypass नहीं है। अच्छी security communication को observed account takeover, reproducible Proof of Concept, theoretical attack और disproven hypothesis अलग रखने चाहिए।

मेरा security आकलन

Pass-ta-key का तकनीकी दायरा सीमित है। TPM वाले Windows system पर Chrome में Google Password Manager के विरुद्ध attack chain प्रमाणित हुआ। संभावना मध्यम से कम है, क्योंकि malware को पहले स्थानीय रूप से चलना और variant के हिसाब से state या process memory को खास तरह बदलना पड़ता है।

संभावित प्रभाव ऊँचा से बहुत ऊँचा है। सफल हमला account takeover, स्थायी remote access या कई private key extraction करा सकता है। Protocol risk कम रहता है, क्योंकि WebAuthn, Origin Binding और public-key cryptography नहीं टूटे।

सामान्य user के लिए synced Passkey आम तौर पर SMS code या TOTP वाले password से अधिक सुरक्षित है। यह कई वास्तविक attack path से phishing, Credential Stuffing और reusable password data theft हटा देता है।

Privileged administrator, financial approval, production access या अधिक regulated system में सामान्य कथन पर्याप्त नहीं है। संगठन को तय करना चाहिए कि synced Passkey अपेक्षित assurance level पूरा करता है या नहीं। ऐसे account के लिए device-bound platform key या अलग FIDO2 Hardware Key बेहतर सीमा हो सकती है।

यह Sync Passkey को नकारना नहीं है। यह स्तरित security architecture है।

Web service operator को क्या जाँचना चाहिए

Relying Party के लिए मुख्य सबक असामान्य नहीं, साफ WebAuthn validation है।

Server को चाहिए:

• असली local User Verification जरूरी हो तो userVerification: "required" set करे,
• authenticatorData में लौटे UV flag को अनिवार्य रूप से जाँचे,
• Challenge, Origin, Relying Party ID और Signature पूरी तरह validate करे,
• हर Challenge random, short-lived और single-use बनाए तथा खास session से bind करे,
• पूरे assertion, signature और अन्य reusable authentication artifact को log से दूर रखे,
• Passkey registration, removal और Account Recovery को high-risk event के रूप में log करे,
• Privileged account में मजबूत Re-Authentication के बाद ही नया authenticator स्वीकार करे,
• संभव हो तो authenticator का origin और property record करे,
• High-security use case में Attestation और managed authenticator पर विचार करे,
• असामान्य device या geographic change और नई Passkey binding को Identity Telemetry में जोड़े,
• जोखिम वाले बदलाव के बाद session revoke और critical action फिर authenticate करे,
• platform और application भरोसेमंद support दें तो device-bound session इस्तेमाल करे।

Established WebAuthn library अधूरे custom implementation का जोखिम घटाती है, लेकिन operator को configuration जाँचने से मुक्त नहीं करती। eBay मामला दिखाता है कि एक unchecked flag अपेक्षित security level घटा सकता है। Pass-the-Passkey यह भी दिखाता है कि Challenge और session सही तरह bind न हों तो सही signature भी बेकार है।

Passkey rollout में संगठनों को क्या बदलना चाहिए

Passkey project अक्सर IAM project माना जाता है। Pass-ta-key दिखाता है कि वह endpoint, browser और recovery project भी है।

सामान्य workforce account के लिए synced Passkey अब भी उपयोगी है। वह Helpdesk workload घटाता और user को phishing से प्रभावी ढंग से बचाता है। Privileged role के लिए policy को सुरक्षा जरूरत के आधार पर साफ अंतर करना चाहिए।

सामान्य user account managed device पर Endpoint Protection और Conditional Access के साथ synced Passkey इस्तेमाल कर सकता है। Sensitive business account के लिए managed platform authenticator या मजबूत device binding वाला सीमित Sync environment उचित है। Admin, Break-Glass और दूसरे high-value account को अलग device-bound FIDO2 Hardware Key, सख्त recovery और बिना uncontrolled Cloud Sync के चलना चाहिए।

इसके अलावा संगठनों को चाहिए:

• Chrome और Windows update रखें,
• CVE-2026-34348 के विरुद्ध Windows security status जाँचें,
• Enterprise Policy से built-in Browser Manager में Passkey storage जानबूझकर allow या restrict करें,
• Allowlist से Browser Extension control और privileged WebAuthn Proxy function monitor करें,
• user process पर भी EDR और Application Control लागू करें,
• Browser Sync Database access और Chrome Process Memory Dump monitor करें,
• passkey_enclave_state delete होने या अचानक फिर बनने की जाँच करें,
• बार-बार या अचानक आए Google Password Manager Recovery PIN request को warning signal मानें,
• device loss और Account Recovery की प्रक्रिया को misuse के विरुद्ध test करें,
• privileged account से phishable fallback हटाएँ या Authentication Strength Policy से रोकें,
• अचानक Passkey prompt, नई Credential Registration और असामान्य process से WebAuthn use की जाँच करें,
• अहम service में synced और device-bound credential का inventory रखें।

संगठनात्मक मुख्य बात यह है: Endpoint Detection, Passkey project से अलग budget item नहीं है। Authenticator अगर browser और client पर रहता है तो Endpoint Security सीधे authentication model का हिस्सा है।

User को अब क्या करना चाहिए

सावधानी के नाम पर सभी Passkey हटाकर कमजोर password पर लौटने का कोई तथ्यात्मक कारण नहीं है।

उपयोगी कदम हैं:

• Chrome और Windows जल्दी update करें,
• केवल trusted software और Browser Extension install करें,
• Device Protection, Windows Hello और Malware Protection चालू रखें,
• अचानक आए Passkey या Windows Hello dialog को confirm न करें,
• अचानक आए Recovery PIN या Re-Onboarding request को अनदेखी में स्वीकार न करें,
• Google Password Manager और जरूरी service में registered device तथा Passkey जाँचें,
• बहुत मूल्यवान account के लिए अलग Hardware Security Key पर विचार करें,
• संदिग्ध endpoint को इस्तेमाल करते न रहें, उसे isolate कराकर जाँचें।

Malware, बदली Chrome state या memory dump का ठोस संकेत हो तो संभावित credential और session theft मानना चाहिए। तब केवल password बदलना पर्याप्त नहीं। Endpoint rebuild या भरोसेमंद cleanup, active session revoke, recovery method जाँच, unknown Passkey हटाना और trusted authenticator फिर register करना जरूरी है।

संभावित Golden Pass-ta-key incident में विशेष सावधानी चाहिए। प्रकाशित शोध user के लिए आसान SDS rotation नहीं बताता। इसलिए यह दावा न करें कि PIN बदलने या एक Passkey फिर बनाने से समस्या निश्चित रूप से हल होगी। मूल्यवान account के लिए Endpoint cleanup के बाद मैं नए device-bound credential register करता, पुराने synced credential हटाता और recovery में provider या Incident Response Team को शामिल करता।

असली सबक

Passkey हर compromise के खिलाफ ढाल नहीं है। वह एक खास, बहुत बड़ी समस्या हल करता है: लोगों को server या संभवतः fake website को reusable secret नहीं देना पड़ता।

Pass-ta-key अगला स्तर दिखाता है। Private key आसानी से कई device पर sync होने लगे तो key encryption, device trust और recovery की infrastructure बनती है। मूल WebAuthn protocol सही होने पर भी उसमें flaw हो सकते हैं।

Passkey को विफल कहना गलत प्रतिक्रिया होगी। Local malware infection के बाद हर हमले को साधारण कहना भी उतना ही गलत है।

मेरा आकलन साफ है: Passkey rollout जारी रखें, लेकिन security promise सटीक रखें। Synced Passkey phishing के विरुद्ध उत्कृष्ट हैं। High-value account के लिए device-bound Hardware Key मजबूत सीमा देते हैं। और कोई authenticator साफ endpoint, नियंत्रित recovery process तथा सही server-side validation की जगह नहीं लेता।

Passkey ने phishing के खिलाफ दरवाजा काफी बेहतर बंद किया है। Pass-ta-key याद दिलाता है कि हमलावर पहले ही घर में हो तो अलग रक्षा चाहिए।

अगली बार तक,
आपका जो

अक्सर पूछे जाने वाले प्रश्न