Passkey কী এবং Password-এর চেয়ে কেন আলাদা

প্রতিটি অ্যাকাউন্টের জন্য আলাদা ও শক্তিশালী Password রাখা নিরাপদ, কিন্তু বাস্তবে তা মনে রাখা কঠিন। Password manager এই চাপ কমাতে পারে, তবু নকল login page-এ ভুল করে Password লিখে দিলে phishing-এর ঝুঁকি থেকেই যায়।

Passkey কী—এই প্রশ্নের সংক্ষিপ্ত উত্তর হলো, এটি Password-এর বিকল্প একটি cryptographic credential। এখানে ব্যবহারকারীকে এমন কোনো গোপন Password মনে রাখতে বা সার্ভারে পাঠাতে হয় না। সাধারণত ফোন বা কম্পিউটার আনলক করার পরিচিত পদ্ধতি—যেমন fingerprint, Face ID, অন্য biometric verification বা device PIN—ব্যবহার করে Passkey ব্যবহারের অনুমতি দেওয়া হয়।

Passkey FIDO2/WebAuthn-ভিত্তিক public-key cryptography ব্যবহার করে। প্রতিটি credential নির্দিষ্ট সেবা বা domain-এর সঙ্গে যুক্ত থাকে। এ কারণে Password phishing এবং চুরি হওয়া Password পুনর্ব্যবহারের ওপর নির্ভরশীল অনেক আক্রমণের বিরুদ্ধে এটি প্রচলিত Password-এর তুলনায় শক্তিশালী সুরক্ষা দিতে পারে।

তবে Passkey চালু করলেই কোনো অ্যাকাউন্টের পুরোনো Password বা recovery option স্বয়ংক্রিয়ভাবে মুছে যাবে—এমন নয়। কোনো সেবা Passkey-কে মূল login method, বিকল্প sign-in পদ্ধতি বা অন্য authentication flow-এর অংশ হিসেবে ব্যবহার করতে পারে।

Passkey আসলে কী?

Password ব্যবস্থায় ব্যবহারকারী একটি গোপন তথ্যের ওপর নির্ভর করেন। নিরাপদ Password system-এ সার্ভার সাধারণত Password-এর salted hash সংরক্ষণ করে।

Passkey-এর কাঠামো ভিন্ন। একটি Passkey তৈরির সময় পরস্পর সম্পর্কিত দুটি cryptographic key ব্যবহৃত হয়:

• Private key: ব্যবহারকারীর authenticator বা credential provider-এর মাধ্যমে নিয়ন্ত্রিত হয়।
• Public key: সংশ্লিষ্ট ওয়েবসাইট বা সেবার কাছে নিবন্ধিত থাকে।

Login-এর সময় private key সেবাটির কাছে পাঠানোর দরকার হয় না। সার্ভার একটি challenge পাঠায়। Authenticator private key ব্যবহার করে সেই challenge-এর জন্য cryptographic signature তৈরি করে এবং সার্ভার আগে সংরক্ষিত public key দিয়ে সেটি যাচাই করে।

এ কারণেই কোনো সেবার Passkey database ফাঁস হলে সেখানে থাকা public key ব্যবহারকারীর private authentication key-এর বিকল্প হয়ে যায় না। অর্থাৎ public key ফাঁস হওয়া Password ফাঁস হওয়ার সমতুল্য নয়।

আরও পড়ুনঃ Password Manager ব্যবহার নিরাপদ কি: সাধারণ ব্যবহারকারীর বাস্তব প্রশ্নের উত্তর

Passkey কীভাবে কাজ করে?

ধরা যাক, কোনো ওয়েবসাইটে আপনার অ্যাকাউন্ট আছে এবং সেখানে Passkey তৈরির সুবিধা দেওয়া হয়েছে।

Passkey তৈরির আগে সেবাটি আপনার পরিচয় যাচাই করবে। এরপর অনুমতি দিলে authenticator ওই সেবার জন্য একটি key pair তৈরি করে। Public key সেবাটির কাছে নিবন্ধিত হয়, আর private key ব্যবহারকারীর authenticator বা নির্বাচিত credential-management ব্যবস্থার অধীনে থাকে।

প্রতিটি Passkey নির্দিষ্ট relying party বা service domain-এর সঙ্গে cryptographically যুক্ত। ফলে একটি সেবার জন্য তৈরি credential অন্য কোনো domain-এ একইভাবে ব্যবহার করা যায় না।

