Pass-ta-key: Google Passkey আক্রমণের প্রকৃত অর্থ

তাহলে কি Passkey-ও এখন অনিরাপদ? Pass-ta-key ঠিক এই প্রশ্নটিই সামনে এনেছে।

Palo Alto Networks Unit 42 এমন তিনটি আক্রমণধারা বর্ণনা করেছে, যেগুলোর মাধ্যমে malware Google-এ sync করা Passkey অপব্যবহার করতে, User Verification এড়িয়ে যেতে এবং সবচেয়ে গুরুতর পরিস্থিতিতে একটি অ্যাকাউন্টের সব 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 এখনো খারাপ বিকল্প: Password phishing করা, পুনর্ব্যবহার করা, অনুমান করা এবং server database থেকে চুরি করা যায়।

তাই আমার ঝুঁকি মূল্যায়ন “কিছুই হয়নি” নয়, বরং: প্রযুক্তিগত পরিধি সংকীর্ণ এবং পূর্বশর্ত কঠিন, কিন্তু সফল হলে সম্ভাব্য প্রভাব অত্যন্ত বেশি।

প্রযুক্তিগত পরিধি ও প্রমাণ

৩১ আগস্ট ২০২৬ পর্যন্ত প্রমাণিত অবস্থার মধ্যে রয়েছে 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-এর প্রযুক্তিগত পর্যবেক্ষণও প্রাসঙ্গিক।

গবেষণাটি ৩ আগস্ট প্রকাশিত হয় এবং Unit 42 এটি ১৪ আগস্ট হালনাগাদ করে। এটি স্পষ্টভাবে TPM-যুক্ত Windows device-এ Chrome-এর Google Password Manager নিয়ে করা হয়েছে। অন্য browser, operating system এবং Passkey provider-এ একই ধরনের স্থাপত্যগত প্রশ্ন থাকতে পারে, কিন্তু এই তিনটি আক্রমণ দিয়ে সেগুলো প্রমাণিত হয়নি।

এই নির্দিষ্ট কৌশলগুলোর সক্রিয় ব্যবহার বাস্তব কোনো attack campaign-এ নথিভুক্ত হয়নি। বর্তমান প্রমাণ গবেষণা, Proof of Concept এবং Responsible Disclosure-এর ওপর ভিত্তি করে। ঝুঁকি মূল্যায়নে এটি গুরুত্বপূর্ণ: প্রযুক্তিগতভাবে দেখানো হয়েছে মানেই ব্যাপকভাবে ব্যবহার হচ্ছে, এমন নয়।

Passkey আসলে কী সুরক্ষিত করে

Passkey খুব দীর্ঘ কোনো password নয়। এটি asymmetric cryptography-ভিত্তিক একটি WebAuthn credential।

নিবন্ধনের সময় 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 একটি নতুন, এলোমেলো challenge পাঠায়। Authenticator এমন data sign করে, যার মধ্যে এই challenge এবং আহ্বানকারী website-এর context বাঁধা থাকে। Server সংরক্ষিত public key দিয়ে signature যাচাই করে।

অর্থাৎ password-এর মতো private key server-এ পাঠানো হয় না। আদর্শ পরিস্থিতিতে service-এর data leak থেকে আক্রমণকারী শুধু public key পায়। তা দিয়ে বৈধ signature তৈরি করা সম্ভব নয়।

Relying Party ID ও Web Origin-এর সঙ্গে binding-টিও গুরুত্বপূর্ণ। example.com-এর Passkey দেখতে প্রায় একই কোনো phishing domain-এ example.com-এর জন্য বৈধ assertion তৈরি করে না। ভুল website-এ type করা বা ফোনে আক্রমণকারীকে পড়ে শোনানোর মতো কোনো secret ব্যবহারকারীর কাছে থাকে না।

এটাই phishing-resistant হওয়ার অর্থ। NIST শব্দটিকে নির্দিষ্টভাবে সংজ্ঞায়িত করে: প্রতারণামূলক verifier যেন authentication secret বা আসল service-এ ব্যবহারযোগ্য authentication response, কোনোটিই না পায়। Verifier-এর নামের সঙ্গে cryptographic binding-এর মাধ্যমে WebAuthn এটি নিশ্চিত করে।

