MFA আর passkey — TOTP, FIDO2 আর phishing-প্রতিরোধী login

১ · MFA কেন কাজ করে, আর কী থামায় না

ব্যাংকের লকারের কথা ভাবুন। একটি চাবি থাকে আপনার হাতে, আরেকটি ব্যাংকের কর্মকর্তার কাছে। দুটি একসঙ্গে না ঘুরলে লকার খোলে না। আপনার চাবি হারালেও চোরের কাজ শেষ হয় না। MFA মানে multi-factor authentication. ভাবনাটি একই: একটি প্রমাণ হারালেও দরজা বন্ধ থাকবে।

পর্ব ১৩-এ দেখেছেন, password ফাঁস হয়, আর মানুষ একই password বহু জায়গায় ব্যবহার করেন। পর্ব ১৫-এ authentication-এর ভিত্তি আছে। এই পর্ব সেখান থেকে এগোয়। প্রশ্নটি হলো, password চুরি হলেও login কীভাবে আটকানো যায়?

তিন ধরনের প্রমাণ

প্রতিটি প্রমাণের ধরনকে বলে authentication factor. প্রচলিত তিন ধরন হলো:

• যা আপনি জানেন: password, PIN.
• যা আপনার কাছে আছে: ফোন, security key, OTP যন্ত্র।
• আপনি নিজে: আঙুলের ছাপ, মুখ।

দুটি password দিলে MFA হয় না, কারণ দুটিই একই ধরনের। একসঙ্গে দুটি ভিন্ন ধরনের প্রমাণ চাই। তবে শুধু ধরন গুনলে চলে না। Password আর TOTP secret একই password manager-এ রাখলে একটি জায়গা হারানোই দুটি হারানো। সুবিধা বাড়ে, পৃথকীকরণ কমে। সিদ্ধান্তটি সচেতনভাবে নিন।

শেষ সারিটি মনে রাখুন। MFA শুধু login-এর মুহূর্ত রক্ষা করে। Login শেষে যে session cookie তৈরি হয়, সেটি চুরি হলে কোনো MFA আবার জিজ্ঞেস করে না। সে আলোচনা পর্ব ১৭-এ। যন্ত্রে malware থাকলে, অথবা ব্যবহারকারী ফাঁদে পড়ে কোনো অনুমতি দিলে, কিংবা application-এ authorization-এর ভুল থাকলেও MFA সাহায্য করে না। এটি একটি স্তর, পুরো দেয়াল নয়। পর্ব ৩-এর defense in depth এখানেও খাটে।

২ · SMS আর voice OTP — মোবাইল ব্যাংকিংয়ের চেনা অভ্যাসের ঝুঁকি

বাংলাদেশে অনেকের কাছে MFA মানেই ফোনে আসা ছয় অঙ্কের OTP. মোবাইল ব্যাংকিং, কার্ডের অনলাইন লেনদেন, সরকারি সেবা, সব জায়গায় এটি পরিচিত। এর বড় গুণ হলো নাগালের বিস্তার। সাধারণ বাটন ফোনেও SMS আসে, কোনো app লাগে না। তাই এটিকে তুচ্ছ করা ভুল। কিছু না থাকার চেয়ে SMS OTP অনেক ভালো। তবে এর দুর্বলতাও জানা দরকার।

কোথায় দুর্বল

• SIM swap: কেউ প্রতারণা করে বা ভেতরের সাহায্যে আপনার নম্বর নতুন SIM-এ তুলে নেয়। এরপর OTP তার ফোনে যায়, আর আপনার ফোনের সংযোগ হঠাৎ বন্ধ হয়ে যায়।
• নম্বর পুনর্ব্যবহার: বহুদিন বন্ধ থাকা নম্বর অপারেটর আবার অন্য কাউকে দিতে পারে। পুরোনো অ্যাকাউন্টের OTP তখন নতুন মালিকের কাছে যেতে পারে।
• পথের দুর্বলতা: টেলিফোন network-এর সংকেত ব্যবস্থা পুরোনো যুগের নকশা। SMS end-to-end encrypted নয়।
• মানুষকে ঠকানো: “আপনার অ্যাকাউন্ট বন্ধ হবে, code-টি বলুন” ধরনের ফোন social engineering-এর চেনা রূপ। Voice OTP-তে একই ঝুঁকি, সঙ্গে ভয়েসমেইল আর কল ফরওয়ার্ডের প্রশ্নও আসে।
• ফোনের ভেতরের ঝুঁকি: lock screen-এ দেখা যাওয়া code, অথবা SMS পড়ার অনুমতি পাওয়া ক্ষতিকর app.

প্রতিরক্ষা: অপারেটর, সেবাদাতা আর ব্যবহারকারী