পরেরবার Login করার সময় সেবাটি Passkey authentication শুরু করলে authenticator সাধারণত ব্যবহারকারীকে নিজের উপস্থিতি বা পরিচয় নিশ্চিত করতে বলে। পদ্ধতিটি হতে পারে:

• fingerprint
• Face ID বা অন্য biometric verification
• device PIN বা passcode
• platform-এর অনুমোদিত screen-lock ব্যবস্থা

যাচাই শেষ হলে authenticator private key ব্যবহার করে সেবার challenge-এর জন্য signature তৈরি করে। সার্ভার public key দিয়ে সেটি যাচাই করে।

একটি বিষয় এখানে প্রায়ই ভুল বোঝা হয়: আঙুলের ছাপ বা মুখের তথ্য নিজে Passkey নয়। এগুলো সাধারণত Passkey ব্যবহারের স্থানীয় অনুমোদন পদ্ধতি। Biometric verification ব্যবহৃত হলে সেই biometric data স্বাভাবিক Passkey authentication-এর অংশ হিসেবে সংশ্লিষ্ট ওয়েবসাইটে পাঠানোর কথা নয়।

Passkey বনাম Password: পার্থক্য কোথায়?

দুটির লক্ষ্যই ব্যবহারকারীর পরিচয় যাচাই করা, কিন্তু নিরাপত্তার ভিত্তি এক নয়।

Credential stuffing-এর ক্ষেত্রে একটি শর্ত মনে রাখা দরকার। Passkey নিজে reused Password secret নয়, তাই প্রচলিত Password credential stuffing এর বিরুদ্ধে কার্যকর নয়। কিন্তু কোনো অ্যাকাউন্টে Password fallback চালু থাকলে সেই Password এখনও আক্রমণের লক্ষ্য হতে পারে।

অর্থাৎ Passkey সক্রিয় করেও দুর্বল বা পুনর্ব্যবহৃত fallback Password রেখে দিলে সেই আলাদা ঝুঁকি থেকে যায়।

Phishing-এর বিরুদ্ধে Passkey কেন বেশি কার্যকর

Password phishing-এ আক্রমণকারী সাধারণত আসল ওয়েবসাইটের মতো দেখতে একটি নকল page তৈরি করে। ব্যবহারকারী সেখানে Password বা কিছু ধরনের verification code দিলে attacker সেটি আসল সেবায় ব্যবহার করার চেষ্টা করতে পারে।

WebAuthn credential service domain-এর পরিচয়ের সঙ্গে cryptographically যুক্ত থাকে। NIST WebAuthn-কে verifier name binding ব্যবহারকারী phishing-resistant authentication protocol-এর উদাহরণ হিসেবে উল্লেখ করেছে।

ধরা যাক, আক্রমণকারী আসল সাইটের কাছাকাছি নামের অন্য domain-এ নকল login page তৈরি করল। বৈধ সেবার জন্য তৈরি WebAuthn credential সাধারণ অবস্থায় সেই ভিন্ন domain-এর authentication request-এ ব্যবহার হওয়ার কথা নয়।

এখানেই Passkey-এর বড় নিরাপত্তাগত পার্থক্য। Password-এর ক্ষেত্রে ব্যবহারকারী ভুল সাইটে নিজেই secret লিখে দিতে পারেন। Passkey-তে authentication credential কোন সেবার জন্য ব্যবহারযোগ্য, তার সঙ্গে domain-এর cryptographic সম্পর্ক থাকে।

তবু Passkey সব ধরনের প্রতারণা ঠেকায় না। ভুয়া account-recovery call, remote-access scam, device unlock code হাতিয়ে নেওয়া বা অন্য social engineering পদ্ধতি এখনও ঝুঁকি তৈরি করতে পারে। তাই Passkey চালু করলেও [ফিশিং আক্রমণ প্রতিরোধের উপায়] সম্পর্কে সাধারণ সতর্কতা জরুরি।

Passkey কোথায় সংরক্ষিত থাকে?

সব Passkey একইভাবে পরিচালিত হয় না। ব্যবহারকারীর দৃষ্টিতে দুটি ধরন বোঝা সুবিধাজনক।

Synced Passkey

একটি credential manager বা sync service-এর মাধ্যমে Passkey একাধিক অনুমোদিত ডিভাইসে ব্যবহারযোগ্য হতে পারে।