Pass-ta-key-এর ক্ষেত্রেও এই বৈশিষ্ট্য অক্ষত থাকে। Malware আরও ভালো phishing site তৈরি করে না। এটি ইতিমধ্যেই সেই device-এ চলছে, যেটিকে ব্যবহারকারী trusted authenticator হিসেবে ব্যবহার করেন।

User Presence ও User Verification এক বিষয় নয়

তিনটি আক্রমণ বুঝতে দুটি WebAuthn signal আলাদা করতে হবে:

• User Presence, UP: ব্যবহারকারী উপস্থিতির কোনো action করেছেন, যেমন Security Key স্পর্শ করা বা dialog নিশ্চিত করা।
• User Verification, UV: Authenticator স্থানীয়ভাবে ব্যবহারকারীকে যাচাই করেছে, যেমন Windows Hello, PIN বা biometrics দিয়ে।

WebAuthn assertion-এর authenticatorData-তে এই ফলগুলো flag হিসেবে থাকে। Login শুরু করার সময় server যা চেয়েছিল, শুধু তার ওপর বিশ্বাস করলে চলবে না। Server যদি userVerification: "required" চায়, response-এ UV flag সত্যিই set হয়েছে কি না, সেটিও পরীক্ষা করতে হবে।

এই একটি check গুরুত্বপূর্ণ। প্রয়োজনীয় User Verification না থাকায় Unit 42 সাধারণ Pass-ta-key আক্রমণটি GitHub-এর বিরুদ্ধে সফলভাবে শেষ করতে পারেনি। eBay-তে User Verification চাওয়া হলেও প্রথমে login সফল হয়েছিল। Report পাওয়ার পর eBay server-side validation ঠিক করে।

পার্থক্যটি দেখায়, cryptographically সঠিক signature সব সময় সঠিকভাবে implement করা multi-factor authentication-এর জন্য যথেষ্ট নয়। Authenticator প্রকৃতপক্ষে কোন security condition নিশ্চিত করেছে, Relying Party-কে সেটিও যাচাই করতে হবে।

কেন synced Passkey নতুন একটি trust boundary তৈরি করে

Device-bound Passkey নির্দিষ্ট authenticator-এ থাকে, যেমন hardware Security Key বা স্থানীয়ভাবে সুরক্ষিত platform authenticator। বিপরীতে synced Passkey একাধিক device-এ পাওয়া যাওয়ার জন্য তৈরি। তাই এর private key material encrypted অবস্থায় backup নিতে, sync infrastructure দিয়ে পাঠাতে এবং অন্য অনুমোদিত device-এ restore করতে হয়।

এটি implementation-এর ছোট কোনো পার্থক্য নয়। Synchronization পুরো system-কে বিস্তৃত করে:

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

প্রতিটি অতিরিক্ত স্তরের জন্য device trust, onboarding, recovery, key encryption এবং revocation-এর নিজস্ব নিয়ম দরকার।

এই কারণে NIST sync করা যায় এমন authenticator-কে আলাদা category হিসেবে বিবেচনা করে। এগুলো Authentication Assurance Level 2 পর্যন্ত ব্যবহারের উপযুক্ত হতে পারে। AAL3-এর জন্য NIST hardware-protected environment বা আলাদা authenticator-এ non-exportable key চায়। এর অর্থ synced Passkey দুর্বল নয়। এর অর্থ convenience ও key portability একটি ভিন্ন assurance model তৈরি করে।

Pass-ta-key ঠিক এই বাড়তি trust boundary-তেই আঘাত করে।

গবেষণার নির্দিষ্ট পরিধি

Unit 42 এমন কয়েকটি পূর্বশর্ত উল্লেখ করেছে, যা বহু headline-এ যথেষ্ট গুরুত্ব পায়নি:

• আক্রান্ত synced Passkey Google Password Manager পরিচালনা করে।
• Chrome Windows-এ চলছে।
• Device-টিতে TPM রয়েছে।
• Malware ইতিমধ্যেই ভুক্তভোগীর user context-এ চলছে।
• ব্যবহারকারী প্রাসঙ্গিক Chrome ও Google environment-এ setup করা।
• কিছু variant-এর জন্য malware-কে স্থানীয় Chrome data পড়তে, state file পরিবর্তন করতে বা Chrome process memory পরীক্ষা করতে হয়।

প্রতিটি Passkey-এর বিরুদ্ধে কার্যকর universal attack দেখানো হয়নি। আগাম endpoint compromise ছাড়াই দূরের আক্রমণকারী সহজে TPM থেকে WebAuthn key টেনে নিতে পারে, এমনও দেখানো হয়নি।

তাই “Passkey crack হয়ে গেছে” বলা ভুল হবে। নির্ভুল ভাষায়: Unit 42 compromised Windows endpoint-এ synced Google Passkey-এর trust, onboarding এবং recovery mechanism-এর বিরুদ্ধে তিনটি attack chain দেখিয়েছে।

Phase zero: স্থানীয় Passkey মানচিত্র

তিনটি variant-এর যেকোনোটি শুরুর আগে malware স্থানীয় Chrome sync database পড়ে বলে Unit 42 জানিয়েছে। সেখানে WebauthnCredentialSpecifics record থাকে। এগুলোতে Relying Party information, username, Credential ID এবং encrypted private key material-সহ বিভিন্ন তথ্য থাকে।

গবেষণায় দেওয়া path হলো:

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

পরীক্ষায় এই record পড়তে elevated privilege প্রয়োজন হয়নি। Private key material সরাসরি plaintext-এ না থাকলেও metadata malware-কে target list দেয়: কোন service-এর Passkey আছে, সেগুলো কোন account-এর এবং কোন Credential ID ব্যবহার করতে হবে?

Detection-এর দৃষ্টিতেও এটি গুরুত্বপূর্ণ। Infostealer-কে আর target অনুমান করতে হয় না। প্রথমে inventory করে পরে বেছে বেছে উচ্চমূল্যের account আক্রমণ করতে পারে।

Pass-ta-key: ব্যবহারকারীর action ছাড়াই বৈধ assertion

প্রথম variant সেই device key অপব্যবহার করে, যার মাধ্যমে Chrome Google Cloud Authenticator-এর কাছে Windows device-এর পরিচয় প্রমাণ করে।

এ জন্য Chrome একটি TPM-backed Identity Key তৈরি করে। Unit 42 বলেছে, Chrome private key-টি সাধারণ plaintext key হিসেবে সংরক্ষণ করে না। এর বদলে Windows CNG দিয়ে NCRYPT_OPAQUE_KEY_BLOB হিসেবে export করে। TPM blob-টিকে এমনভাবে সুরক্ষিত রাখে, যাতে একই physical TPM-এ cryptographic operation-এর জন্য আবার import করা যায়।

Cryptography-এর দিক থেকে এটি যৌক্তিক, কিন্তু authorization problem নিজে থেকে সমাধান করে না। গবেষণা অনুযায়ী, সাধারণ user context-এর malware সংরক্ষিত wrapped_identity_private_key পড়তে বা Chrome memory থেকে বের করতে এবং প্রচলিত Windows CNG function call করতে পেরেছে। Request প্রযুক্তিগতভাবে সঠিক device থেকে আসায় TPM signature তৈরি করে। API call-টি Chrome করেছে নাকি 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 নয়। যে service User Verification বাধ্যতামূলক করে এবং ফল যাচাই করে, সঠিকভাবে implement করা সেই service-কে UV = 0 assertion প্রত্যাখ্যান করতে হবে।

এ কারণে variant-টি নিরীহ নয়। Compatibility বা UX-এর কারণে অনেক service শুধু preferred হিসেবে User Verification configure করে। অন্যরা এটি চাইলেও response ভুলভাবে পরীক্ষা করে। এমন ক্ষেত্রে multi-factor হিসেবে পরিকল্পিত login বাস্তবে একটিমাত্র factor-এ নেমে আসে: device identity-তে access।

