পাসকি কেন নিরাপদ — চিত্রে বোঝা «গোপন তথ্য না পাঠানো প্রমাণীকরণ»

«আবার বড় সার্ভিস থেকে পাসওয়ার্ড ফাঁস» খবর আর কাউকে অবাক করে না। ফিশিং প্রশিক্ষণ বছর বছর করলেও ধরা পড়া মানুষ শূন্য হয় না। «পাসওয়ার্ড পুনর্ব্যবহার করবেন না, লম্বা করুন, নিয়মিত বদল… আর করতে হয় না» — বলার কথাও উল্টে গেছে।

গত কয়েক বছরে দ্রুত ছড়ানো পাসকি (passkey) এই অবস্থার উত্তর হিসেবে Apple·Google·Microsoft তিন প্রতিষ্ঠান একসঙ্গে এগিয়ে নিচ্ছে প্রমাণীকরণ পদ্ধতি।¹ «আঙুলের ছাপ বা মুখ দিয়ে লগইন, সুবিধা» বলে পরিচয় বেশি, কিন্তু সার সেখানে নয়। পাসকির আসল মূল্য নিরাপত্তার ভিত্তি «মানুষের মনোযোগ» থেকে «প্রোটোকলের কাঠামো»তে সরিয়ে দেওয়া।

• পাসওয়ার্ড ফাঁস হয় ব্যবহারকারীর অসাবধানতায়, তাই শিক্ষা দিন → মানুষ অবশ্যই ভুল করে
• নকল সাইট চিনতে প্রশিক্ষণ দিন → চেনা যায় না এমন নকল সাইট বানানো যায়
• পাসকি হলে → পাঠানোর গোপন তথ্যই নেই, নকল সাইটে স্বাক্ষর দাঁড়ায় না

এই নিবন্ধ পাসকি কেন নিরাপদ তা পাসওয়ার্ডে কী ভেঙেছে সেখান থেকে চিত্রে ধরে। তারপর «সিঙ্ক হওয়া পাসকি সত্যি নিরাপদ?» «দুর্বলতা নেই?» — স্বাভাবিক প্রশ্নের মুখোমুখি উত্তর দিয়ে শেষে Web অ্যাপ ও Windows পরিবেশে বসানোর বাস্তব মূল কথা সাজায়।

1. আগে উপসংহার

পাসকি নিরাপদ হওয়ার কারণ তিনটায় জমা হয়।

1. সার্ভারে গোপন তথ্য নেই। সার্ভার যা রাখে পাবলিক কী মাত্র, ফাঁস হলেও অপব্যবহার যায় না। ডেটাবেস পুরো ফাঁস হলেও আক্রমণকারী নিয়ে যাওয়ার «অন্যের পরিচয় নেওয়ার উপাদান» পায় না।²
2. গোপন তথ্য নেটওয়ার্কে বয়ে না। লগইনে যা যায় সেই মুহূর্তের র‍্যান্ডম সংখ্যা (চ্যালেঞ্জ)-এর স্বাক্ষর মাত্র। প্রাইভেট কী ডিভাইসের অথেন্টিকেটর থেকে একেবারেই বেরোয় না, পথের যেখানেই আড়ি পাতুন বা রিলে করুন গোপন তথ্য হাতে আসে না।²
3. নকল সাইটে স্বাক্ষর দাঁড়ায় না। পাসকি সাইটের ডোমেইনে বাঁধা, ব্রাউজার ডোমেইন মিল জোর করে। ব্যবহারকারী নকল সাইটে ধোঁকা খেলেও আসল সাইটের পাসকি প্রার্থীতেই আসে না, স্বাক্ষর রিলে করলেও যাচাইয়ে পড়ে।³

এই তিনটা আলাদা কৌশল নয়, «গোপন তথ্য ভাগ করে পাঠানো» প্রমাণীকরণ থেকে «গোপন তথ্য আছে স্বাক্ষরে প্রমাণ করা» প্রমাণীকরণে একটা নকশা বদল থেকেই সব ফল। ক্রমে দেখি।

পরিভাষার সম্পর্ক — পাসকি·WebAuthn·FIDO2·CTAP

এই ক্ষেত্রে পরিভাষা বেশি, নিবন্ধে নিবন্ধে পরিসর আলাদা, তাই আগে সম্পর্ক ধরে রাখি। পাসকি নতুন প্রোটোকল নয়, বিদ্যমান মানের সমন্বয়ে লাগানো «নাম»।²¹

সারণি ১: পাসকি FIDO2 ভিত্তির উপরের নাম, মানের নাম নয়

অর্থাৎ «পাসকি সমর্থন» বাস্তবায়নের ভাষায় «WebAuthn বাস্তবায়ন»। CTAP বাহ্যিক অথেন্টিকেটর ব্যবহার করলে ব্রাউজার ও OS যে স্তর সামলায়, Web অ্যাপ বানানো পাশ সরাসরি ছোঁয় না।

এই নিবন্ধের জ্ঞান মানচিত্র

পাসকি WebAuthn ও CTAP (একসঙ্গে FIDO2) মানের উপর দাঁড়ানো পাবলিক-কী ক্রিপ্টোগ্রাফিভিত্তিক ক্রেডেনশিয়াল; প্রাইভেট কী প্রমাণীকরণ যন্ত্র থেকে বের হয় না, সার্ভারে কেবল ফাঁস হলেও কাজে লাগে না এমন পাবলিক কী রাখা হয়। পাসকি সাইটের ডোমেইনের (RP ID) সঙ্গে বেঁধে তৈরি হয় বলে নকল সাইটে স্বাক্ষর আদৌ দাঁড়ায় না এবং ফিশিং কাঠামোগতভাবে প্রতিরোধ হয়। সিঙ্ক করা পাসকি ক্লাউড অ্যাকাউন্টের উপর নির্ভরতার বিনিময়ে হারানোর সহনশীলতা পায়, অন্যদিকে ডিভাইস-বাঁধা ধরন হার্ডওয়্যারে কী আটকে রাখে। পাসকি চালু করার পর পাশাপাশি থাকা ফলব্যাক উপায় সংকোচন ও অ্যাকাউন্ট পুনরুদ্ধার প্রবাহ শক্তিশালী করাই বাস্তব কাজের কেন্দ্র।