Apple-এর iCloud Keychain Password ও Passkey অনুমোদিত Apple ডিভাইসগুলোর মধ্যে sync করতে পারে। Google Password Manager-ও সমর্থিত পরিবেশে Passkey sync করার সুবিধা দেয়। Microsoft-এর ব্যবস্থাতেও synced credential manager ব্যবহার করা যায়।

নতুন ডিভাইসে Passkey ফিরে পাওয়ার প্রক্রিয়া সংশ্লিষ্ট provider-এর account recovery, sync এবং security policy-এর ওপর নির্ভর করে। তাই “synced” মানে যেকোনো নতুন ডিভাইসে কোনো অতিরিক্ত যাচাই ছাড়াই credential চলে আসবে—এমন ধরে নেওয়া ঠিক নয়।

Device-bound Passkey

Device-bound credential নির্দিষ্ট authenticator বা ডিভাইসের সঙ্গে থাকে এবং সাধারণ synced Passkey-এর মতো cloud sync-এর মাধ্যমে অন্য ডিভাইসে ছড়ায় না।

উচ্চ assurance-এর পরিবেশে এই পার্থক্য গুরুত্বপূর্ণ। NIST SP 800-63B Revision 4 অনুযায়ী syncable authenticator AAL2 পর্যন্ত ব্যবহারযোগ্য হতে পারে। AAL3-তে phishing-resistant authenticator-এর authentication key non-exportable হতে হয়।

সাধারণ ব্যক্তিগত অ্যাকাউন্টের ক্ষেত্রে অবশ্য AAL3-স্তরের ব্যবস্থা প্রয়োজন হবে—এমন নয়।

অন্য কম্পিউটারে নিজের ফোনের Passkey ব্যবহার করা যায়

সমর্থিত platform ও service-এ নিজের ফোনে থাকা Passkey ব্যবহার করে অন্য কম্পিউটারেও sign-in করা যায়।

Login করার সময় “Passkey from nearby device”, “Use another device” বা কাছাকাছি কোনো option দেখা যেতে পারে। এরপর কম্পিউটারে একটি QR code দেখানো হয়। সেটি ফোন দিয়ে scan করে ফোনেই authentication সম্পন্ন করা যায়।

Platform ও implementation অনুযায়ী কাছাকাছি থাকা ডিভাইস নিশ্চিত করতে Bluetooth চালু রাখার প্রয়োজন হতে পারে।

পাবলিক বা ধার করা কম্পিউটারে এখানে একটি ব্যবহারিক নিয়ম মানা ভালো: অন্যের ডিভাইসে নিজের স্থায়ী Passkey তৈরি না করে, support থাকলে নিজের ফোনে থাকা Passkey দিয়ে cross-device sign-in করুন। Google-ও ব্যক্তিগত মালিকানাধীন ডিভাইসে Passkey তৈরির পরামর্শ দেয়।

Passkey কি 2FA-এর বিকল্প?

কিছু ক্ষেত্রে পারে, কিন্তু প্রতিটি Passkey-কে সরাসরি 2FA বলা ঠিক নয়।

Passkey authentication-এ authenticator-এর দখল এবং PIN বা biometric-এর মতো local user verification একসঙ্গে ব্যবহৃত হলে একাধিক authentication factor যুক্ত হতে পারে। NIST-এর guidance-এ user verification-সহ WebAuthn authenticator কীভাবে AAL2-এর multi-factor requirement পূরণ করতে পারে, তার ব্যাখ্যা রয়েছে।

তবে একটি নির্দিষ্ট Passkey transaction single-factor নাকি multi-factor হিসেবে গণ্য হবে, তা authenticator, user-verification configuration এবং সংশ্লিষ্ট সেবার policy-এর ওপর নির্ভর করতে পারে।

Google Account-এ Passkey দিয়ে sign-in করলে 2-Step Verification-এর আলাদা দ্বিতীয় ধাপ এড়িয়ে যাওয়া যেতে পারে। Passkey যোগ করলেও Google Account-এর বিদ্যমান authentication বা recovery factor স্বয়ংক্রিয়ভাবে মুছে যায় না।

Microsoft নিজের Passkey implementation-কে multi-factor authentication হিসেবে বর্ণনা করে, যেখানে credential থাকা device এবং সেটি biometric বা PIN দিয়ে unlock করার বিষয়টি একসঙ্গে ব্যবহৃত হয়।

তাই [টু-ফ্যাক্টর অথেন্টিকেশন (2FA) কী] এবং Passkey-কে সব পরিস্থিতিতে একই জিনিস ধরে নেওয়া উচিত নয়।