Silver Pass-ta-key: আক্রমণকারী নিজের UV identity নিবন্ধন করে

Silver Pass-ta-key এই সীমা এড়িয়ে যায়। আক্রমণকারী Windows Hello বা ভুক্তভোগীর biometrics ভাঙার চেষ্টা করে না। সে Cloud Authenticator-কে এমনভাবে প্রভাবিত করে, যাতে ভবিষ্যতে নিজের key-কে User Verification-এর বৈধ প্রমাণ হিসেবে গ্রহণ করা হয়।

শুরুটি Re-Onboarding process-এ। গবেষণা অনুযায়ী malware Cloud Authenticator-কে আগের device state ভুলিয়ে দিতে পারে অথবা স্থানীয় passkey_enclave_state file মুছে দিতে পারে। পরবর্তী Passkey operation-এ Chrome-কে device-টি নতুন করে register করতে হয়।

Windows-এ প্রথম ধাপেই User Verification Key তৈরি হওয়া বাধ্যতামূলক নয়। Chrome শুরুতে Google Password Manager Recovery PIN ব্যবহার করে uv_key_pending state set করতে পারে। আসল UV Key পরের Passkey ব্যবহারের সময় আসে। User experience সহজ করার জন্য তৈরি এই মধ্যবর্তী state-ই একটি সময়সীমা খুলে দেয়।

প্রস্তুতির জন্য ভুক্তভোগীকে অপ্রত্যাশিতভাবে শুরু হওয়া recovery বা Re-Onboarding ধাপটি সম্পন্ন করে GPM PIN দিতে হয়। Malware-কে PIN চুরি করতে হয় না। এরপর তৈরি হওয়া uv_key_pending state-টি ব্যবহার করে। পরবর্তী অপব্যবহারমূলক login আর কোনো interaction ছাড়াই এবং ভুক্তভোগীর device online না থাকলেও করা যায়।

আক্রমণকারী নিজের environment-এ key pair তৈরি করে public key-টি নতুন UV Key হিসেবে পাঠায়। Unit 42-এর ফল অনুযায়ী, Google Cloud Authenticator তখন নতুন key-টি সত্যিই trusted hardware থেকে এসেছে কি না যাচাই করেনি। System বৈধ device identity-এর পাশে আক্রমণকারীর key-টিও সংরক্ষণ করেছে।

এরপর আক্রমণকারী নিজের private key দিয়ে request sign করতে পারে। Cloud Authenticator এটিকে স্থানীয়ভাবে সম্পন্ন User Verification হিসেবে দেখে এবং UV flag set করা assertion তৈরি করে। পরবর্তী login-এর সময় ভুক্তভোগীর PC online থাকতে হয় না।

প্রকাশ্য Chromium issue-তে আচরণটি “GPM Passkeys Are Vulnerable to User Verification Key Abuse” নামে বর্ণিত। আমার যাচাইয়ের সময় এটি WAI হিসেবে চিহ্নিত ছিল। Internal assessment যাই হোক, ঘটনাটি একটি গুরুত্বপূর্ণ architecture rule দেখায়: নতুন trusted key bind করা recovery বা onboarding process নিজেই অত্যন্ত critical authentication event।

Golden Pass-ta-key: Cloud Sync থেকে export করা যায় এমন key material

Golden Pass-ta-key সবচেয়ে গুরুতর variant। এর লক্ষ্য Security Domain Secret, সংক্ষেপে SDS। ৩২ byte দীর্ঘ এই secret Google Password Manager account-এর synced private Passkey key সুরক্ষিত রাখে।

সহজ ভাষায় architecture-এর প্রতিশ্রুতি হলো: Client-এর কাছে শুধু encrypted wrapped_secret থাকে। Device-specific key দিয়ে Cloud Authenticator-এর ভেতরে decryption হয়। ফলে client-এ malware থাকলেও সহজে private Passkey key পাওয়ার কথা নয়।