flowchart LR
    accTitle: পাসকি কেন নিরাপদ তার জ্ঞান মানচিত্র
    accDescr: পাসকি যে WebAuthn · FIDO2 · CTAP · পাবলিক-কী ক্রিপ্টোগ্রাফির উপর দাঁড়ায়, RP ID দিয়ে ডোমেইন বাঁধা যে কাঠামোগতভাবে ফিশিং আটকায়, সিঙ্ক করা ও ডিভাইস-বাঁধা ধরনের পার্থক্য ও তাদের একক ব্যর্থতা বিন্দু, ফিশিং-প্রতিরোধী MFA হিসেবে অবস্থান, অবশিষ্ট ঝুঁকি (ফলব্যাক · অ্যাকাউন্ট পুনরুদ্ধার · সেশন চুরি)-এর সম্পর্ক দেখানো চিত্র
    passkey["পাসকি"]
    webauthn["WebAuthn"]
    fido2["FIDO2"]
    public_key_cryptography["পাবলিক-কী ক্রিপ্টোগ্রাফি"]
    ctap["CTAP"]
    authenticator["প্রমাণীকরণ যন্ত্র"]
    tpm["TPM"]
    windows_hello["Windows Hello"]
    fido2_security_key["সিকিউরিটি কী"]
    device_bound_passkey["ডিভাইস-বাঁধা পাসকি"]
    webauthn_secure_context["সিকিউর কনটেক্সটের শর্ত (HTTPS)"]
    webauthn_challenge["চ্যালেঞ্জ (একবারের র্যান্ডম সংখ্যা)"]
    rp_id["RP ID (Relying Party শনাক্তকারী)"]
    phishing["ফিশিং"]
    aitm_phishing["AiTM (মধ্যম ব্যক্তি) ধরনের ফিশিং"]
    credential_database_breach["ক্রেডেনশিয়াল ডেটাবেসের ফাঁস"]
    password_authentication["পাসওয়ার্ড প্রমাণীকরণ"]
    password_reuse["পাসওয়ার্ড পুনর্ব্যবহার (তালিকাভিত্তিক আক্রমণ)"]
    account_takeover["অ্যাকাউন্ট দখল"]
    session_cookie_theft["সেশন কুকি চুরি"]
    totp["ওয়ান-টাইম পাসওয়ার্ড (TOTP)"]
    phishing_resistant_mfa["ফিশিং-প্রতিরোধী MFA"]
    entra_id["Microsoft Entra ID"]
    synced_passkey["সিঙ্ক করা পাসকি"]
    platform_credential_vault["প্ল্যাটফর্মের ক্রেডেনশিয়াল ভল্ট"]
    nist_aal3["NIST AAL3 (প্রমাণীকরণ যন্ত্রের নিশ্চয়তা স্তর 3)"]
    platform_account_hardening["প্ল্যাটফর্ম অ্যাকাউন্টের সুরক্ষা শক্তিশালীকরণ"]
    account_recovery_abuse["অ্যাকাউন্ট পুনরুদ্ধার প্রবাহের অপব্যবহার"]
    account_recovery_hardening["পুনরুদ্ধার প্রবাহে পরিচয় যাচাই শক্তিশালীকরণ"]
    fallback_credential["পাশাপাশি থাকা ফলব্যাক প্রমাণীকরণ উপায়"]
    fallback_retirement["ফলব্যাক উপায়ের পরিকল্পিত সংকোচন"]
    passkey -->|"ব্যবহার করে"| webauthn
    passkey -->|"ব্যবহার করে"| fido2
    passkey -->|"ব্যবহার করে"| public_key_cryptography
    fido2 -->|"ব্যবহার করে"| webauthn
    fido2 -->|"ব্যবহার করে"| ctap
    passkey -->|"ব্যবহার করে"| authenticator
    authenticator -.->|"ব্যবহার করে"| tpm
    windows_hello -.->|"ব্যবহার করে"| tpm
    passkey -.->|"ব্যবহার করে"| windows_hello
    passkey -.->|"ব্যবহার করে"| fido2_security_key
    device_bound_passkey -->|"ব্যবহার করে"| authenticator
    webauthn -->|"পূর্বশর্ত"| webauthn_secure_context
    webauthn -->|"ব্যবহার করে"| webauthn_challenge
    passkey -->|"পূর্বশর্ত"| rp_id
    rp_id -->|"প্রতিরোধ করে"| phishing
    passkey -->|"প্রতিরোধ করে"| phishing
    passkey -->|"প্রতিরোধ করে"| aitm_phishing
    public_key_cryptography -->|"কমায়"| credential_database_breach
    password_authentication -.->|"কারণ হতে পারে"| credential_database_breach
    password_authentication -.->|"কারণ হতে পারে"| phishing
    password_authentication -.->|"কারণ হতে পারে"| password_reuse
    password_reuse -.->|"কারণ হতে পারে"| account_takeover
    aitm_phishing -.->|"কারণ হতে পারে"| session_cookie_theft
    totp -->|"ব্যবহার নিরুৎসাহিত"| phishing_resistant_mfa
    passkey -->|"প্রস্তাবিত সমাধান"| phishing_resistant_mfa
    entra_id -.->|"ব্যবহার করে"| passkey
    passkey -.->|"দিয়ে কনফিগার"| entra_id
    synced_passkey -->|"এ সংরক্ষিত"| platform_credential_vault
    synced_passkey -->|"সামঞ্জস্যহীন"| nist_aal3
    device_bound_passkey -.->|"প্রস্তাবিত সমাধান"| nist_aal3
    platform_credential_vault -.->|"কারণ হতে পারে"| account_takeover
    platform_account_hardening -->|"প্রস্তাবিত সমাধান"| account_takeover
    account_recovery_abuse -.->|"কারণ হতে পারে"| account_takeover
    account_recovery_hardening -->|"প্রস্তাবিত সমাধান"| account_recovery_abuse
    fallback_credential -.->|"কারণ হতে পারে"| account_takeover
    fallback_retirement -->|"প্রস্তাবিত সমাধান"| fallback_credential
    session_cookie_theft -->|"কারণ হতে পারে"| account_takeover
    passkey -->|"ব্যবহার নিরুৎসাহিত"| session_cookie_theft

চিত্রে, টানা রেখা সবসময় সত্য এমন সম্পর্ককে এবং ভাঙা রেখা শর্তসাপেক্ষ সম্পর্ককে নির্দেশ করে (শর্তগুলো বিস্তারিত পাতায় প্রতিটি সম্পর্কের ব্যাখ্যায় আছে)। সম্পর্কের সম্পূর্ণ তালিকা (মোট 38, প্রমাণ ও নিশ্চয়তার মাত্রাসহ) এবং প্রধান ধারণাগুলোর সংজ্ঞা জ্ঞান মানচিত্রের বিস্তারিত পাতায় সংগ্রহ করা আছে (জাপানি ভাষায়)। তথ্য: JSON-LD / Turtle

2. পাসওয়ার্ড প্রমাণীকরণে কী ভেঙেছে

পাসকির নিরাপত্তা বোঝার ছোট পথ পাসওয়ার্ডের দুর্বলতাকে «জায়গা» দিয়ে ধরা। পাসওয়ার্ড প্রমাণীকরণে গোপন তথ্য নিজেই প্রতি প্রমাণীকরণে পুরো পথ ভ্রমণ করে।

sequenceDiagram
    participant U as ব্যবহারকারী
    participant B as ব্রাউজার
    participant S as সার্ভার
    Note over U: গোপন তথ্য (পাসওয়ার্ড) মাথায় রাখে<br/>【দুর্বলতা ①】 অনুমান যায়·পুনর্ব্যবহার হয়
    U->>B: পাসওয়ার্ড ইনপুট
    Note over B: 【দুর্বলতা ②】 নকল সাইটেও একইভাবে<br/>ইনপুট যায় (চেহারায় আলাদা করা যায় না)
    B->>S: পাসওয়ার্ড নিজে পাঠানো
    Note over B,S: 【দুর্বলতা ③】 গোপন তথ্য পথে বয়ে<br/>TLS-এ রক্ষা হয় কিন্তু প্রান্তে সাধারণ লেখায় ফেরে
    S->>S: রাখা হ্যাশের সঙ্গে মিল
    Note over S: 【দুর্বলতা ④】 সব ব্যবহারকারীর গোপন তথ্য (হ্যাশ) জমা<br/>ফাঁস হলে অফলাইন ব্রুট ফোর্সের লক্ষ্য

চিত্র ১: পাসওয়ার্ড প্রমাণীকরণে গোপন তথ্য নিজে পুরো পথে থাকে

আক্রমণকারীর চোখে এটা লক্ষ্য বেশি, মারা সহজ কাঠামো।

• দুর্বলতা ① (ব্যবহারকারী): মনে রাখা যায় এমন শক্তিই, একাধিক সাইটে পুনর্ব্যবহার। এক জায়গার ফাঁস সব অ্যাকাউন্টে ছড়ায় (পাসওয়ার্ড লিস্ট আক্রমণ)।
• দুর্বলতা ② (ইনপুটের মুহূর্ত): আসল থেকে আলাদা করা যায় না নকল সাইট বানালে ব্যবহারকারী নিজে গোপন তথ্য এগিয়ে দেন (ফিশিং)।
• দুর্বলতা ③ (পথ): TLS থাকায় পথ নিজে আড়ি পাতা কঠিন, কিন্তু «বৈধ চেহারার রিলে বিন্দু» ঢোকালে অর্থ থাকে না (পরে AiTM)।
• দুর্বলতা ④ (সার্ভার): হ্যাশ করে রাখলেও ডেটাবেস ফাঁস হলে অফলাইনে ব্রুট ফোর্স চালানো যায়। দুর্বল পাসওয়ার্ড থেকে ক্রমে ভাঙে।