Passkey ব্যবহার করলে বাস্তবে কী বদলায়?

প্রথম পরিবর্তনটি Password মনে রাখার ঝামেলায়। Passkey-enabled প্রতিটি সেবার জন্য নতুন Password মুখস্থ করার দরকার পড়ে না।

Password reuse-এর সমস্যাও Passkey credential-এ থাকে না। একটি service-এর জন্য তৈরি cryptographic credential অন্য service-এর Password হিসেবে পুনর্ব্যবহার করা যায় না।

Server breach-এর ক্ষেত্রেও ঝুঁকির ধরন আলাদা। Passkey authentication-এ service provider public key রাখে; authentication-এর private key Password-এর মতো shared secret হিসেবে server-এ জমা থাকার কথা নয়।

সবচেয়ে গুরুত্বপূর্ণ পার্থক্যটি phishing resistance-এ। Properly configured WebAuthn credential service domain-এর সঙ্গে bound থাকে, ফলে Password-এর মতো secret নকল site-এ লিখে দেওয়ার পরিস্থিতি তৈরি হয় না।

ব্যবহারকারীর জন্য sign-in-ও সহজ হতে পারে। অনেক ক্ষেত্রে ফোন বা কম্পিউটার আনলক করার পরিচিত verification flow-তেই Login শেষ হয়।

তবে এখান থেকে “শক্তিশালী Password আর দরকার নেই” সিদ্ধান্তে যাওয়া ঠিক হবে না। যেসব account-এ Password fallback আছে বা Passkey support নেই, সেখানে [শক্তিশালী পাসওয়ার্ড তৈরির কৌশল] এখনও প্রাসঙ্গিক।

যে সীমাবদ্ধতাগুলো সিদ্ধান্তে প্রভাব ফেলতে পারে

প্রধান browser ও operating system ecosystem-এ Passkey support থাকলেও প্রতিটি website বা app একইভাবে এটি বাস্তবায়ন করে না। কোথাও Passkey primary sign-in method, কোথাও Password-এর বিকল্প, আবার কোথাও পুরোনো authentication method পাশাপাশি থাকে।

Account recovery-ও provider-ভেদে আলাদা। ফোন হারালে synced Passkey সবসময় হারিয়ে যাবে—এটি ঠিক নয়। আবার নতুন ডিভাইসে credential ফিরে পাওয়ার পথও সব provider-এর ক্ষেত্রে এক নয়। Credential provider account, registered authenticator, recovery method এবং sync architecture এখানে গুরুত্বপূর্ণ।

ডিভাইসের নিরাপত্তা তাই Passkey ব্যবস্থার অংশ। Google ব্যক্তিগত মালিকানাধীন ডিভাইসেই Google Account Passkey তৈরির পরামর্শ দেয়। কেউ যদি সেই ডিভাইস unlock করতে পারেন, সংশ্লিষ্ট account-এ প্রবেশের সুযোগ তৈরি হতে পারে।

Passkey চালু করে দুর্বল device PIN রেখে দিলে তাই পুরো নিরাপত্তা ব্যবস্থাই দুর্বল হতে পারে। শক্তিশালী PIN বা passcode, biometric protection এবং screen lock বজায় রাখা জরুরি।

আরেকটি বাস্তব সীমাবদ্ধতা হলো provider বদলানো। Passkey ও অন্যান্য credential এক provider থেকে অন্য provider-এ স্থানান্তরের জন্য FIDO Alliance standardization নিয়ে কাজ করছে। ২৮ আগস্ট ২০২৬ পর্যন্ত Credential Exchange Format (CXF) 1.0-এর status Proposed Standard এবং Credential Exchange Protocol-এর status Working Draft।

ফলে এক credential manager বা ecosystem থেকে অন্যটিতে Passkey স্থানান্তরের অভিজ্ঞতা এখনও provider ও platform অনুযায়ী ভিন্ন হতে পারে। যারা একসঙ্গে Android, iPhone, Windows বা একাধিক credential manager ব্যবহার করেন, তাদের জন্য এই বিষয়টি বেশি গুরুত্বপূর্ণ।

Passkey চালু করার আগে তিনটি বিষয় দেখুন

সব account একদিনে বদলানোর দরকার নেই। প্রধান email বা identity account দিয়ে শুরু করাই বেশির ভাগ ব্যবহারকারীর জন্য বাস্তবসম্মত।