Onboarding ও recovery-এর সময় Sync infrastructure-কে আবার Security Domain-এ device যুক্ত করতে হয়। Unit 42 দেখেছে, এই প্রক্রিয়ায় Chrome client-এর accessযোগ্য রূপে 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 বাধ্যতামূলকভাবে শুরু করে এবং Chrome process-এ SDS থাকার সঠিক মুহূর্তটি ধরতে হয়। এতে আক্রমণটি কঠিন হয়, কিন্তু সফল extraction-এর পর চুরি হওয়া secret-এর পরিধি কমে না।

Attack chain-টি তাই কয়েকটি ধাপ একত্র করে:

1. Malware নতুন onboarding বাধ্যতামূলক করে।
2. এটি স্থানীয় Enclave state নতুন করে তৈরি বা পরিবর্তনের অপেক্ষা করে।
3. সঠিক সময়ে Chrome process memory পড়ে SDS খোঁজে।
4. আগে পড়া Sync record-এর সঙ্গে SDS যুক্ত করে।
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 কখনো architecture বদলাতে পারবে না, এটি তার প্রমাণ নয়।

স্থানীয় malware থাকলেও আক্রমণটি কেন তুচ্ছ নয়

Logged-in PC-র user context-এ ইচ্ছামতো malware চালাতে পারা আক্রমণকারীর হাতে আরও অনেক সহজ উপায় থাকে। সে Session Cookie চুরি, browser content পড়া, transaction পরিবর্তন, file exfiltrate করা বা active account-এ সরাসরি ব্যবহারকারীর হয়ে কাজ করতে পারে। সম্পূর্ণ compromised client-কে কোনো authentication method-ই নিঃশর্তে বিশ্বাস করতে পারে না।

মূল attack class-টিও নতুন নয়। Compromised Password Manager ও browser থেকে secret বা active session নেওয়া বহু বছর ধরে Infostealer-এর toolkit-এর অংশ। আগে থেকে থাকা endpoint compromise-কে Pass-ta-key কোনো জাদুকরী remote attack-এ পরিণত করে না।

তবু আক্রমণটিকে গুরুত্বহীন বলা যথেষ্ট নয়। গবেষণাটি নির্দিষ্ট implementation-সংক্রান্ত এমন কিছু তথ্য দেয়, যা আগে স্বতঃসিদ্ধ ছিল না:

• Unprivileged process signature তৈরিতে TPM-bound Chrome device key ব্যবহার করতে পেরেছে।
• Device possession ও User Verification-এর সীমা Relying Party-এর সঠিক UV flag evaluation-এর ওপর নির্ভর করেছে।
• Re-Onboarding state আক্রমণকারী-নিয়ন্ত্রিত UV Key register করতে দিয়েছে।
• Central Sync secret প্রথমে log-এ দেখা গেছে এবং পরে গবেষণা অনুযায়ী process memory-তে accessযোগ্য থেকেছে।
• সবচেয়ে গুরুতর path synced private key-কে মূল device-এর বাইরে পুনর্ব্যবহারযোগ্য করেছে।
• একাধিক বৈধ device একই credential ব্যবহার করায় synced Passkey-এর জন্য classical signature counter প্রায়ই নির্ভরযোগ্য cloning signal নয়।

“Endpoint compromised” একটি পূর্বশর্ত, ক্ষতির পূর্ণ বিবরণ নয়। Incident Response-এ আক্রমণকারী সাময়িক session চুরি করেছে, নাকি বহু service-এর জন্য দীর্ঘমেয়াদে ব্যবহারযোগ্য private key material পেয়েছে, তার মধ্যে বড় পার্থক্য আছে।

নতুন attack surface-এর একটি অংশ মাত্র Pass-ta-key