বাংলাদেশে SIM নিবন্ধনে আঙুলের ছাপের ব্যবহার একটি বড় প্রক্রিয়াগত পদক্ষেপ ছিল। ITU-সংশ্লিষ্ট আর্থিক অন্তর্ভুক্তি উদ্যোগ FIGI-র নিরাপত্তা সুপারিশেও SIM বদলের আগে biometric যাচাই আর আর্থিক সেবাদাতাকে জানানোর কথা আছে। তবে নিয়ম আর চর্চা সময়ের সঙ্গে বদলায়। আপনার সেবার জন্য বর্তমান নিয়ম নিয়ন্ত্রকের সরকারি উৎসে দেখে নিন। কোনো প্রক্রিয়াই শতভাগ নয়, কারণ ভুল আর ভেতরের সহায়তা থেকেই যায়।

NIST-এর অবস্থানও শিক্ষণীয়। SP 800-63B-4 (২০২৫) phone network দিয়ে OTP পাঠানোকে restricted বলে। অর্থাৎ চলতে পারে, তবে ঝুঁকি বিবেচনা করতে হবে, বিকল্প দিতে হবে, ব্যবহারকারীকে ঝুঁকি জানাতে হবে, আর সরে যাওয়ার পরিকল্পনা রাখতে হবে। ঝুঁকির সংকেত হিসেবে যন্ত্র বদল, SIM বদল আর নম্বর port হওয়ার কথা সেখানে আছে। NIST মূলত মার্কিন সরকারি সংস্থার নির্দেশিকা, তবে বিশ্বজুড়ে একটি ভালো মাপকাঠি।

৩ · HOTP আর TOTP — সময় থেকে ছয় অঙ্ক

SMS-এর সমস্যা হলো code পথে চলে। তাহলে এমন ব্যবস্থা ভাবুন, যেখানে code পাঠাতেই হয় না। ফোন আর server দুজনেই নিজে নিজে একই সংখ্যা হিসাব করে। দরকার শুধু একটি অভিন্ন গোপন মান, যাকে বলে shared secret. আর দরকার এমন কিছু, যা প্রতিবার বদলায়।

HOTP (RFC 4226, ২০০৫)-এ বদলানোর মান হলো একটি counter. Button চাপলে counter বাড়ে। TOTP (RFC 6238, ২০১১)-এ counter-এর জায়গায় সময়। সূত্র দুটি হলো:

এখানে K হলো secret, আর ভেতরের যন্ত্রটি পর্ব ৯-এর HMAC. SHA-1-এর collision দুর্বলতা জানা, কিন্তু HMAC-এর নিরাপত্তা সরাসরি collision-এর ওপর নির্ভর করে না। তাই TOTP-তে SHA-1 থাকলেই code ভাঙা যায়, এমন নয়। RFC 6238 SHA-256 আর SHA-512-ও অনুমোদন করে। তবে বহু app-এ SHA-1, ছয় অঙ্ক আর ৩০ সেকেন্ডই সবচেয়ে সামঞ্জস্যপূর্ণ।

নিচের ডায়াগ্রামে RFC 6238-এর আসল test secret আর আসল সময় দিয়ে একটি code তৈরি হবে। প্রতিটি মান script চালিয়ে পাওয়া। “পরে” চেপে এগোন।

ASCII : 12345678901234567890  (20 byte)
Base32: GEZDGNBVGY3TQOJQ
        GEZDGNBVGY3TQOJQ

t = 1234567890
  = 2009-02-13 23:31:30 UTC

T = floor(1234567890 / 30)
  = 41152263
  = 0x273EF07

bytes: 00 00 00 00 02 73 EF 07

90 7c d1 a9 11 65 64 ec b9 d5
d1 78 03 25 f2 46 17 3f e7 03

শেষ byte = 0x03, offset = 3

90 7c d1 a9 11 65 64 ec b9 d5
index:    3  4  5  6

0xa9116564 & 0x7fffffff
= 0x29116564
= 689005924

689005924 mod 10^6 = 5924
ফোনে দেখায়: 005924

৮ অঙ্কে (RFC vector): 89005924

এবার একই হিসাব সত্যিকারের কোডে দেখুন। শুধু standard library, কোনো network নেই। কোডটি RFC 6238-এর Appendix B-র SHA-1 vector-এর সঙ্গে নিজের ফল মিলিয়ে দেখে।

import hashlib, hmac, struct

SECRET = b"12345678901234567890"   # RFC 6238 public test secret

def totp(secret, unix_time, digits=8, step=30):
    counter = unix_time // step
    msg = struct.pack(">Q", counter)            # 8 bytes, big-endian
    digest = hmac.new(secret, msg, hashlib.sha1).digest()
    offset = digest[-1] & 0x0F                  # dynamic truncation
    chunk = digest[offset:offset + 4]
    value = int.from_bytes(chunk, "big") & 0x7FFFFFFF
    return f"{value % 10**digits:0{digits}d}"