«তাহলে ওয়ানটাইম কোড (SMS বা TOTP) যোগ করলেই» — এই পুরনো বহু-উপাদান প্রমাণীকরণ, তবু ভাগ করা গোপন তথ্য পাঠানো কাঠামো বদলায় না। TOTP-তে সার্ভার ও অথেন্টিকেটর অ্যাপ একই সিড (গোপন তথ্য) ভাগ করে, তৈরি ৬ অঙ্কের কোড শেষে ব্যবহারকারী নকল সাইটে ইনপুট করতে পারেন। বাস্তবে নকল সাইট আসল সার্ভারে রিয়েল টাইম রিলে করা AiTM (Adversary-in-the-Middle) টাইপ ফিশিং পাসওয়ার্ড+ওয়ানটাইম কোড জোড়া সোজা পাশ কাটিয়ে ভেঙে ফেলে। CISA (মার্কিন সাইবারসিকিউরিটি সংস্থা) «ফিশিং-প্রতিরোধী MFA» হিসেবে FIDO/WebAuthn পদ্ধতি ও স্মার্ট কার্ড (PIV/CAC) ধরনের PKI ভিত্তিক প্রমাণীকরণ দুটোই তালিকা করে, তার মধ্যে FIDO-কে গোল্ড স্ট্যান্ডার্ড বলে — এই কারণে।⁴

অর্থাৎ সমস্যা পাসওয়ার্ডের «শক্তি» নয়, «গোপন তথ্য ভাগ করে প্রতি প্রমাণীকরণে পাঠানো» কাঠামো নিজে।

3. পাসকির আসল চেহারা — না পাঠিয়ে «আছে» প্রমাণ করা

পাসকি W3C-এর WebAuthn ও FIDO অ্যালায়েন্সের CTAP দুই মানের (একসঙ্গে FIDO2) উপর দাঁড়ানো পাবলিক কী ক্রিপ্টোগ্রাফি ভিত্তিক শংসাপত্র।²¹ কঠিন শোনায়, কাঠামো সরল।

flowchart LR
    subgraph DEV["ব্যবহারকারীর ডিভাইস"]
        AUTH["অথেন্টিকেটর (সিন্দুক)<br/>Windows Hello / Face ID /<br/>Android-এর স্ক্রিন লক / সিকিউরিটি কী"]
        SK["প্রাইভেট কী<br/>এখান থেকে একেবারেই বেরোয় না"]
        BIO["আঙুলের ছাপ·মুখ·PIN<br/>= সিন্দুকের দরজা খোলা মাত্র<br/>এটাও বাইরে যায় না"]
        AUTH --- SK
        BIO -->|"স্থানীয় মিল"| AUTH
    end
    subgraph SRV["সার্ভার"]
        PK["পাবলিক কী<br/>ফাঁস হলেও অপব্যবহার যায় না<br/>«যাচাই-শুধু» তথ্য"]
    end
    SK -.->|"গাণিতিক পেয়ার<br/>(স্বাক্ষর বানানো পাশ)"| PK

চিত্র ২: পাসকির সত্তা সাইট প্রতি কী পেয়ার। গোপন পাশ ডিভাইস থেকে বেরোয় না, সার্ভার শুধু যাচাইয়ের পাবলিক কী রাখে

• প্রাইভেট কী স্বাক্ষর বানাতে পারে এমন পাশের কী, ডিভাইসের অথেন্টিকেটরে (Windows Hello, iPhone-এর Face ID/Touch ID, Android-এর স্ক্রিন লক, বা YubiKey ধরনের সিকিউরিটি কী) থাকে, বাইরে যায় না।
• পাবলিক কী স্বাক্ষর যাচাই ছাড়া কিছু করতে পারে না এমন পাশের কী, এটা সার্ভারে রাখা হয়। পাবলিক কী থেকে প্রাইভেট কী উল্টে বের করা গণনায় অসম্ভব, তাই ফাঁস হলেও চলে।
• আঙুলের ছাপ·মুখ ইত্যাদি বায়োমেট্রিক তথ্য সিন্দুকের দরজা স্থানীয়ভাবে খোলার জন্যই ব্যবহার হয়, এটাও ডিভাইস থেকে বেরোয় না। সার্ভারে বায়োমেট্রিক তথ্য যায় না।¹

নিবন্ধন: পাবলিক কী «শুধু» দেওয়া

সাইটে পাসকি নিবন্ধনের প্রবাহ।

sequenceDiagram
    participant S as সার্ভার (example.com)
    participant B as ব্রাউজার
    participant A as অথেন্টিকেটর
    S->>B: নিবন্ধন অনুরোধ (র‍্যান্ডম চ্যালেঞ্জ + সাইট তথ্য)
    B->>A: এই সাইট (example.com)-এর জন্য কী বানাও
    A->>A: আঙুলের ছাপ·মুখ·PIN দিয়ে পরিচয় নিশ্চিত (স্থানীয়)
    A->>A: নতুন কী পেয়ার তৈরি<br/>প্রাইভেট কী ভিতরে সংরক্ষণ
    A->>B: পাবলিক কী + credential ID (কী-এর নামফলক)
    B->>S: পাবলিক কী + credential ID পাঠানো
    S->>S: এই অ্যাকাউন্টের পাবলিক কী হিসেবে সংরক্ষণ
    Note over S: সার্ভার যা পেল<br/>«ফাঁস হলেও অপব্যবহার যায় না তথ্য» মাত্র

চিত্র ৩: নিবন্ধনে নেটওয়ার্কে বয়ে সার্ভারে যা রাখা হয় পাবলিক কী মাত্র

জরুরি, এই সময়ে কী পেয়ার সাইটের ডোমেইন (RP ID)-এ বেঁধে তৈরি হয়। example.com-এর জন্য বানানো পাসকি example.com-এর সাইটেই ব্যবহার হয় (RP ID ডোমেইন একক, তাই login.example.com ধরনের একই ডোমেইনের সাবডোমেইন পাতা থেকে ব্যবহার যায়, অপ্রাসঙ্গিক ডোমেইন থেকে যায় না)। এই বাঁধন পরে বলা ফিশিং প্রতিরোধের ভিত্তি।³

আর কী পেয়ার সাইট প্রতি প্রতিবার নতুন তৈরি হয়। সাইট A ও সাইট B-এর পাসকি গাণিতিকভাবে অসম্পর্কিত, তাই «পুনর্ব্যবহার» ধারণাই নেই, সাইটের মধ্যে ব্যবহারকারী মেলানোর উপাদানও হয় না।

প্রমাণীকরণ: সেই মুহূর্তের স্বাক্ষর ফেরানো

লগইনের প্রবাহ। পাসওয়ার্ড প্রমাণীকরণ (চিত্র ১)-এর সঙ্গে মিলিয়ে দেখুন।

sequenceDiagram
    participant S as সার্ভার (example.com)
    participant B as ব্রাউজার
    participant A as অথেন্টিকেটর
    S->>B: লগইন অনুরোধ (সেই মুহূর্তের র‍্যান্ডম চ্যালেঞ্জ)
    B->>A: example.com-এ স্বাক্ষর অনুরোধ
    A->>A: আঙুলের ছাপ·মুখ·PIN দিয়ে পরিচয় নিশ্চিত (স্থানীয়)
    A->>A: প্রাইভেট কী দিয়ে স্বাক্ষর তৈরি<br/>চ্যালেঞ্জ + অরিজিন + RP ID হ্যাশ পোঁতা
    A->>B: স্বাক্ষর (প্রাইভেট কী নিজে নয়)
    B->>S: স্বাক্ষর পাঠানো
    S->>S: রাখা পাবলিক কী দিয়ে স্বাক্ষর যাচাই<br/>চ্যালেঞ্জ·অরিজিন·RP ID-ও নিশ্চিত
    Note over B,S: পথে যা বয়ে একবার ব্যবহারের স্বাক্ষর মাত্র<br/>চুরি করলেও পরের চ্যালেঞ্জে কাজে লাগে না