Pass-ta-key বিচ্ছিন্নভাবে আসেনি। ২০২৫ ও ২০২৬ সালের গবেষণা এমন কয়েকটি পথ দেখায়, যেগুলোতে আক্রমণকারী 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 এবং সেখান থেকে তৈরি ২০টিরও বেশি attack technique শনাক্ত করে। সবচেয়ে গুরুত্বপূর্ণ chain-টি অপ্রত্যাশিত জায়গা থেকে শুরু হয়েছিল: Windows Microsoft-Windows-WebAuthN/Operational Event Log-এ সম্পূর্ণ WebAuthn assertion লিখত।

এ ধরনের 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 এমন 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, স্বল্পমেয়াদি, একবার ব্যবহারযোগ্য এবং নির্দিষ্ট login session-এর সঙ্গে বাঁধা হতে হবে। শুধু বৈধ signature পুরো login flow সঠিক ছিল তা প্রমাণ করে না।

আরেকটি attack technique Windows WebAuthn API-এর Parent Window Handle নিয়ে। Local process আসল Passkey dialog এমনভাবে দেখাতে পারে, যেন এটি browser বা mail client-এর মতো trusted program-এর অংশ। এখানেও system UI আসল, কিন্তু যে context এটি চালু করেছে তা বিভ্রান্তিকর হতে পারে। তাই অপ্রত্যাশিত Passkey ও Windows Hello request-কে ব্যবহারকারীদের অপ্রত্যাশিত MFA push notification-এর মতোই বিবেচনা করা উচিত।

সবচেয়ে দুর্বল fallback-ই প্রকৃত security level নির্ধারণ করে

Proofpoint ২০২৫ সালে 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 এড়িয়ে যায় না। এটি নিশ্চিত করে, WebAuthn ceremony যেন শুরুই না হয়। Account-এ Passkey-এর পাশাপাশি দুর্বল method অনুমোদিত থাকলেই শুধু এটি কাজ করে। বাস্তব আক্রমণে এই downgrade ব্যবহারের প্রমাণ নথিভুক্ত হয়নি।

প্রতিষ্ঠানগুলোর জন্য এখান থেকে অস্বস্তিকর কিন্তু স্পষ্ট নিয়ম পাওয়া যায়: একটি Passkey register করলেই policy phishing-resistant হয় না। নির্দিষ্ট সুরক্ষা প্রয়োজনের জন্য login আর phishable fallback গ্রহণ না করলেই তা phishing-resistant। 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 ঢোকাতে পারলে ব্যবহারকারী আসল biometric dialog দেখতে পারেন, আর background-এ আক্রমণকারীর নিয়ন্ত্রণে 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 browser থেকে session artifact চুরি করলে এবং server অন্য device থেকে পুনর্ব্যবহার মেনে নিলে আক্রমণকারীর password বা Passkey কোনোটিই লাগে না। সে আগে থেকেই authenticated session আক্রমণ করে।

বর্ণিত অনেক গবেষণামূলক Proof of Concept-এর তুলনায় এটি বর্তমানে বেশি ব্যবহারিক attack path। Passkey login-এর আগে ও সময়ে attack surface অনেক কমায়। কিন্তু secure Token storage, ঝুঁকি অনুযায়ী স্বল্প session lifetime, critical action-এর জন্য Re-Authentication, Token Revocation এবং সম্ভব হলে উচ্চমূল্যের session-এর device-এর সঙ্গে cryptographic binding-এর বিকল্প নয়।

তাই session theft-এর ক্ষেত্রে “MFA bypass হয়েছে” বলা প্রায়ই বিভ্রান্তিকর। MFA সফলভাবে সম্পন্ন হয়েছিল। পরে তার ফলটি চুরি হয়েছে।

PoisonSeed দেখায়, গবেষণা কত দ্রুত hype-এ পরিণত হয়

Expel জুলাই ২০২৫-এ প্রথমে Passkey-এর Cross-Device Authentication-এর বিরুদ্ধে একটি কথিত আক্রমণের কথা জানায়। আক্রমণকারী একটি বৈধ QR code phishing page-এর মাধ্যমে ভুক্তভোগীর কাছে পাঠিয়ে দূর থেকে login দখল করতে পারবে বলে দাবি করা হয়েছিল। কয়েক দিন পরে Expel মূল দাবিটি প্রকাশ্যে প্রত্যাহার করে ক্ষমা চায়।