# RFC 6238 Appendix B, SHA-1 rows
VECTORS = [(59, "94287082"), (1111111109, "07081804"),
           (1111111111, "14050471"), (1234567890, "89005924"),
           (2000000000, "69279037"), (20000000000, "65353130")]

for t, expected in VECTORS:
    got = totp(SECRET, t)
    ok = hmac.compare_digest(got, expected)
    print(f"t={t:<12} got={got} rfc={expected} {'OK' if ok else 'FAIL'}")

t = 1234567890
print("6-digit codes around t:")
for shift in (-30, 0, 30):
    print(f"  T{shift // 30:+d}: {totp(SECRET, t + shift, digits=6)}")

৪ · Verifier-এর দিক — window, replay, rate limit আর secret রাখা

Code বানানো সহজ অংশ। আসল নিরাপত্তা নির্ভর করে server যেভাবে যাচাই করে তার ওপর। ঘড়ি কখনো হুবহু মেলে না, আর code টাইপ করতেও সময় লাগে। তাই server শুধু বর্তমান ধাপ নয়, আশপাশের ধাপও দেখে। একে বলে verification window. RFC 6238 network দেরির জন্য বড়জোর এক ধাপ ছাড় দেওয়ার পরামর্শ দেয়।

NIST SP 800-63B-4-এর ভাষায়, একটি OTP বৈধ থাকার সময়ে মাত্র একবার গ্রহণ করতে হবে, আর ব্যর্থ চেষ্টা সর্বোচ্চ ১০০-তে সীমিত রেখে authenticator বন্ধ করতে হবে। সংস্থা চাইলে আরও কম সীমা রাখতে পারে। নিচের simulator-এ simulated clock চলে, আর code-গুলো আগের Python block-এর একই test secret থেকে আগে হিসাব করে রাখা।

// simulated clock. আসল সময় নয়, code RFC test secret থেকে আগে হিসাব করা
const CODES = { 41152262: '980357', 41152263: '005924', 41152264: '590587',
  41152265: '240500', 41152266: '992085', 41152267: '687586' };
const STEP = 30, WINDOW = 1, MAX_FAILS = 5;
const user = { lastStep: 0, fails: 0, locked: false };

function fail(reason) {
  user.fails += 1;
  if (user.fails >= MAX_FAILS) user.locked = true;
  return `REJECT ${reason} (fails=${user.fails})`;
}
function verify(now, code) {
  if (user.locked) return 'REJECT locked, use recovery';
  const current = Math.floor(now / STEP);
  for (let w = -WINDOW; w <= WINDOW; w++) {
    const step = current + w;
    if (CODES[step] !== code) continue;   // real code: constant-time compare
    if (step <= user.lastStep) return fail('replay');
    user.lastStep = step; user.fails = 0;
    return `ACCEPT drift ${w >= 0 ? '+' : ''}${w}`;
  }
  return fail('invalid');
}
const T0 = 1234567890;
const events = [[0, '005924', 'on time'], [5, '005924', 'same code again'],
  [35, '240500', 'phone 1 step ahead'], [95, '590587', 'phone 2 steps behind'],
  [100, '240500', 'older used step'], [105, '992085', 'on time'],
  [110, '111111', 'guess'], [112, '222222', 'guess'], [114, '333333', 'guess'],
  [116, '444444', 'guess'], [118, '555555', 'guess'], [125, '687586', 'correct, late']];
for (const [dt, code, note] of events)
  console.log(`t0+${String(dt).padEnd(3)} ${code} ${note.padEnd(21)} ${verify(T0 + dt, code)}`);

হিসাব: ছয় অঙ্ক কতটা শক্ত

ধরুন window ±১, তাই একসঙ্গে ৩টি code বৈধ। ছয় অঙ্কে সম্ভাব্য মান ১০^৬টি। এক অনুমানে সাফল্যের সম্ভাবনা p = 3 / 10⁶ = 0.000003. n বার অনুমানে অন্তত একবার সফল হওয়ার সম্ভাবনা:

শিক্ষাটি পরিষ্কার। ছয় অঙ্ক নিজে শক্ত নয়। শক্তি আসে rate limit থেকে। Limit মুছে দিলে TOTP-র গণিত আপনাকে বাঁচাবে না। Limit-টি অ্যাকাউন্ট ধরে রাখতে হবে, শুধু IP ধরে নয়, আর এক session-এর বদলে সব session মিলিয়ে গুনতে হবে। RFC 4226-ও ব্যর্থ চেষ্টা সীমিত করতে বলে।

Secret রাখবেন কোথায়