চিত্র ৪: প্রমাণীকরণেও গোপন তথ্য নড়ে না। যা বয়ে «সেই মুহূর্তের প্রমাণপত্র» মাত্র

সার্ভার প্রতিবার নতুন র‍্যান্ডম সংখ্যা (চ্যালেঞ্জ) দেয়, অথেন্টিকেটর «সেই চ্যালেঞ্জ + এখন ব্রাউজার যে অরিজিন দেখছে + RP ID-এর হ্যাশ»-এ স্বাক্ষর করে। সার্ভার রাখা পাবলিক কী দিয়ে স্বাক্ষর যাচাই করে, চ্যালেঞ্জ নিজের দেওয়া কি না, অরিজিন ও RP ID নিজের সাইটের কি না নিশ্চিত করে।⁵

এই নকশার ফল হিসেবে শুরুর তিন কারণের দুটো ইতিমধ্যে দাঁড়ায়।

• সার্ভারে গোপন তথ্য নেই: যা রাখা পাবলিক কী মাত্র। ফাঁস হলেও আক্রমণকারী স্বাক্ষর বানাতে পারে না, পাসওয়ার্ড হ্যাশের মতো «নিয়ে গিয়ে ভাঙা» যায় না।
• গোপন তথ্য বয়ে না: পথের স্বাক্ষর চুরি করলেও চ্যালেঞ্জ একবার ব্যবহারের, পুনর্ব্যবহার (রিপ্লে) যায় না।

বাকি একটা, «নকল সাইটে স্বাক্ষর দাঁড়ায় না» — পাসকির সবচেয়ে বড় বিক্রি। অধ্যায় আলাদা করে দেখি।

4. ফিশিং «কাঠামোগতভাবে» দাঁড়ায় না কেন

পাসওয়ার্ডে ফিশিং সফল হয় কারণ আসল গোপন তথ্য নকল সাইটে ইনপুট করা যায়। মানুষ example.com আর examp1e.com আলাদা করতে পারে না (ক্লান্ত হলে বিশেষ করে), কিন্তু পাসওয়ার্ড ইনপুট ঘর দুই সাইটেই একইভাবে চলে।

পাসকিতে এই মিল মানুষ নয় ব্রাউজার যান্ত্রিকভাবে করে। WebAuthn স্পেসিফিকেশনে ব্রাউজার «এখন যে অরিজিন দেখাচ্ছে তার ডোমেইন» ও «পাসকির RP ID» মিললেই অথেন্টিকেটর ডাকতে পারে।³ নকল সাইটে ঢোকার মুহূর্তে কী হয় চিত্রে।

sequenceDiagram
    participant U as ব্যবহারকারী
    participant B as ব্রাউজার
    participant P as নকল সাইট (examp1e.com)<br/>আসলে রিলে করা AiTM প্রক্সি
    participant S as আসল সার্ভার (example.com)
    U->>P: চেহারায় হুবহু লগইন পর্দায় প্রবেশ
    P->>S: (পেছনে) আসল লগইন প্রক্রিয়া শুরু
    S->>P: চ্যালেঞ্জ
    P->>B: চ্যালেঞ্জ পাশ কাটিয়ে স্বাক্ষর চায়
    B->>B: এখনকার অরিজিন examp1e.com<br/>example.com-এর পাসকি প্রার্থীতে দেওয়া যায় না
    B--xP: স্বাক্ষর তৈরি হয় না (ব্যবহারকারী ধোঁকা খেতে পারেন না)
    Note over B,S: কোনোভাবে স্বাক্ষর তৈরি হলেও<br/>স্বাক্ষরে examp1e.com পোঁতা থাকে তাই<br/>আসল সার্ভারের যাচাইয়ে অবশ্যই পড়ে

চিত্র ৫: AiTM টাইপ ফিশিং পাসওয়ার্ড+ওয়ানটাইম কোড ভেঙে ফেলে, পাসকিতে স্বাক্ষরের ধাপেই দাঁড়ায় না

প্রতিরক্ষা দ্বৈত — খেয়াল করুন।

1. প্রার্থীতে আসে না: ব্রাউজার অরিজিনের RP ID-এর পাসকিই তালিকা করে। নকল ডোমেইনে আসল সাইটের পাসকি বিকল্পে আসে না, ব্যবহারকারী «ভুলে ব্যবহার»ও করতে পারেন না।
2. স্বাক্ষর পাস করে না: স্বাক্ষরের লক্ষ্যে ব্রাউজার নিশ্চিত করা অরিজিন ও RP ID-এর হ্যাশ থাকে। আসল সার্ভার যাচাইয়ে এটা মেলায়, তাই আলাদা অরিজিনে বানানো স্বাক্ষর অবশ্যই প্রত্যাখ্যান হয়।⁵

পাসওয়ার্ডের ফিশিং মোকাবিলা «ব্যবহারকারী URL ভালো করে দেখবেন» মানুষের চেষ্টার উপর নির্ভর করত। পাসকিতে ব্যবহারকারীকে নকল সাইট চিনতেই হয় না। এটাই «ফিশিং-প্রতিরোধী (phishing-resistant)» শব্দের সঠিক অর্থ, CISA ও NIST (মার্কিন মান ইনস্টিটিউট) FIDO/WebAuthn পদ্ধতিকে বিশেষ স্থান দেওয়ার কারণ।⁴⁶

এ পর্যন্ত বিষয় আক্রমণ পদ্ধতি অনুযায়ী সাজাই।

সারণি ২: আক্রমণ পদ্ধতি অনুযায়ী প্রতিরোধ তুলনা। পাসকির «○» সবই পরিচালনা বা মনোযোগ নয়, কাঠামো থেকে

5. «সিঙ্ক হওয়া পাসকি» নিরাপদ কি

এ পর্যন্ত পড়ে স্বাভাবিক প্রশ্ন ওঠে। «প্রাইভেট কী ডিভাইস থেকে বেরোয় না বলেছিলেন, তাহলে iPhone-এ বানানো পাসকি iPad-এ কেন চলে» — ভালো প্রশ্ন, উত্তর «পাসকি দুই ধরনের»।

আগে উপসংহার দ্রুত সারণিতে। এই অধ্যায় ও পরের অধ্যায় এই সারণির প্রতি সারি কেন এমন তা ব্যাখ্যা।

সারণি ৩: সিঙ্ক টাইপ ও ডিভাইস-বাউন্ডের দ্রুত সারণি। কোনটা বাছবেন «হারানোর শক্তি» আর «কী কোথায় সামলানো যায়» কোনটা নেবেন তা দিয়ে স্থির

flowchart TB
    subgraph SYNC["সিঙ্ক টাইপ পাসকি (ভোক্তার ডিফল্ট)"]
        S1["iCloud কিচেইন /<br/>Google পাসওয়ার্ড ম্যানেজার /<br/>1Password ইত্যাদি পাসওয়ার্ড ম্যানেজার"]
        S2["একই অ্যাকাউন্টের ডিভাইসের মধ্যে<br/>এন্ড-টু-এন্ড এনক্রিপ্ট করে সিঙ্ক<br/>পরিচালনাকারীও ভিতর পড়তে পারে না"]
        S3["সুবিধা: মডেল বদল·হারানোয় শক্ত<br/>সতর্কতা: ক্লাউড অ্যাকাউন্ট নিজে রক্ষা লাগে"]
        S1 --> S2 --> S3
    end
    subgraph BOUND["ডিভাইস-বাউন্ড পাসকি"]
        B1["সিকিউরিটি কী (YubiKey ইত্যাদি) /<br/>Windows Hello /<br/>Microsoft Authenticator (Entra ID)"]
        B2["প্রাইভেট কী সেই হার্ডওয়্যার থেকে<br/>শারীরিকভাবে বেরোয় না (TPM ইত্যাদিতে রক্ষা)"]
        B3["সুবিধা: কী কোথায় এক জায়গায় স্পষ্ট<br/>সতর্কতা: হারানোর জন্য একাধিক নিবন্ধন আবশ্যক"]
        B1 --> B2 --> B3
    end
    SYNC ~~~ BOUND