পরবর্তী বিশ্লেষণে দেখা যায়, Cross-Device Authentication-এর জন্য পরিকল্পিত local proximity check সফলভাবে অতিক্রম করা হয়নি। প্রয়োজনীয় নৈকট্য ছাড়া flow timeout হয়েছে, সব 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 ভাঙা হয়নি।

সাধারণ ব্যবহারকারীর জন্য 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 করা, স্বল্প সময়ের জন্য বৈধ রাখা, একবার গ্রহণ করা এবং নির্দিষ্ট 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 change, geographic change ও নতুন Passkey binding Identity Telemetry-তে যুক্ত করা,
• ঝুঁকিপূর্ণ পরিবর্তনের পর session revoke করা এবং critical action আবার authenticate করা,
• platform ও application নির্ভরযোগ্যভাবে support করলেই device-bound session ব্যবহার করা।

প্রতিষ্ঠিত 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 কমায় এবং 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 হালনাগাদ রাখা,
• CVE-2026-34348-এর বিরুদ্ধে Windows security status পরীক্ষা করা,
• Enterprise Policy দিয়ে built-in Browser Manager-এ Passkey storage সচেতনভাবে অনুমোদন বা সীমিত করা,
• Allowlist দিয়ে Browser Extension নিয়ন্ত্রণ এবং privileged WebAuthn Proxy function monitor করা,
• user process-এও EDR ও Application Control প্রয়োগ করা,
• Browser Sync Database access এবং Chrome Process Memory Dump monitor করা,
• passkey_enclave_state মুছে ফেলা বা অপ্রত্যাশিতভাবে পুনরায় তৈরি হওয়া তদন্ত করা,
• বারবার বা অপ্রত্যাশিত Google Password Manager Recovery PIN request-কে warning signal ধরা,
• device loss ও Account Recovery-এর বর্তমান process অপব্যবহারের বিরুদ্ধে পরীক্ষা করা,
• privileged account থেকে phishable fallback সরানো বা Authentication Strength Policy দিয়ে বাদ দেওয়া,
• অপ্রত্যাশিত Passkey prompt, নতুন Credential Registration এবং অস্বাভাবিক process থেকে WebAuthn ব্যবহার তদন্ত করা,
• কোন গুরুত্বপূর্ণ service synced এবং কোনটি device-bound credential ব্যবহার করে, তার inventory রাখা।

সংগঠনের জন্য মূল বিষয়টি হলো: Endpoint Detection, Passkey project থেকে আলাদা কোনো budget item নয়। Authenticator যদি browser ও client-এ থাকে, Endpoint Security সরাসরি authentication model-এর অংশ।

ব্যবহারকারীদের এখন যা করা উচিত

সতর্কতামূলকভাবে সব Passkey মুছে আবার দুর্বল password ব্যবহারে ফেরার কোনো যৌক্তিক কারণ নেই।

কার্যকর পদক্ষেপ হলো:

• দ্রুত Chrome ও Windows update করা,
• শুধু trusted software ও Browser Extension install করা,
• Device Protection, Windows Hello ও Malware Protection সক্রিয় রাখা,
• অপ্রত্যাশিত Passkey বা Windows Hello dialog নিশ্চিত না করা,
• অপ্রত্যাশিত 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-এ বিশেষ সতর্কতা দরকার। প্রকাশিত গবেষণায় ব্যবহারকারীর জন্য সহজ 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 থেকে অন্য device-এ সহজে sync হলে key encryption, device trust ও recovery-এর একটি infrastructure তৈরি হয়। মূল WebAuthn protocol সঠিক হলেও এই infrastructure-এ 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 মনে করিয়ে দেয়, আক্রমণকারী ইতিমধ্যেই ঘরের ভেতরে থাকলে অন্য ধরনের প্রতিরক্ষা প্রয়োজন।

পরের বার পর্যন্ত,
আপনাদের জো

প্রায়শ জিজ্ঞাসিত প্রশ্ন