পাসওয়ার্ড আর SMS কোড বারবার ফিশিংয়ে ধরা পড়ে। জানুন passkey কীভাবে কাজ করে, কারা আগে সুইচ করবেন, আর ফোন হারালে, কাউন্টারের শেয়ার করা ডিভাইসে, কন্ট্রাক্টরদের জন্য এবং ফলব্যাক সাইন-ইনে কী করবেন।
Author
Anichur Rahaman
বেতনের দিন সকাল ৮টা ৫০। ৪০ জনের একটা কোম্পানির ফাইন্যান্স প্রধান sign-in করতে পারছেন না, অথচ দুপুর ১২টার মধ্যে ৩৬ জনের বেতনের রান অনুমোদন করতে হবে। আগের রাতে ট্যাক্সিতে তাঁর ফোন পড়ে গেছে।
account reset করতে পারেন একজনই: চ্যাটে পাওয়া যায় এমন একজন আইটি contractor। তাঁর কাছে যে-ই ওই কর্মকর্তার নাম আর বিশ্বাসযোগ্য একটা গল্প নিয়ে হাজির হবে, দশ মিনিটে সে reset পেয়ে যাবে। দৃশ্যটা কাল্পনিক, কিন্তু প্রতিটা কোম্পানিতেই এই মুহূর্ত আসে।
Passkey চুরি-যাওয়া password-র ঝুঁকি গোড়া থেকেই সরিয়ে দেয়, কিন্তু আসলে কতটা সুরক্ষা মিলবে তা নির্ভর করে recovery-র পথ কতটা শক্ত তার ওপর। ব্যবসায় সাইবার হামলার বেশিরভাগই শুরু হয় জটিল হ্যাকিং দিয়ে নয়, একটা login দিয়ে: phishing পেজে লেখা password, কিংবা পাঁচ বছর আগে কোনো ফোরামে ব্যবহার করা password।
Passkey এখন Apple, Google ও Microsoft-এর ফোন, ল্যাপটপ আর browser-এই তৈরি করা আছে, তাই প্রযুক্তি আর কঠিন অংশ নয়। কঠিন অংশ rollout: কারা আগে শুরু করবে, ফোন হারালে কী হবে, কাউন্টারের শেয়ার করা ট্যাবলেটের কী ব্যবস্থা হবে। এই লেখায় সহজ ভাষায় passkey বুঝিয়ে দিচ্ছি, সঙ্গে দিচ্ছি ভূমিকা (role) ধরে ধরে একটা বাস্তব পরিকল্পনা, আর recovery ও fallback-এর সেই নিয়মগুলো, যেগুলো বেশিরভাগ গাইডে বাদ পড়ে যায়।
Password-র ব্যর্থতার কারণ মানবিক। ডজন ডজন শক্ত আর আলাদা password কারও মনে থাকে না, তাই সবাই একই password ঘুরিয়ে-ফিরিয়ে ব্যবহার করে। একটা সাইট ফাঁস হলেই আক্রমণকারী একই email-password অন্য সব জায়গায় চেষ্টা করে। একে বলে credential stuffing। এতে দক্ষতা লাগে না, লাগে শুধু একটা তালিকা আর একটা স্ক্রিপ্ট।
পরিসংখ্যানও এ কথাই বলে। Verizon-এর ২০২৫ সালের Data Breach Investigations Report অনুযায়ী ২২% data ফাঁসে আক্রমণকারী ঢুকেছে চুরি-যাওয়া credential দিয়ে, যা সবচেয়ে বড় পথ; তার পরে আছে ভাঙা দুর্বলতা কাজে লাগানো (২০%) আর ফিশিং (১৬%)। ২০২৬ সালের সংস্করণে প্রতিবেদনের ১৯ বছরের ইতিহাসে প্রথমবার দুর্বলতা কাজে লাগানো এক নম্বরে উঠে এসেছে। তবু credential-এর গুরুত্ব কমেনি: প্রথম ঢোকার পর system-এর ভেতরে ঘুরে দামি data-য় পৌঁছাতে আক্রমণকারীরা এগুলোই ব্যবহার করে।
ওয়ান-টাইম কোড যোগ করলে সুরক্ষা বাড়ে, কিন্তু অনেকে যতটা ভাবেন ততটা নয়:
তিনটারই দুর্বলতা এক: ব্যবহারকারীর হাতে এমন কিছু আছে যা ভুলিয়ে-ভালিয়ে আদায় করা যায়। Passkey সেই জিনিসটাই সরিয়ে দেয়।
Passkey হলো এক জোড়া cryptographic key, যা কোনো সাইটে register করার সময় তৈরি হয়। Private key আপনার device-এই থাকে, কখনো বাইরে যায় না। Public key জমা থাকে বিজনেস app-এ। Sign-in করতে গেলে app একটা এককালীন challenge পাঠায়, আপনি fingerprint, face বা screen PIN দিয়ে device আনলক করলে device-টা সেটায় সই করে দেয়, আর app public key দিয়ে সইটা মিলিয়ে নেয়।
এর পেছনের standard হলো WebAuthn (browser-এর অংশ) আর FIDO2, তাই দুটো নামই চোখে পড়বে। চালু করতে খুঁটিনাটি জানা জরুরি নয়, তবে দুটো বৈশিষ্ট্য জেনে রাখলে বোঝা যায় কেন এটা এত কাজের।
একটা passkey তৈরি হয় নির্দিষ্ট একটা সাইটের ঠিকানার জন্য, আর browser সেটা শুধু ওই ঠিকানাতেই দেখায়। নকল domain দেখতে যত হুবহু আসলের মতোই হোক, সেখানে মেলানোর মতো কোনো passkey-ই নেই, ফলে লেখার মতো কিছু নেই, চুরি করারও কিছু নেই। "Phishing-resistant" বলতে এটাই বোঝায়: নকল চিনে ফেলার দায়িত্ব ব্যবহারকারীর ওপর থাকে না।
Server-এর হাতে এমন কিছু থাকে না যা আক্রমণকারীর কাজে লাগে। বিজনেস app-এর database ফাঁস হলেও পাওয়া যাবে শুধু public key, যা একা কোনো কাজের নয়। তুলনা করুন ফাঁস হওয়া password টেবিলের সঙ্গে, যা অন্য সব জায়গায় credential stuffing-এর শুরুর পুঁজি হয়ে যায়।
Passkey দুই ধরনের, আর পলিসি ঠিক করার সময় পার্থক্যটা কাজে লাগে।
| ধরন | Key কোথায় থাকে | শক্তি | দুর্বল জায়গা |
|---|---|---|---|
| Synced passkey | Platform account বা password manager-এ, ব্যক্তির নিজের device-গুলোতে copy হয় | চালু করা সহজ, ফোন হারালেও থেকে যায় | যে account-এ sync হয়, সেটা যতটা নিরাপদ ততটাই |
| Device-bound passkey | একটাই physical device-এ, যেমন hardware security key | Key copy বা export করা যায় না | Device হারালে backup লাগে |
বেশিরভাগ কর্মীর জন্য synced passkey-ই বাস্তবসম্মত, কারণ আলাদা কিছু বয়ে বেড়াতে হয় না। Admin আর যাঁরা payment অনুমোদন করতে পারেন, তাঁদের জন্য device-bound key সামান্য খরচের হলেও সার্থক: একজনের জন্য দুটো hardware key কেনার খরচ একটা জালিয়াতির payment-র তুলনায় নগণ্য।
আপনি আগেভাগে শুরু করছেন না। এই standard-র রক্ষণাবেক্ষণকারী সংস্থা FIDO Alliance ২০২৫ সালের অক্টোবরে একটি Passkey Index প্রকাশ করেছে, যেখানে Amazon, Google, Microsoft ও PayPal-সহ নয়টি বড় service-র sign-in data ব্যবহার হয়েছে। তাতে দেখা গেছে, passkey দিয়ে sign-in-এ সফলতার হার ৯৩%, অন্য পদ্ধতিতে ৬৩%; গড় sign-in-এর সময় ৮.৫ সেকেন্ড, অন্য পদ্ধতিতে ৩১.২ সেকেন্ড; আর যারা passkey চালু করেছে তাদের login-সংক্রান্ত helpdesk ঘটনা কমেছে ৮১%। এগুলো বড় consumer service-র সংখ্যা, তাই আপনার দলের জন্য এটাকে নিশ্চয়তা নয়, দিকনির্দেশ হিসেবে দেখুন। তবে দিকটা পরিষ্কার: passkey একই সঙ্গে বেশি নিরাপদ আর বেশি সহজ, যা security-র জগতে বিরল।
কোম্পানির ভেতরে এটাই আপনার সবচেয়ে জোরালো যুক্তি। এখন যা ব্যবহার হয় তার চেয়ে দ্রুত হলে মানুষ নিজেই নতুন পদ্ধতিটা নেবে।
এক সোমবারে সবাইকে একসঙ্গে সুইচ করাবেন না। যেখানে ক্ষতি সবচেয়ে বেশি হতো, সেখান থেকে শুরু করুন, ছোট দল থেকে শিখুন, তারপর ছড়িয়ে দিন।
এই account-গুলো দাম বদলাতে, customer data export করতে, refund অনুমোদন করতে আর ব্যাংকের তথ্য পাল্টাতে পারে। এখানে passkey বাধ্যতামূলক করুন, প্রত্যেকের জন্য দুটো করে register করান (যেমন ল্যাপটপ আর একটা hardware key), recovery code অফলাইনে রাখুন, আর এই role-গুলোর জন্য SMS code বন্ধ করে দিন।
পরের sign-in-েই passkey চান, backup হিসেবে authenticator app রাখুন, আর ২০ মিনিটের একটা help session করুন। প্রতি সপ্তাহে কতজন enroll করলেন তা মাপুন। "৭৪% হয়ে গেছে" লেখা একটা সংখ্যা চোখে পড়লে মানুষ কাজটা শেষ করার তাগিদ পায়।
এই ধাপের জন্য আলাদা নিয়ম লাগে, তাই পরের অংশে এটা আলাদাভাবে দেখানো হয়েছে।
স্বাভাবিক sign-in-এর পর account page-এ এক ট্যাপের একটা option হিসেবে passkey দেখান। Fallback হিসেবে email-link বা password রাখুন, আর checkout-এর মাঝখানে কখনো নতুন পদ্ধতি চাপিয়ে দেবেন না। যিনি টাকা দিতে এসেছেন, তাঁর সামনে নতুন login পদ্ধতি এসে দাঁড়ানো উচিত নয়।
Passkey একজন মানুষকে চেনায়। কাউন্টারের shared device ব্যবহার করে যে shift-এ থাকে সে। এই দুটো বাস্তবতা ঘুরপথে নয়, সরাসরি সামলাতে হবে।
শুরুর আগে একটা প্রশ্নের উত্তর লিখে ঠিক করে ফেলুন: "কেউ ফোন হারালে কী হবে?" নিচের ছবিতে পুরো নীতিটা এক নজরে দেখানো হলো।
Recovery-র পথটাকে security-র অংশ ভাবুন, পাশের দরজা নয়। দুর্বল reset প্রক্রিয়া থাকলে সবচেয়ে শক্ত passkey-ও reset প্রক্রিয়ার সমানই শক্ত।
কিছুদিন fallback রাখতেই হবে। শক্তি অনুযায়ী সাজান এবং সবচেয়ে দুর্বলটা আগে তুলে দিন: passkey, তারপর authenticator app (সময়ভিত্তিক code), তারপর email link, আর সবার শেষে SMS। SMS না থাকার চেয়ে ভালো, কিন্তু গুরুত্বপূর্ণ যে কারও জন্য এটাই সবার আগে সরানোর পদ্ধতি।
| Role | প্রাথমিক sign-in | Backup | কখনোই অনুমোদিত নয় |
|---|---|---|---|
| Admin | Passkey, hardware key পছন্দনীয় | দ্বিতীয় passkey আর offline recovery code | SMS code, shared login |
| Finance ও payroll | Passkey, hardware key পছন্দনীয় | Authenticator app | SMS code |
| কর্মী | Synced passkey | Authenticator app | Shared login |
| Counter ও POS | Hardware key, অথবা lock করা device-এ ব্যক্তিগত PIN | Supervisor override, log সহ | পুরো shift-এর জন্য একটাই account |
| Contractor | মেয়াদি account-এ passkey | Authenticator app | ধার করা staff account |
| Customer | Optional passkey | Email link বা password | Checkout-এ forced enrolment |
আপনার software যা enforce করতে পারে, rollout ততটাই কার্যকর। শুরুর আগে দেখে নিন আপনার ERP, shop admin আর POS নিচের কাজগুলো পারে কি না:
কিছু platform এসব আগে থেকেই দেয়। যেমন StoreConsole-এ admin-রা passkey register করতে ও two-step sign-in enforce করতে পারেন। যেটাই ব্যবহার করুন, অন্য কাউকে launch করানোর আগে recovery flow নিজে একবার পরীক্ষা করে দেখুন।
প্রযুক্তিগত পটভূমি আর যেসব সার্ভিস ইতোমধ্যে passkey সাপোর্ট করে তার তালিকার জন্য FIDO Alliance-এর passkey পেজ একটা নিরপেক্ষ ভালো শুরু। Verizon-এর report-টি পাবেন Verizon-এর DBIR পেজে।
বেতনের দিনের সেই সকালে ফিরে আসি। দুটো passkey register করা থাকায় finance প্রধান ৮টা ৫৫-এ ল্যাপটপ থেকে sign in করে হারানো ফোনটা তালিকা থেকে সরিয়ে দেন। শুধু ফোনই থাকলে contractor এককালীন code দেওয়ার আগে video call আর manager-র অনুমোদন চাইতেন, আর চ্যাটে আসা অচেনা লোকটা কিছুই পেত না। দুপুর ১২টায় বেতনের রান চলে যায়, আর audit log-এ প্রতিটি ধাপ লেখা থাকে।
আনিছুর রহমান একজন সফটওয়্যার আর্কিটেক্ট এবং StoreConsole-এর নির্মাতা। বাড়তে থাকা ব্যবসার জন্য তিনি কমার্স ও ERP সিস্টেম ডিজাইন করেন — বিশেষ মনোযোগ event-driven আর্কিটেকচার, ডেটার নির্ভুলতা আর নিজের সার্ভারে চালানো সিস্টেমের ওপর।
About the Author
Anichur Rahaman
Continue Reading