চিত্র ৬: সিঙ্ক টাইপ ও ডিভাইস-বাউন্ড। দুটোই «প্রাইভেট কী সার্ভারে না পাঠানো» একই, রক্ষার কেন্দ্র আলাদা

সিঙ্ক টাইপ পাসকি iCloud কিচেইন বা Google পাসওয়ার্ড ম্যানেজার প্রাইভেট কী একই অ্যাকাউন্টের ডিভাইসের মধ্যে সিঙ্ক করে। এখানে জরুরি সিঙ্ক এন্ড-টু-এন্ড এনক্রিপ্ট। Appleও Googleও পাসকি ডিভাইসে এনক্রিপ্ট হয়ে তারপর সিঙ্ক হয়, পরিচালনাকারী নিজে ভিতর পড়তে পারে না বলে স্পষ্ট করেছে।⁷⁸ অর্থাৎ «প্রাইভেট কী ডিভাইস থেকে বেরোয় না» নীতি সঠিকভাবে «প্রাইভেট কী সাধারণ লেখায় ডিভাইস থেকে বেরোয় না»-এ শিথিল, বিনিময়ে মডেল বদল·হারানোর প্রতিরোধ পায়।

এই শিথিলকরণ হুমকি মডেল কীভাবে বদলায় স্পষ্ট ভাষায় রাখা উচিত। রক্ষার জায়গা «প্রতি সাইটের সার্ভার» থেকে «একটা ক্লাউড অ্যাকাউন্ট»-এ জমা হয়। প্রতি সাইটের DB ফাঁস বা ফিশিংয়ে আগের মতোই শক্ত, এবার Apple ID/Google অ্যাকাউন্ট নিজে দখল একক ব্যর্থতা বিন্দু হয়। তাই পাসকি রাখা প্ল্যাটফর্ম অ্যাকাউন্টে সবচেয়ে শক্ত রক্ষা (শক্ত স্ক্রিন লক, পুনরুদ্ধার উপায় গুছানো, সম্ভব হলে শারীরিক সিকিউরিটি কী) বড় পূর্বশর্ত। NIST-ও ২০২৪ সালের এপ্রিলে NIST SP 800-63B-এর সংযোজন (Supplement 1: Incorporating Syncable Authenticators Into NIST SP 800-63B) বের করে এই সিঙ্ক টাইপ পাসকি (syncable authenticator) শর্ত মিললে সরকারি মান AAL2 (Authenticator Assurance Level 2, অথেন্টিকেটর নিশ্চয়তা স্তর ২) পূরণ করতে পারে বলে আনুষ্ঠানিক স্থান দিয়েছে। তবে প্রাইভেট কী এক্সপোর্ট হতে পারে বলে হার্ডওয়্যারে আলাদা পরিবেশ চায় AAL3-এ সিঙ্ক টাইপ ব্যবহার করবেন না বলা আছে।⁶

ডিভাইস-বাউন্ড পাসকি প্রাইভেট কী হার্ডওয়্যার থেকে বেরোয় না এমন টাইপ। YubiKey ধরনের সিকিউরিটি কী প্রতিনিধি, কর্পোরেট পাশে Microsoft Entra ID-এর পাসকি (Microsoft Authenticator-এ বানানো)ও ডিভাইস-বাউন্ড।⁹ Windows-এর Windows Hello-ও TPM থাকলে প্রাইভেট কী TPM-এর নিচে রক্ষা করে। এই «কী বাইরে না ছাড়ার হার্ডওয়্যার সিন্দুক» ব্যবস্থা নিজে TPM নিবন্ধ-এ বিস্তারিত যে ভিত্তি তারই।

আর «ফোনের পাসকি দিয়ে PC-এর ব্রাউজারে লগইন»-এ QR কোড স্ক্যান করানো অদ্ভুত লাগতে পারে। সেটা শুধু পর্দা বদল নয়, Bluetooth দিয়ে ফোন ও PC-এর শারীরিক নৈকট্য নিশ্চিত করা হাইব্রিড পদ্ধতি (FIDO-এর cross-device প্রমাণীকরণ)। দূরের আক্রমণকারী নিজের PC-এ লগইন QR কোড দিয়ে অন্যকে অনুমোদন করানো আক্রমণ নৈকট্য নিশ্চিতকরণে ভাঙে।¹

6. রুপোর গুলি নয় — দুর্বলতা «মিলিয়ে যায়» না, «সরয়»

এ পর্যন্ত পাসকির শক্তি ব্যাখ্যা করেছি, কিন্তু সততার সঙ্গে বললে পাসকি আক্রমণ মিলিয়ে দেয় না আক্রমণকারীকে আরও দুর্বল জায়গায় ঠেলে দেয় প্রযুক্তি। প্রমাণীকরণের দরজা শক্ত হলে আক্রমণকারী কোথায় ঘোরে চিত্রে।

flowchart LR
    A["আক্রমণকারী"]
    G["প্রমাণীকরণ নিজে<br/>চ্যালেঞ্জ স্বাক্ষর<br/>【শক্ত】"]
    R["অ্যাকাউন্ট পুনরুদ্ধার প্রবাহ<br/>«পাসকি হারিয়েছি» বলে<br/>SMS বা ইমেইলে আবার সেট করিয়ে<br/>আক্রমণকারীর পাসকি নিবন্ধন"]
    F["পাশাপাশি থাকা ফলব্যাক<br/>পাসওয়ার্ড·SMS লগইন<br/>থাকলে সবচেয়ে দুর্বল লিঙ্ক সেখানে"]
    C["ক্লাউড অ্যাকাউন্ট<br/>সিঙ্ক টাইপ হলে Apple ID /<br/>Google অ্যাকাউন্ট একক ব্যর্থতা বিন্দু"]
    SS["সেশন<br/>লগইনের পর Cookie চুরি করলে<br/>প্রমাণীকরণ পদ্ধতি অপ্রাসঙ্গিক"]
    A --x G
    A --> R
    A --> F
    A --> C
    A --> SS

চিত্র ৭: দরজা (প্রমাণীকরণ) শক্ত হলে আক্রমণ পুনরুদ্ধার প্রবাহ·পাশাপাশি উপায়·ক্লাউড অ্যাকাউন্ট·সেশনে সরয়

বাস্তবে ধরার অবশিষ্ট ঝুঁকি চারটা।

1. পাশাপাশি ফলব্যাক সবচেয়ে দুর্বল লিঙ্ক হয়। পাসকি «ও» ব্যবহার করা যায় করলেই পাসওয়ার্ড বা SMS লগইন থাকলে আক্রমণকারী সেদিকেই যায়। ফিশিং প্রতিরোধ অ্যাকাউন্ট পুরো দেখলে সবচেয়ে দুর্বল লগইন উপায়ের স্তর-এ আটকে যায়। বসানোর মূল কাজ পাসকি যোগ নয়, ফলব্যাক পরিকল্পিত ছোট করা·বন্ধ করা।
2. পুনরুদ্ধার প্রবাহ নতুন আক্রমণ তল হয়। «ডিভাইস হারিয়েছি» মিথ্যা বলে সাপোর্ট ডেস্ক বা ইমেইল দিয়ে আবার সেটে আক্রমণকারীর নিজের পাসকি নিবন্ধন করানো কৌশল। বাস্তবে শক্ত প্রমাণীকরণ এড়িয়ে হেল্পডেস্ক ধোঁকা দেওয়া সামাজিক প্রকৌশল বড় লঙ্ঘনের নিয়মিত হাতিয়ার। প্রমাণীকরণ শক্ত করার বিনিময়ে পুনরুদ্ধার প্রবাহের পরিচয় নিশ্চিতকরণ কীভাবে নকশা করবেন সেটাই প্রশ্ন।
3. সিঙ্ক টাইপে ক্লাউড অ্যাকাউন্ট একক ব্যর্থতা বিন্দু। আগের অধ্যায় অনুযায়ী। পাসকি রাখা অ্যাকাউন্টের রক্ষা ও সংস্থায় ব্যবহার করলে «কোন প্ল্যাটফর্মে সিঙ্ক অনুমতি» নীতি স্থির লাগে।
4. সেশন চুরি ঠেকায় না। পাসকি রক্ষা করে লগইনের মুহূর্ত মাত্র, লগইনের পর সেশন কুকি ম্যালওয়্যার বা XSS-এ চুরি হলে প্রমাণীকরণ পদ্ধতি অপ্রাসঙ্গিক। টোকেনের মেয়াদ·বাইন্ডিং·ডিভাইস স্বাস্থ্য সামলানো আলাদা স্তরের কাজ থেকে যায়।