পর্ব ১৩-এ password hash করে রাখা শিখেছেন। TOTP secret-এর বেলায় তা চলে না। কেন? Server-কে প্রতিবার HMAC হিসাব করতে হয়, তাই আসল secret হাতে লাগে। OTP seed তাই ফেরত পড়া যায় এমনভাবে রাখতেই হয়। করণীয় হলো application key দিয়ে encrypt করে রাখা, আর সেই key KMS বা HSM-এ আলাদা রাখা। পর্ব ১৪-এর envelope encryption এখানে ভালো খাটে। Log, backup আর analytics-এ seed যেন না যায়। Enrollment-এর পরে সেটি আর কখনো দেখানো উচিত নয়। Database আর key দুটি একসঙ্গে ফাঁস হলে কী হবে? সব ব্যবহারকারীর seed বদলাতে হবে। আগেই সেই পরিকল্পনা রাখুন।

৫ · Push approval, MFA fatigue আর number matching

Code টাইপ করা ঝামেলার। তাই এলো push approval: login করলেই ফোনে বার্তা আসে, “আপনি কি login করছেন?” একটি চাপেই কাজ শেষ। সুবিধাটি বড়। কিন্তু সেই সহজ বোতামটিই দুর্বলতা।

২০২২ সালের Uber ঘটনার প্রকাশিত বিবরণগুলোতে বারবার push পাঠিয়ে ক্লান্ত করার কথা আসে, যদিও খুঁটিনাটি নিয়ে সূত্রভেদ আছে। শিক্ষাটি নির্দিষ্ট ঘটনার চেয়ে বড়: “অনুমোদন” চাপাটি যদি চিন্তা ছাড়াই করা যায়, তাহলে মানুষ চিন্তা ছাড়াই করবেন।

প্রতিকার: Number matching

Login পর্দায় একটি ছোট সংখ্যা দেখায়, আর ব্যবহারকারীকে ফোনে সেটি টাইপ করতে হয়। পর্দার সামনে না থাকলে সংখ্যাটি জানার উপায় নেই। ফলে হঠাৎ আসা অনুরোধে অন্ধ অনুমোদন সম্ভব হয় না। CISA ২০২২ সালের অক্টোবরে এটিকে push-ভিত্তিক MFA-র অন্তর্বর্তী প্রতিকার হিসেবে সুপারিশ করে, আর প্রথম পছন্দ রাখে phishing-প্রতিরোধী MFA.

নকশার খুঁটিনাটি গুরুত্বপূর্ণ। NIST SP 800-63B-4 বলে, শুধু দুটি মান মিলিয়ে “অনুমোদন” চাপা আর যথেষ্ট নয়, কারণ মানুষ না মিলিয়েই চাপতে পারেন। কয়েকটি বিকল্পের তালিকা থেকে বাছাইও যথেষ্ট নয়। মানটি এক channel থেকে আরেকটিতে সত্যিই স্থানান্তর করতে হবে। NIST push-এর সংখ্যা বা হারও সীমিত রাখতে বলে।

Detection: কী দেখবেন

অল্প সময়ে একই ব্যবহারকারীর অনেক push প্রত্যাখ্যান, তারপর হঠাৎ একটি অনুমোদন একটি শক্ত সংকেত। ব্যবহারকারীর জন্য “এটি আমি নই” বোতাম রাখুন, যা সরাসরি SOC-তে সতর্কবার্তা পাঠাবে। নতুন authenticator যোগ হওয়ার ঘটনাও গুরুত্ব দিয়ে দেখুন। অনেক সময় অনুপ্রবেশকারী প্রথম যে কাজটি করে, তা হলো নিজের জন্য একটি পদ্ধতি যোগ করা। নিচের rule-টি Sigma ধাঁচের উদাহরণ, log-এর নামগুলো কাল্পনিক। Sigma আর correlation-এর বিস্তারিত পর্ব ৫৬-তে।

# উদাহরণ: কাল্পনিক identity log schema, আপনার নিজের system-এর জন্য বদলে নিন
title: New MFA Method Added Without Recent Step-Up
id: 6f0c2a54-7b1e-4c1d-9a3e-000000000016
status: experimental
description: A new authenticator was added without a recent strong re-check.
logsource:
  product: example_idp
  category: authentication
detection:
  selection:
    event_type: mfa.factor.added
    recent_step_up: false
  condition: selection
falsepositives:
  - First enrollment by a new employee
level: high

৬ · Real-time phishing relay আর origin binding

এতক্ষণ যা দেখলেন, সব পদ্ধতিতে একটি মিল আছে। ব্যবহারকারী নিজে একটি মান এক জায়গা থেকে পড়ে অন্য জায়গায় দেন। সেই “অন্য জায়গা” যে আসল সাইট, তা যাচাই করে শুধু তাঁর চোখ। Phishing-এ ঠিক এই চোখকেই ঠকানো হয়।

