Pass-ta-key हमला: Windows पर Google Password Manager के Passkeys का खतरा

महत्वपूर्ण बात यह है कि ये हमले WebAuthn या FIDO2 की मूल public-key cryptography को crack नहीं करते। इसके बजाय वे Chrome के cloud authenticator, डिवाइस की पहचान पर भरोसे, नए डिवाइस को onboard करने की प्रक्रिया और user verification के implementation में मौजूद खामियों का फायदा उठाते हैं ।

तीनों Pass-ta-key तकनीकें कैसे काम करती हैं

1. Pass-ta-key: user verification की जांच न करने वाली साइटों पर हमला

इस basic technique में मालवेयर Chrome की स्थानीय passkey_enclave_state फाइल से TPM-wrapped device identity key निकालता है। इसके बाद वह Windows की वैध CNG APIs के जरिए attacker-controlled requests पर हस्ताक्षर कराता है। परिणामस्वरूप एक वैध WebAuthn assertion तैयार हो सकता है—वह भी बिना fingerprint, PIN या स्क्रीन पर किसी prompt के ।

हालांकि यह तरीका उन relying parties यानी वेबसाइटों पर निर्भर करता है, जो authenticator data में मौजूद User Verified (UV) flag को server-side validate नहीं करतीं ।

यह किस कमजोरी का फायदा उठाता है?

• cloud authenticator का स्थानीय रूप से रखी device identity key पर भरोसा;
• कुछ वेबसाइटों द्वारा user verification की पुष्टि न करना।

2. Silver Pass-ta-key: re-onboarding के दौरान attacker की key दर्ज करना

Silver Pass-ta-key स्थानीय passkey_enclave_state फाइल को मिटाकर या अमान्य करके Chrome को डिवाइस को दोबारा onboard करने के लिए मजबूर करता है। इस re-onboarding प्रक्रिया के दौरान user-verification key कुछ समय के लिए deferred flow में बनती है। शोधकर्ताओं के अनुसार, इसी अंतराल में हमलावर अपनी UV key register कर सकता है ।

Google का cloud authenticator नई key की attestation को validate नहीं करता। इसलिए हमलावर की key से बनाए गए assertions में UV flag 1 सेट हो सकता है और वे उन वेबसाइटों पर भी स्वीकार किए जा सकते हैं, जो user verification लागू करती हैं ।

इसका असर अधिक गंभीर है: हमलावर अपने कंप्यूटर से लंबे समय तक दोबारा इस्तेमाल किया जा सकने वाला access हासिल कर सकता है। इसके बाद पीड़ित का Windows डिवाइस online रहना जरूरी नहीं होता ।

यह किस कमजोरी का फायदा उठाता है?

• डिवाइस re-onboarding के दौरान attestation validation का अभाव;
• enclave state फाइल को बिना पर्याप्त सुरक्षा के हटाया जा सकना।

3. Golden Pass-ta-key: सभी synced passkeys की master key तक पहुंच

Golden Pass-ta-key उसी re-onboarding flow को trigger करता है, लेकिन इसके बाद Chrome की process memory को dump करके Security Domain Secret (SDS) हासिल करने की कोशिश करता है। SDS 32-byte की symmetric key है, जो Google खाते में synced सभी passkeys को encrypt करती है ।

यदि SDS चोरी हो जाए, तो हमलावर मौजूदा और भविष्य में sync होने वाली passkey private keys को decrypt कर सकता है। इससे उन सभी सेवाओं पर व्यापक account takeover का खतरा पैदा हो जाता है, जो इन passkeys से सुरक्षित हैं ।

Unit 42 के खुलासे से पहले Chrome के chrome://device-log/FIDO output में SDS plaintext के रूप में log होने की बात सामने आई थी। Google ने इस logging को हटा दिया है, लेकिन Chrome की process memory में SDS के exposed होने की समस्या रिपोर्ट के अनुसार बनी हुई है ।

यह किस कमजोरी का फायदा उठाता है?

• onboarding flow के दौरान Chrome की process memory में SDS का plaintext रूप में मौजूद होना।

कौन-सी वेबसाइटें प्रभावित हो सकती हैं?

Basic Pass-ta-key उन सभी relying parties के खिलाफ काम कर सकता है, जो returned UV bit की जांच नहीं करतीं। Unit 42 ने eBay को ऐसे उदाहरण के रूप में पहचाना था; eBay ने बाद में यह समस्या ठीक कर दी ।

शोधकर्ताओं ने यह भी कहा कि “आश्चर्यजनक रूप से बड़ी संख्या” में वेबसाइटें registration के समय userVerification: "required" मांगती हैं, लेकिन authentication के दौरान लौटने वाले UV bit को verify नहीं करतीं ।

SDS चोरी होने पर क्या जोखिम है?

SDS को उपयोगकर्ता के Google खाते में synced passkeys की master key समझा जा सकता है। इसके चोरी होने पर:

• मौजूदा synced passkey private keys decrypt की जा सकती हैं और बाद में sync होने वाली नई keys भी पढ़ी जा सकती हैं ;
• हमलावर पीड़ित की किसी अतिरिक्त कार्रवाई के बिना Gmail समेत passkey-सुरक्षित खातों में sign in कर सकता है ;
• Gmail तक पहुंच मिलने पर दूसरे खातों के password reset किए जा सकते हैं, इसलिए नुकसान सीधे प्रभावित सेवाओं से कहीं आगे तक फैल सकता है ;
• SDS को rotate करने के लिए Google की ओर से कोई built-in तरीका उपलब्ध नहीं है—यूज़र नई SDS key generate नहीं कर सकते ।

यूज़र्स और वेबसाइटों के लिए बचाव के उपाय

Unit 42 की findings के आधार पर प्रमुख mitigations ये हैं:

• Synced passkey के साथ कम-से-कम एक hardware security key भी register करें, जैसे YubiKey। Device-bound credentials cloud के साथ sync नहीं होते, Chrome के enclave state में नहीं जाते और memory से पढ़े नहीं जा सकते ।
• High-risk यूज़र्स Google Advanced Protection Program चालू करें। पत्रकारों, executives, activists और administrators जैसे यूज़र्स के लिए यह security keys या device-bound passkeys को अनिवार्य करता है और account recovery को अधिक सुरक्षित बनाता है ।
• Google खाते की device list हर महीने जांचें और अनजान sessions या devices को हटा दें ।
• Infostealer संक्रमण को full credential reset event मानें। खाते सुरक्षित करने के बाद कंप्यूटर को clean system से rebuild करें और सभी passkeys किसी सुरक्षित, साफ डिवाइस से दोबारा register करें ।
• वेबसाइटों को server-side UV flag validate करना चाहिए। संवेदनशील कार्रवाइयों के लिए userVerification को "preferred" के बजाय "required" सेट करना पर्याप्त नहीं है; लौटे हुए UV bit की जांच भी जरूरी है ।

मौजूदा स्थिति

3 अगस्त 2026 को रिपोर्ट प्रकाशित होने के समय इन हमलों के लिए कोई CVE assigned नहीं था। Google ने सार्वजनिक रूप से यह पुष्टि भी नहीं की थी कि Silver या Golden attack paths को सीधे ठीक किया जाएगा या नहीं ।

सबसे बड़ा takeaway यह है कि passkeys की सुरक्षा केवल cryptography पर निर्भर नहीं करती। यदि endpoint यानी Windows PC पहले ही मालवेयर से संक्रमित है, तो डिवाइस-ट्रस्ट और key-management workflows भी हमले का रास्ता बन सकते हैं ।