এগুলো «পাসকি বাদ দিন» কথা নয়। দরজার তালা নতুন করলেও জানালার তালা আলাদা কাজ — এই সাধারণ কথা। বরং দুর্বলতার জায়গা স্পষ্ট হওয়ায় প্রতিরক্ষা সম্পদ পুনরুদ্ধার প্রবাহ ও সেশন ব্যবস্থাপনায় কেন্দ্রীভূত করা যায়।

7. বাস্তবে বসানো — WebAuthn API ও Windows পরিবেশ

শেষে বসানো পাশের দৃষ্টিতে মূল কথা ধরি।

নিজের Web সার্ভিসে পাসকি লগইন লাগানো

ব্রাউজার পাশে WebAuthn API-এর দুই ফাংশনই। নিবন্ধন navigator.credentials.create(), প্রমাণীকরণ navigator.credentials.get() ডাকে।

// নিবন্ধন (ব্রাউজার পাশে)
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: challengeFromServer,   // সার্ভার তৈরি করা একবার ব্যবহারের র‍্যান্ডম সংখ্যা
    rp: { id: "example.com", name: "Example" },
    user: { id: userIdBytes, name: "taro@example.com", displayName: "Taro" },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }],  // ES256
    authenticatorSelection: {
      residentKey: "required",        // ডিসকভারেবল শংসাপত্র (= পাসকি) করে
      userVerification: "required",   // বায়োমেট্রিক·PIN দিয়ে পরিচয় নিশ্চিতকরণ বাধ্যতামূলক করে
    },
  },
});
// পাবলিক কী credential.response থেকে, credential ID উপরের স্তরের
// credential.id / credential.rawId থেকে নেওয়া। নিবন্ধনের সাড়াও প্রমাণীকরণের
// মতো চ্যালেঞ্জ·অরিজিন·RP ID সার্ভারে যাচাই করে তারপর সংরক্ষণ করা

মূল প্যারামিটারের অর্থ নিচের মতো।

সারণি ৪: navigator.credentials.create()-এর মূল প্যারামিটার

যাচাই পরিবেশের সতর্কতা: WebAuthn API সিকিউর কনটেক্সটেই প্রকাশিত, তাই সাধারণ http:// দিয়ে দেওয়া পাতায় navigator.credentials কল ব্যর্থ হয়। ব্যতিক্রম http://localhost (ও 127.0.0.1), এগুলো বিশ্বস্ত অরিজিন হিসেবে গণ্য, তাই ডেভ মেশিনে HTTPS না করেই চেষ্টা যায়। তবে RP ID অরিজিনের কার্যকর ডোমেইন (বা তার পিতা ডোমেইন) হতে হয়, তাই localhost-এ বানানো পাসকি প্রোডাকশন ডোমেইনে চলে না। হাতে অথেন্টিকেটর না থাকলেও Chrome ডেভেলপার টুলসের «WebAuthn» ট্যাবে ভার্চুয়াল অথেন্টিকেটর চালু করলে নিবন্ধন থেকে প্রমাণীকরণ পর্যন্ত এক পাকে চালানো যায়।

// প্রমাণীকরণ (ব্রাউজার পাশে)
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: challengeFromServer,
    rpId: "example.com",
    userVerification: "required",
  },
  // লগইন ঘরের স্বয়ংক্রিয় পূরণ প্রার্থী হিসেবে পাসকি দেখায়। আগে
  // PublicKeyCredential.isConditionalMediationAvailable() দিয়ে সমর্থন নিশ্চিত করে,
  // অসমর্থিত ব্রাউজারে mediation ছাড়া সাধারণ কলে ফলব্যাক করা
  mediation: "conditional",
  // (লক্ষ্য <input>-এ autocomplete="username webauthn" নির্দিষ্ট করা দরকার)
});
// assertion.response-এর স্বাক্ষর সার্ভারে যাচাই করা

মূল কাজ সার্ভার পাশের যাচাই। ন্যূনতম অবশ্যই নিচেরটা করুন।⁵

• চ্যালেঞ্জ মিল: নিজে ইস্যু করা অব্যবহৃত চ্যালেঞ্জ কি। একবার ব্যবহারের কি (রিপ্লে মোকাবিলা)। আর ইস্যুর সময়ের ব্রাউজার সেশন (লগইন চেষ্টা)-এ বেঁধে রেখে শুধু সেই সেশন থেকে সাড়া খরচ অনুমতি। এটা ঢিলা হলে আক্রমণকারী নিজের উদ্দেশ্যে চ্যালেঞ্জের স্বাক্ষর ভিকটিমের ব্রাউজার দিয়ে পাঠিয়ে ভিকটিমকে আক্রমণকারীর অ্যাকাউন্টে লগইন করানো (লগইন CSRF) ফাঁক তৈরি হয়।
• অরিজিন মিল: clientDataJSON-এর origin নিজের সাইটের বৈধ অরিজিন কি (ফিশিং মোকাবিলার চাবি)।
• RP ID হ্যাশ মিল: authenticatorData-এর rpIdHash নিজের সাইটের RP ID-এর SHA-256-এর সঙ্গে মিলে কি।
• সেরেমনি ধরন ও ফ্ল্যাগ নিশ্চিতকরণ: clientDataJSON-এর type প্রমাণীকরণে webauthn.get, নিবন্ধনে webauthn.create কি। authenticatorData-এর UP (ইউজার প্রেজেন্ট) ফ্ল্যাগ দাঁড়িয়ে কি। ইউজার ভেরিফিকেশন (UV) চাইলে UV ফ্ল্যাগও দাঁড়িয়ে কি।
• স্বাক্ষর যাচাই: নিবন্ধনে রাখা পাবলিক কী দিয়ে স্বাক্ষর সঠিক যাচাই হয় কি।
• অ্যাকাউন্টের সঙ্গে বাঁধন: উপস্থাপিত credential ID (ও userHandle) নিজের ডেটাবেসে টেনে সেই শংসাপত্রের মালিককে সেশন ইস্যু করছেন কি। আলাদা ইনপুট করা ব্যবহারকারী নাম নিঃশর্ত বিশ্বাস করলে সঠিক স্বাক্ষরে অন্য হিসেবে লগইন করানো ফাঁক হয়।
• স্বাক্ষর কাউন্টার সংরক্ষণ ও তুলনা: authenticatorData-এর signCount শংসাপত্র প্রতি রেখে পরের মান আগের চেয়ে বেড়েছে নিশ্চিত করুন। আগের মানের নিচে বা সমান হলে অথেন্টিকেটর প্রতিলিপি (ক্লোন)-এর লক্ষণ হিসেবে ধরুন। তবে সিঙ্ক টাইপ পাসকি প্রায়ই সবসময় 0 ফেরায়, তাই শুধু 0 থেকে 0 ব্যতিক্রম হিসেবে অনুমতি দিন।

এই যাচাই হাতে লেখা দুর্ঘটনার বীজ, তাই প্রমাণিত লাইব্রেরি (.NET-এ fido2-net-lib, Node.js-এ SimpleWebAuthn ইত্যাদি) ব্যবহার করুন। স্পেসিফিকেশনের বিস্তার (CBOR পার্স, অ্যালগরিদম সম্মতি, চ্যালেঞ্জ ব্যবস্থাপনা) লাইব্রেরিতে ছেড়ে নিজেরা চ্যালেঞ্জ সংরক্ষণ ও বাতিল, একাধিক পাসকির ব্যবস্থাপনা UI, পুনরুদ্ধার প্রবাহের নকশায় শক্তি কেন্দ্রীভূত করাই সঠিক ভাগ।