পুরোনো ধারণা ছিল, OTP ৩০ সেকেন্ডে বদলায়, তাই চুরি করে লাভ নেই। Real-time phishing relay এই ধারণা ভেঙে দিয়েছে। এটি ধারণাগতভাবে পথের মাঝে বসা একটি মধ্যস্থতাকারী (MITM-এর এক রূপ)। ব্যবহারকারী নকল পাতায় যা দেন, তা সঙ্গে সঙ্গে আসল সাইটে যায়। ৩০ সেকেন্ড অনেক লম্বা সময়। OTP একটি সাধারণ সংখ্যা, তাতে লেখা নেই সে কোন সাইটের। তাই আসল সাইট তাকে সঠিকই পায়।

Origin মানে scheme, host আর port-এর মিলিত পরিচয়, যেমন https://shop.example.com. পর্ব ৩৬-এ browser-এর দিক থেকে এটি আবার আসবে। Origin binding-এ দুটি কাজ হয় একসঙ্গে। মানুষের বদলে browser origin পড়ে, আর সেই origin স্বাক্ষরের ভেতরে চলে যায়।

NIST SP 800-63B-4 phishing resistance-কে দুই ভাবে পাওয়ার কথা বলে। Channel binding-এ authenticator-এর ফল ওই নির্দিষ্ট সংযোগের সঙ্গে বাঁধা থাকে। উদাহরণ হলো client-authenticated TLS, যা পর্ব ১২-এ mTLS নামে দেখেছেন। Verifier name binding-এ ফল যাচাইকারীর নামের সঙ্গে বাঁধা থাকে। উদাহরণ WebAuthn. নিয়মটি স্পষ্ট: যেসব পদ্ধতিতে মানুষ হাতে ফল টাইপ করেন, যেমন OTP, সেগুলো phishing-প্রতিরোধী নয়।

নিচের ডায়াগ্রামে একই নকল পাতায় দুজন ব্যবহারকারীকে পাশাপাশি দেখুন। একজন OTP ব্যবহার করেন, অন্যজন passkey.

এটি শুধু তত্ত্ব নয়। ২০২২ সালের আগস্টে Cloudflare জানায়, কর্মীদের কাছে একটি সুসংগঠিত SMS phishing প্রচারণা আসে, আর তিনজন কর্মী নকল পাতায় তথ্য দিয়ে ফেলেন। তবু login হয়নি, কারণ প্রতিষ্ঠানটি FIDO2 hardware key বাধ্যতামূলক করেছিল। তাদের প্রতিবেদনের ভাষ্যে origin binding-ই real-time phishing আটকেছে। Google-ও ২০১৮ সালে জানায়, ২০১৭ সালের শুরুতে কর্মীদের security key দেওয়ার পর কোনো নিশ্চিত account takeover তাদের জানা ছিল না। এগুলো প্রতিষ্ঠানের নিজের ভাষ্য, স্বাধীনভাবে নিরীক্ষিত সংখ্যা নয়।

৭ · FIDO2, WebAuthn আর CTAP — registration আর login ceremony

নামগুলো গুলিয়ে যায়, তাই আগে সাজিয়ে নিই। FIDO2 হলো ছাতা-নাম, যার দুটি অংশ। WebAuthn হলো W3C-র মান, অর্থাৎ website আর browser-এর ভাষা। CTAP হলো FIDO Alliance-এর মান, অর্থাৎ browser বা OS আর বাইরের যন্ত্রের ভাষা। যে যন্ত্র key রাখে আর স্বাক্ষর করে, সে authenticator. ল্যাপটপ বা ফোনের ভেতরের হলে platform authenticator, আর USB, NFC বা Bluetooth-এ যুক্ত আলাদা চাবি হলে security key. যে website login নিচ্ছে, সে relying party বা RP. তার নাম RP ID, যেমন shop.example.com.

WebAuthn-এ পুরো অনুষ্ঠানকে বলে ceremony. ভিত্তি হলো পর্ব ১০-এর public key cryptography আর পর্ব ১১-এর digital signature. গোপন key কখনো server-এ যায় না। এটিই shared secret-এর সঙ্গে মৌলিক পার্থক্য।

Registration: key জোড়া তৈরি

1. Server একটি random challenge, RP ID আর ব্যবহারকারীর পরিচয় পাঠায়।
2. Browser origin মিলিয়ে authenticator-কে বলে নতুন key জোড়া বানাতে। ব্যবহারকারী আঙুলের ছাপ বা PIN দেন। এটি user verification.
3. Authenticator ফেরত দেয় credential ID আর public key, সঙ্গে চাইলে attestation, মানে যন্ত্রের ধরন সম্পর্কে একটি স্বাক্ষরিত বিবৃতি।
4. Server challenge, origin আর RP ID-র hash মিলিয়ে public key রেখে দেয়।