Passkey support থাকলে নিজের ব্যক্তিগত, আপডেটেড এবং screen lock-সুরক্ষিত device-এ সেটি তৈরি করুন। তারপর নিশ্চিত হয়ে নিন:

• account recovery কীভাবে হবে;
• হারানো device-এর Passkey কীভাবে remove বা revoke করবেন;
• প্রধান authenticator হাতে না থাকলে বিকল্প নিরাপদ sign-in method কী।

Google Account-এ হারানো device-এর Passkey account settings থেকে সরানোর ব্যবস্থা রয়েছে।

Device-bound credential ব্যবহার করলে বিকল্প authenticator বা recovery route রাখা আরও গুরুত্বপূর্ণ হয়ে উঠতে পারে। NIST-ও authenticator হারানোর পরিস্থিতি সামলাতে একাধিক পৃথক authentication method রাখার পরামর্শ দেয়।

শেয়ার করা কম্পিউটার বা অন্যের ফোনে গুরুত্বপূর্ণ account-এর স্থায়ী Passkey তৈরি না করাই নিরাপদ সম্পাদকীয় সুপারিশ।

Password কি তাহলে অপ্রয়োজনীয় হয়ে যাচ্ছে?

Passkey Password ছাড়াই authentication সম্ভব করতে পারে। বাস্তবে অবশ্য Password থেকে রূপান্তরটি ধাপে ধাপে হচ্ছে।

একটি service Passkey support করলেও Password, recovery code বা অন্য fallback method রেখে দিতে পারে। Google Account-এ Passkey যোগ করলে বিদ্যমান authentication এবং recovery factor স্বয়ংক্রিয়ভাবে মুছে যায় না।

তাই “পাসওয়ার্ডহীন ভবিষ্যৎ” বলতে এখনই সব Password মুছে ফেলা বোঝানো ঠিক হবে না। যেখানে নির্ভরযোগ্য Passkey support আছে, সেখানে দৈনন্দিন Login-এর জন্য Password-এর ওপর নির্ভরতা কমানোই বেশি বাস্তবসম্মত লক্ষ্য।

শেষ কথা

Passkey কী—এর ব্যবহারিক উত্তর হলো, এটি মনে রাখার মতো আরেক ধরনের Password নয়। Shared Password secret-এর বদলে public-key cryptography ব্যবহার করে পরিচয় যাচাই করাই এর মূল পার্থক্য।

প্রধান email, identity account বা নিয়মিত ব্যবহৃত গুরুত্বপূর্ণ কোনো service Passkey support করলে নিজের ব্যক্তিগত ও সুরক্ষিত ডিভাইসে সেটি সক্রিয় করা যৌক্তিক প্রথম পদক্ষেপ। তবে আগে recovery option এবং হারানো authenticator সরানোর প্রক্রিয়া জেনে নিন।

Passkey Password phishing ও Password reuse-নির্ভর অনেক ঝুঁকি কমাতে পারে। কিন্তু নিরাপদ device lock, ভালো account recovery এবং social engineering সম্পর্কে সচেতনতা—এই তিনটি এখনও সমানভাবে প্রয়োজনীয়।

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

১. Passkey কি Password-এর চেয়ে বেশি নিরাপদ?

সাধারণভাবে, সঠিকভাবে বাস্তবায়িত Passkey phishing এবং password reuse-নির্ভর আক্রমণের বিরুদ্ধে বেশি শক্তিশালী। কারণ এতে ব্যবহারকারীর কোনো shared Password সার্ভারে পাঠাতে হয় না এবং credential নির্দিষ্ট service domain-এর সঙ্গে যুক্ত থাকে।

২. ফোন হারালে Passkey কি হারিয়ে যাবে?

সব ক্ষেত্রে নয়। Synced Passkey ব্যবহার করলে credential provider-এর recovery ও sync ব্যবস্থার মাধ্যমে নতুন ডিভাইসে Passkey ফিরে পাওয়া যেতে পারে। তবে provider ও platform অনুযায়ী recovery পদ্ধতি ভিন্ন হতে পারে।

৩. Passkey চালু করলে কি Password মুছে ফেলতে হবে?

অবশ্যই নয়। অনেক service Passkey চালু করার পরও Password বা অন্য recovery method রেখে দেয়। তাই Password সরানোর আগে account recovery এবং fallback sign-in কীভাবে কাজ করে, তা যাচাই করা উচিত।