Windows পরিবেশ·অভ্যন্তরীণ সিস্টেমের ক্ষেত্রে

এই সাইটের পাঠক «Windows ব্যবসায়িক সিস্টেম সামলানো অবস্থান» থেকে নিচের তিনটা ধরে রাখলে যথেষ্ট।

• Windows ক্লায়েন্ট ইতিমধ্যে সমর্থন করে। Windows 11 Windows Hello-কে অথেন্টিকেটর করে পাসকি তৈরি·ব্যবহার·ব্যবস্থাপনা (সেটিংস > অ্যাকাউন্ট > পাসকি) সমর্থন করে, প্রাইভেট কী TPM থাকলে হার্ডওয়্যার রক্ষা পায়।¹⁰ ব্রাউজার (Edge/Chrome) দিয়ে WebAuthn Windows 10-এও চলে।
• Entra ID পরিবেশে «পাসকি = FIDO2 প্রমাণীকরণ পদ্ধতি» সক্রিয় করুন। Microsoft Entra ID সিকিউরিটি কী ও Microsoft Authenticator অ্যাপের পাসকি (ডিভাইস-বাউন্ড) সমর্থন করে, কন্ডিশনাল অ্যাক্সেসের প্রমাণীকরণ শক্তিতে «ফিশিং-প্রতিরোধী MFA» চাইলে লক্ষ্য রিসোর্সে অ্যাক্সেস পাসকি ইত্যাদিতে সীমিত করা যায়।⁹ NTLM বা পাসওয়ার্ড মেয়াদ নীতির জগৎ থেকে এক লাফে এগোয় না, তাই NTLM ও Kerberos নিবন্ধ-এ যে প্রমাণীকরণ অবকাঠামোর তালিকা তার সঙ্গে আগে প্রশাসক অ্যাকাউন্ট থেকে ফিশিং-প্রতিরোধী MFA বাধ্যতামূলক করাই নিয়ম।
• অভ্যন্তরীণ Web অ্যাপেও উপকার একই। তবে HTTPS পূর্বশর্ত। WebAuthn API সিকিউর কনটেক্সটেই চলে, তাই ইন্ট্রানেট অ্যাপেও (ডেভের localhost ছাড়া) HTTPS ও RP ID হিসেবে ব্যবহারযোগ্য অভ্যন্তরীণ ডোমেইন নাম সাজানো আগে। সেটা হলে RP ID অভ্যন্তরীণ ডোমেইনেও কাজ করে। পাসওয়ার্ড স্টিকি নোট ছাড়ার অর্থ বহির্মুখী সার্ভিসের চেয়ে অভ্যন্তরীণে ফল তাড়াতাড়ি আসাও বিরল নয়।

8. সারসংক্ষেপ

• পাসওয়ার্ডের দুর্বলতা শক্তি নয়, «গোপন তথ্য ভাগ করে প্রতি প্রমাণীকরণে পাঠানো» কাঠামো। গোপন তথ্য ব্যবহারকারী·ইনপুট ঘর·পথ·সার্ভার সব জায়গায় থাকে, তাই আক্রমণের লক্ষ্য বেশি। ওয়ানটাইম কোড যোগ করলেও AiTM টাইপ ফিশিংয়ে রিলে হয়ে হারে।
• পাসকি সাইট প্রতি পাবলিক কী ক্রিপ্টোগ্রাফির কী পেয়ার, সার্ভারে ফাঁস হলেও অপব্যবহার যায় না পাবলিক কীই দেয়, লগইনে একবার ব্যবহারের চ্যালেঞ্জের স্বাক্ষরই পাঠায়। সার্ভারে গোপন তথ্য নেই, পথেও গোপন তথ্য বয়ে না।
• স্বাক্ষরে ব্রাউজার নিশ্চিত করা অরিজিন ও RP ID পোঁতা থাকে, তাই নকল সাইতে আসল পাসকি প্রার্থীতে আসে না, রিলে করলেও যাচাইয়ে পড়ে। ব্যবহারকারীকে নকল সাইট চিনতে হয় না — এটাই «ফিশিং প্রতিরোধ»-এর সত্তা, প্রতিরক্ষার ভিত্তি মানুষের মনোযোগ থেকে প্রোটোকলের কাঠামোতে সরয়।
• সিঙ্ক টাইপ পাসকি এন্ড-টু-এন্ড এনক্রিপ্ট করে সিঙ্ক হয়, মডেল বদল·হারানোয় শক্ত। বিনিময়ে রক্ষার জায়গা ক্লাউড অ্যাকাউন্টে জমা, তাই Apple ID/Google অ্যাকাউন্ট নিজে রক্ষা বড় পূর্বশর্ত। কর্পোরেট ডিভাইস-বাউন্ড (সিকিউরিটি কী, Entra ID-এর Authenticator পাসকি)ও বাছতে পারে।
• পাসকি আক্রমণ মিলিয়ে দেয় না দুর্বল জায়গায় ঠেলে দেয়। পাশাপাশি পাসওয়ার্ড, অ্যাকাউন্ট পুনরুদ্ধার প্রবাহ, সেশন চুরি অবশিষ্ট আক্রমণ তল, বসানোর মূল কাজ ফলব্যাক পরিকল্পিত ছোট করা ও পুনরুদ্ধার প্রবাহ শক্ত করা।
• বাস্তবায়ন WebAuthn API-এর create / get দুই ফাংশন + সার্ভার যাচাই। যাচাই নিজে বানাবেন না, প্রমাণিত লাইব্রেরিতে ছেড়ে চ্যালেঞ্জ ব্যবস্থাপনা·একাধিক পাসকির UI·পুনরুদ্ধার নকশায় শক্তি দিন।

সম্পর্কিত নিবন্ধ

• Windows-এ TPM কী — চিত্রে বোঝা «কী বাইরে না ছাড়ার সিন্দুক» ও পরিমাপ বুট
• চিত্রে বোঝা NTLM ও Kerberos — প্রমাণীকরণ কেন NTLM-এ «পড়ে»
• WinForms/WPF অ্যাপে Entra ID প্রমাণীকরণ বসানো — MSAL.NET ও WAM ব্রোকারের বাস্তব কনফিগার
• PowerShell-এ শংসাপত্র নিরাপদে সামলানো — সাধারণ লেখা পাসওয়ার্ড স্ক্রিপ্ট থেকে সরান
• Windows অ্যাপ ডেভেলপমেন্টের নিরাপত্তা ন্যূনতম চেকলিস্ট
• ছোট ব্যবসার নিরাপত্তা, কোথা থেকে শুরু — IPA «ছোট ব্যবসার তথ্য নিরাপত্তা নির্দেশিকা» ৪.০ সংস্করণের পথ

সম্পর্কিত পরামর্শ ক্ষেত্র

KomuraSoft LLC অভ্যন্তরীণ Web সিস্টেমে পাসকি লগইন WebAuthn বাস্তবায়নের সহায়তা, Entra ID পরিবেশে ফিশিং-প্রতিরোধী MFA রোলআউটের নকশা, WinForms/WPF ইত্যাদি Windows ব্যবসায়িক অ্যাপে প্রমাণীকরণ বসানোসহ Custom Software Development সামলায়।

সম্পর্কিত নিবন্ধ

কাছাকাছি বিষয়ে গভীরে যেতে একই ট্যাগযুক্ত সাম্প্রতিক নিবন্ধ।

সম্পর্কিত বিষয়

এই পৃষ্ঠাগুলো বিষয়টিকে সেবা ও সিদ্ধান্তের বৃহত্তর প্রেক্ষাপটে স্থাপন করে।

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

এই নিবন্ধের বিষয়ে পরামর্শে প্রায়ই আসা প্রশ্ন।

পাসকি আর পাসওয়ার্ডের মৌলিক ফারাক কী?