Login-এর ধাপগুলো এবার দেখুন। মানগুলো উদাহরণ, তবে rpIdHash সত্যিই shop.example.com-এর SHA-256. Script চালিয়ে পাওয়া।

challenge: example-challenge
rpId     : shop.example.com
timeout  : 60000 ms

{
  "type": "webauthn.get",
  "challenge": "ZXhhbXBsZS1...",
  "origin": "https://shop.example.com",
  "crossOrigin": false
}

credential খোঁজা: shop.example.com → পাওয়া গেছে
user presence    : UP = 1
user verification: UV = 1 (আঙুলের ছাপ)
আঙুলের ছাপ server-এ যায় না

rpIdHash = 951623a26f8b3388...
flags    = UP, UV, BE, BS
signCount= 0

sign( authenticatorData ||
      SHA-256(clientDataJSON) )

type      == webauthn.get        ✓
challenge == পাঠানো মান          ✓
origin    == অনুমোদিত তালিকায়    ✓
rpIdHash  == SHA-256(rpId)       ✓
UP, UV    == নীতি অনুযায়ী        ✓
signature == public key-তে মিলল  ✓

challenge বাতিল (একবারই চলবে)
session তৈরি
event লেখা: login, credential ID, UV

Website-এর দিক থেকে ডাকটি কেমন দেখায়, তা নিচে। এটি আপনার নিজের সাইটের জন্য নমুনা, চালানোর জন্য নয়। আপনার server থেকে আনা challenge ছাড়া এটি অর্থহীন।

// উদাহরণ: challengeBytes আপনার server থেকে আসবে, এখানে বানানো যাবে না
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: challengeBytes,
    rpId: "shop.example.com",
    userVerification: "required",
    timeout: 60000
  }
});
// assertion পুরোটা server-এ পাঠান। যাচাই browser-এ নয়, server-এ হবে।

এবার একটি ছোট খেলনায় দেখুন, কোন যাচাই কোন বিপদ ধরে। এখানে স্বাক্ষর খেলনা, কিন্তু কাঠামোটি একই। Private key শুধু authenticator-এর হাতে, আর server-এর কাছে শুধু public মান।

// খেলনা স্বাক্ষর: ছোট RSA (n=3233) + FNV hash. real নয়, শুধু ধারণার জন্য
const N = 3233, E = 17, D = 2753, RP = 'shop.example.com';
const ORIGIN = 'https://' + RP;
function modPow(b, e, m) { let r = 1; b %= m;
  while (e > 0) { if (e & 1) r = r * b % m; b = b * b % m; e >>= 1; }
  return r; }
function toyHash(s) { let h = 2166136261;
  for (const c of s) h = Math.imul(h ^ c.charCodeAt(0), 16777619) >>> 0;
  return h % N; }
const toySign = (rp, data) => modPow(toyHash(rp + '|' + data), D, N);
const wallet = new Set([RP]);                  // passkey শুধু এই RP-র জন্য
function browserGet(pageHost, challenge) {     // origin browser নিজে লেখে
  const data = JSON.stringify({ origin: 'https://' + pageHost, challenge });
  if (!wallet.has(pageHost)) return null;      // এই সাইটের credential নেই
  return { data, sig: toySign(pageHost, data) };
}
function serverVerify(resp, challenge) {       // server জানে শুধু N আর E
  if (!resp) return 'nothing to verify, no signature exists';
  const cd = JSON.parse(resp.data);
  if (modPow(resp.sig, E, N) !== toyHash(RP + '|' + resp.data))
    return 'REJECT signature';
  if (cd.challenge !== challenge) return 'REJECT stale challenge';
  if (cd.origin !== ORIGIN) return 'REJECT origin ' + cd.origin;
  return 'ACCEPT';
}
const good = browserGet(RP, 'c1');
console.log('real site      :', serverVerify(good, 'c1'));
console.log('look-alike site:', serverVerify(browserGet('shop.example.net', 'c2'), 'c2'));
console.log('old response   :', serverVerify(good, 'c3'));
const edited = { data: good.data.replace('c1', 'c3'), sig: good.sig };
console.log('edited data    :', serverVerify(edited, 'c3'));
const fakeData = JSON.stringify({ origin: 'https://shop.example.net', challenge: 'c4' });
console.log('buggy wallet   :', serverVerify({ data: fakeData, sig: toySign(RP, fakeData) }, 'c4'));

৮ · Passkey — synced, device-bound আর recovery-র দুর্বলতা

Passkey হলো FIDO credential-এর জনপ্রিয় নাম, যা দিয়ে password ছাড়াই login করা যায়। যন্ত্র নিজেই জানে কোন সাইটের জন্য কোন key, এমন credential-কে বলে discoverable credential. আঙুলের ছাপ বা PIN দিলে একসঙ্গে দুটি জিনিস প্রমাণ হয়: যন্ত্রটি আপনার কাছে আছে, আর আপনি সেটি খুলতে পারেন। তাই একটি ধাপেই MFA-র মান পাওয়া যায়।

Passkey দুই ধরনের। পার্থক্যটি হলো private key কোথায় থাকতে পারে।

WebAuthn-এর flags-এ BE (sync হতে পারে কি না) আর BS (এখন backup হয়েছে কি না) জানানো হয়। Server এ দিয়ে নীতি ঠিক করতে পারে, যেমন উচ্চ ঝুঁকির কর্মীদের device-bound key দাবি করা। তবে NIST বলে, সাধারণ মানুষের সেবায় BS-এর ভিত্তিতে গ্রহণ-বর্জন করা উচিত নয়। সাধারণ গ্রাহকের জন্য হিসাবটি সহজ: password আর OTP-র চেয়ে synced passkey অনেক ভালো, তবে তার নিরাপত্তা sync account-এর নিরাপত্তার সঙ্গে জড়িত।

Recovery: আসল দুর্বল জায়গা

একটি চিন্তার পরীক্ষা করুন। আপনার সেবায় passkey আছে, phishing আটকে যায়। ব্যবহারকারী ফোন হারিয়ে ফেললেন। এবার কী? Account recovery যদি শুধু SMS code বা কয়েকটি ব্যক্তিগত প্রশ্ন হয়, তাহলে আপনার সব নিরাপত্তা সেই প্রশ্নের সমান। হামলাকারী তালা ভাঙে না, পেছনের দরজা খোঁজে।

• Backup code: আগে থেকে দেওয়া একবার ব্যবহারযোগ্য code. কাগজে ছাপিয়ে নিরাপদ জায়গায় রাখুন, password-এর পাশে নয়।
• একাধিক authenticator: শুরুতেই দুটি passkey বা security key যোগ করা। এটিই সবচেয়ে ভালো recovery, কারণ recovery দরকারই পড়ে না।
• Helpdesk-এর নিয়ম: কথায় বিশ্বাস নয়। পরিচয় যাচাইয়ের লিখিত ধাপ, দ্বিতীয় ব্যক্তির অনুমোদন আর log. পর্ব ৩-এর separation of duties এখানে কাজে লাগে।
• জানানো আর অপেক্ষা: Recovery হলে সব জায়গায় notification পাঠানো। স্পর্শকাতর কাজে কিছু সময় বিরতি রাখা।

NIST SP 800-63B-4-এর নিয়মগুলো কার্যকর মাপকাঠি। সংরক্ষিত recovery code-এ অনুমোদিত random উৎস থেকে অন্তত ৬৪ bit থাকতে হবে, code hash করে রাখতে হবে, আর ব্যবহারের পরে বাতিল করতে হবে। Recovery হলে সবসময় ব্যবহারকারীকে জানাতে হবে। AAL2 account-এ recovery-র জন্য বিভিন্ন পথের সমন্বয় লাগে, যেমন ভিন্ন পদ্ধতিতে পাওয়া দুটি recovery code.

হিসাব: Backup code-এ কত bit

৬৪ bit পেতে দশমিকে দরকার ⌈64 / 3.32⌉ = ২০ অঙ্ক। ধারণাটি পর্ব ৭-এর entropy-র। অক্ষরগুলো নিরাপদ CSPRNG থেকে এলে তবেই এই হিসাব খাটে।

৯ · প্রতিষ্ঠানে চালু করা — enrollment, step-up আর NIST-এর মান

একটি কাল্পনিক অনলাইন বাজারের নিরাপত্তা প্রধান আপনি। কাল থেকে সবার passkey চালু করে দিলে কী হবে? Helpdesk ভেঙে পড়বে, আর পুরোনো ফোনের মানুষ আটকে যাবেন। Rollout একটি প্রকৌশল আর মানুষ সামলানোর কাজ।

Enrollment: নতুন পদ্ধতি যোগ করার মুহূর্তটিই ঝুঁকির

কেউ password চুরি করে নিজের যন্ত্র যোগ করে ফেললে সব শেষ। তাই নতুন authenticator যোগ করার আগে বিদ্যমান শক্ত পদ্ধতিতে আবার যাচাই করুন, ব্যবহারকারীকে জানান, আর ঘটনাটি log করুন। প্রথম enrollment-ও গুরুত্বপূর্ণ। কেউ যেন শুধু password দিয়ে অন্যের account-এ প্রথম passkey বসাতে না পারে।