পাসওয়ার্ড «ব্যবহারকারী ও সার্ভার একই গোপন তথ্য ভাগ করে, লগইনে সেই গোপন তথ্য পাঠায়» ব্যবস্থা। গোপন তথ্য ব্যবহারকারীর মাথায়·ইনপুট ঘরে·যোগাযোগ পথে·সার্ভারের ডেটাবেসে — সব জায়গায় থাকে, তাই সব জায়গা আক্রমণের লক্ষ্য। পাসকি পাবলিক কী ক্রিপ্টোগ্রাফির কী পেয়ার ব্যবহার করে, প্রাইভেট কী সার্ভারে যায় না। ডিভাইস-বাউন্ডে প্রাইভেট কী অথেন্টিকেটর থেকে একেবারেই বেরোয় না, সিঙ্ক টাইপেও এন্ড-টু-এন্ড এনক্রিপ্ট রূপেই বাইরে যায়। সার্ভারে যা থাকে পাবলিক কী — «ফাঁস হলেও অপব্যবহার যায় না এমন তথ্য» — আর লগইনে যা যায় সেই মুহূর্তের চ্যালেঞ্জের স্বাক্ষর মাত্র। অর্থাৎ পাসওয়ার্ডের দুর্বলতা ছিল যে «ভাগ করা গোপন তথ্য» তাই নেই। তার উপর কী পেয়ার সাইট প্রতি আলাদা তৈরি হয়, তাই পুনর্ব্যবহারের ধারণাও দাঁড়ায় না।

বায়োমেট্রিক তথ্য (আঙুলের ছাপ·মুখ) সার্ভারে যায়?

যায় না। আঙুলের ছাপ বা মুখের ডেটা ডিভাইসের ভিতরে «প্রাইভেট কী-এর সিন্দুকের দরজা খোলা»র জন্যই স্থানীয় মিল, FIDO-এর নকশায় বায়োমেট্রিক তথ্য ডিভাইসের বাইরে যায় না। সার্ভার যা পায় «ব্যবহারকারীর পরিচয় নিশ্চিতকরণ (ইউজার ভেরিফিকেশন) হয়েছে» ফ্ল্যাগসহ স্বাক্ষর মাত্র, আঙুলের ছাপ তো নয়, তার বৈশিষ্ট্য ভেক্টরও থাকে না। বায়োমেট্রিক ব্যবহার করা যায় না এমন জায়গায় PIN বিকল্প, এই PIN-ও Windows Hello-এর PIN-এর মতো শুধু ডিভাইসে স্থানীয় মিল, নেটওয়ার্কে না বয়ে পাসওয়ার্ড থেকে নির্ণায়ক ফারাক।

পাসকি কেন ফিশিংয়ে শক্ত?

ব্যবহারকারীকে নকল সাইট চিনতে হওয়ার প্রয়োজন ব্যবস্থায়ই নেই। পাসকি সাইটের ডোমেইন (RP ID)-এ বেঁধে তৈরি হয়, ব্রাউজার «এখন যে সাইট দেখাচ্ছে তার ডোমেইন»-এর পাসকিই প্রার্থী দেখায়। আসলের হুবহু নকল ডোমেইনে গেলেও আসল সাইটের পাসকি বিকল্পে আসে না, ব্যবহারকারী ধোঁকা খেতে পারেন না। তার উপর স্বাক্ষরে ব্রাউজার নিশ্চিত করা অরিজিন ও RP ID-এর হ্যাশ পুঁতে থাকে, স্বাক্ষর রিলে করলেও আসল সার্ভারের যাচাইয়ে পড়ে। পাসওয়ার্ড বা SMS কোডের মতো «আসল শংসাপত্র নকল সাইটে ইনপুট» দুর্ঘটনা কাঠামোগতভাবে ঘটানো যায় না — প্রশিক্ষণ বা সতর্কতার উপর ভরসা করা মোকাবিলার সঙ্গে এই মৌলিক ফারাক।

ফোন হারালে অ্যাকাউন্টে ঢোকা যাবে না?

সিঙ্ক টাইপ পাসকি (iCloud কিচেইন বা Google পাসওয়ার্ড ম্যানেজারে রাখা) হলে একই Apple ID/Google অ্যাকাউন্টে সাইন-ইন করা নতুন ডিভাইসে পুনরুদ্ধার যায়। তবে এন্ড-টু-এন্ড এনক্রিপ্ট ভল্ট পুনরুদ্ধারে অ্যাকাউন্ট পাসওয়ার্ড ছাড়াও আগের টার্মিনালের স্ক্রিন লক (পাসকোড) ইনপুট ইত্যাদি অতিরিক্ত পরিচয় নিশ্চিতকরণ চাওয়া হয়, এই পুনরুদ্ধার উপায়ও হারালে পুনরুদ্ধার নাও হতে পারে। একটা ফোনে সব না রাখার ভঙ্গি জরুরি। ডিভাইস-বাউন্ড (সিকিউরিটি কী বা Windows Hello ইত্যাদি) টার্মিনালের ভাগ্য ভাগ করে, তাই গুরুত্বপূর্ণ অ্যাকাউন্টে একাধিক পাসকি নিবন্ধনই নিয়ম। অনেক সার্ভিস এক অ্যাকাউন্টে একাধিক পাসকি নিবন্ধন দেয়। হারালে অকার্যকর করার ধাপ টাইপ অনুযায়ী বদলায়। সিঙ্ক টাইপে প্রতি ডিভাইসের কপি একই শংসাপত্র, তাই আগে প্ল্যাটফর্ম অ্যাকাউন্ট পাশে হারানো টার্মিনাল মুছা বা রিমোট ওয়াইপ করে টার্মিনালের কপি ব্যবহারযোগ্য নয় করুন (সার্ভিস পাশের অ্যাকাউন্ট সেটিংসে সেই পাসকি মুছলে সব ডিভাইসের কপি একসঙ্গে অকার্যকর হয়)। ডিভাইস-বাউন্ড হলে সার্ভিস পাশে সেই অথেন্টিকেটরের পাসকি মুছলে শুধু হারানো কী অকার্যকর হয়। সংস্থায় ব্যবহার করলে «ব্যবহারকারী নিজে পুনরুদ্ধার করতে পারেন এমন দ্বৈতকরণ» ও «হারালে প্রশাসক বাতিল করার ধাপ» একসেট নকশা জরুরি।

পাসকিরও দুর্বলতা আছে?

আছে। তবে দুর্বলতার জায়গা বদলায় — এই কথাটাই সঠিক। প্রমাণীকরণ নিজে পাবলিক কী ক্রিপ্টোগ্রাফিতে শক্ত হয়, তাই আক্রমণকারী আরও দুর্বল আশপাশে যায়। স্পষ্ট করে: পাসওয়ার্ড বা SMS ইত্যাদি পুরনো উপায় পাশাপাশি থাকলে সেটাই সবচেয়ে দুর্বল লিঙ্ক থেকে যায়; অ্যাকাউন্ট পুনরুদ্ধার প্রবাহ অপব্যবহার করে আক্রমণকারীর নিজের পাসকি নিবন্ধন করানো কৌশল; সিঙ্ক টাইপে ক্লাউড অ্যাকাউন্ট নিজে দখল নতুন একক ব্যর্থতা বিন্দু হয়। আর লগইনের পর সেশন কুকি চুরির আক্রমণ পাসকি ঠেকায় না, তাই অপ্রাসঙ্গিক হুমকি মিলিয়ে যায় না। বসানোর সময় «পাসকি যোগ» ছাড়াও পুনরুদ্ধার প্রবাহ শক্ত করা ও ফলব্যাক উপায় পরিকল্পিত ছোট করা পর্যন্ত নকশা লাগে।

লেখকের প্রোফাইল

নিবন্ধের লেখকের পরিচিতি পৃষ্ঠা।

Go Komura

KomuraSoft LLC-এর প্রতিনিধি

Windows সফটওয়্যার ডেভেলপমেন্ট, প্রযুক্তিগত পরামর্শ ও বাগ তদন্তে বিশেষজ্ঞ, বিশেষ করে বিদ্যমান সিস্টেমযুক্ত প্রকল্প ও পুনরুৎপাদন করা কঠিন বাগে।