Step-up authentication: ঝুঁকি বুঝে যাচাই

প্রতিটি পাতায় আঙুলের ছাপ চাইলে মানুষ বিরক্ত হন। আবার login-এর পরে সব খোলা রাখাও ঠিক নয়। সমাধান হলো সংবেদনশীল কাজের আগে নতুন করে যাচাই করা: নতুন প্রাপক যোগ, বড় লেনদেন, password বা MFA বদল, ডেটা export, admin ভূমিকা নেওয়া। লেনদেনের ক্ষেত্রে সবচেয়ে ভালো হলো যাচাইকে নির্দিষ্ট লেনদেনের সঙ্গে বাঁধা, যাতে ব্যবহারকারী পরিমাণ আর প্রাপক দেখে অনুমোদন দেন। Admin-দের নিয়ম পর্ব ২০-এ আছে।

Rollout-এর ক্রম

1. তালিকা: কোন system কোন login নেয়, কোনগুলো পুরোনো protocol-এ আটকে আছে।
2. আগে admin: সবচেয়ে বড় blast radius-এর হিসাব আগে রক্ষা করুন, প্রতিজনের জন্য দুটি device-bound key.
3. Break-glass: জরুরি হিসাব আলাদা রাখুন, ব্যবহারে সতর্কবার্তা বাজান, নিয়মিত পরীক্ষা করুন।
4. পরীক্ষামূলক দল: একটি ছোট বিভাগে চালু করে সমস্যা শিখুন।
5. পর্যায়ে পর্যায়ে বাধ্যতামূলক: আগে ঐচ্ছিক, তারপর নতুন কর্মীদের জন্য, তারপর সবার জন্য।
6. দুর্বল fallback বন্ধ: এটিই শেষ এবং সবচেয়ে ভুলে যাওয়া ধাপ। SMS খোলা থাকলে হামলাকারী সেখানেই নামতে চাইবে।

Metric রাখুন: কত শতাংশ account-এ phishing-প্রতিরোধী পদ্ধতি আছে, কত login fallback দিয়ে হচ্ছে, মাসে কতবার helpdesk recovery হচ্ছে, push প্রত্যাখ্যানের সংখ্যা। সবচেয়ে কাজের সংখ্যাটি হলো fallback-এর হার। এটি না কমলে নিরাপত্তা কাগজে বেড়েছে, বাস্তবে নয়।

NIST-এর স্তর

AAL মানে Authentication Assurance Level. NIST SP 800-63B-4 (২০২৫, 800-63B-এর আগের সংস্করণের স্থলাভিষিক্ত) থেকে মূল বিষয়গুলো হলো:

এখানে একটি সূক্ষ্মতা আছে। NIST-এর syncable appendix অনুযায়ী phishing resistance সুপারিশকৃত, আর মার্কিন federal enterprise-এর জন্য আবশ্যক। কারণ এটি সঠিক কনফিগারেশনের ওপর নির্ভর করে। আবার নকল সাইট ঠেকানোর দিক থেকে synced আর device-bound passkey একই। কিন্তু sync account দখল ঠেকানোর দিক থেকে তারা এক নয়। “Phishing-প্রতিরোধী” শব্দটি দেখে সব ঝুঁকি শেষ ভাববেন না। মার্কিন সরকারের OMB M-22-09 (২০২২) সরকারি কর্মীদের জন্য phishing-প্রতিরোধী MFA চেয়েছিল। বাংলাদেশে আপনার খাতের নিয়ন্ত্রকের বর্তমান নিয়ম আলাদাভাবে দেখে নিন।

১০ · AI-এর যুগে MFA — যা যাচাই না করলে বিপদ

AI দ্রুত TOTP বা WebAuthn কোড লিখে দেয়। কোড চলেও। কিন্তু এখানকার ভুলগুলো প্রায়ই “চলে” এমন ভুল: login সফল হয়, শুধু সুরক্ষাটি থাকে না। Happy path পরীক্ষায় তা ধরা পড়ে না।

• Prompt-এ আসল seed, recovery code, token বা ব্যক্তিগত তথ্য দিইনি
• AI-এর উল্লেখ করা RFC বা NIST অংশ মূল উৎসে খুলে দেখেছি
• নেতিবাচক test চালিয়েছি: ভুল origin, পুরোনো challenge, একই OTP দুবার
• Fallback আর recovery পথও পর্যালোচনায় রেখেছি
• নিজের লেখা crypto-র বদলে পরীক্ষিত library ব্যবহার করেছি
• মানুষের ওপর প্রভাব ফেলে এমন সিদ্ধান্ত, যেমন account বন্ধ, একজন মানুষ নিয়েছেন