Authentication — পরিচয় যাচাইয়ের উপায় আর password নীতি

১ · নাম বলা, প্রমাণ দেওয়া, অনুমতি পাওয়া

একটি অফিসের গেটের কথা ভাবুন। দারোয়ান জিজ্ঞেস করলেন, “কে আপনি?” আপনি বললেন, “আমি রহিমা, হিসাব বিভাগের।” এটি শুধু দাবি। তিনি তখন পরিচয়পত্র দেখলেন, ছবির সঙ্গে মুখ মেলালেন। এবার দাবিটি যাচাই হলো। এরপর রেজিস্টার খাতায় দেখা হলো, আপনি কি সার্ভার রুমে যেতে পারেন? না, শুধু তিন তলার অফিসে।

একটি গেটেই তিনটি আলাদা কাজ হলো। কম্পিউটারেও ঠিক তাই হয়, আর এই তিনটি গুলিয়ে ফেলাই বহু ভুল নকশার শুরু।

২ · Factor: প্রমাণের তিন ধরন, আর কেন স্থান প্রমাণ নয়

প্রমাণ দেওয়ার উপায় অনেক, কিন্তু ধরন মূলত তিনটি। প্রতিটি ধরনকে বলে authentication factor. যে জিনিস দিয়ে প্রমাণ দেওয়া হয়, তাকে NIST বলে authenticator.

MFA মানে এই তিন ভিন্ন ধরনের অন্তত দুটি। Password আর security question মিলিয়ে দুটি জিনিস হয়, কিন্তু দুটিই “যা জানেন”। তাই এটি MFA নয়। একটি phishing পাতায় দুটিই একসঙ্গে চলে যেতে পারে। NIST SP 800-63B-4 আঙুলের ছাপ বা মুখকে একা authenticator হিসেবে নেয় না। এটি একটি physical authenticator-এর সঙ্গে জোড়া অবস্থায় কাজে লাগে, যেমন ফোন আনলক করে তার ভেতরের key ব্যবহার।

স্থান আর আচরণ কেন সংকেত, factor নয়

কিছু পুরোনো বইয়ে “somewhere you are” বা “something you do”-কে চতুর্থ বা পঞ্চম factor বলা হয়। বিভিন্ন পাঠ্যে এই শ্রেণিবিভাগ আলাদা, তাই পরীক্ষায় প্রশ্নটি মন দিয়ে পড়বেন। তবে রক্ষকের দিক থেকে পার্থক্যটি জরুরি।

IP ঠিকানা, দেশ, device, টাইপ করার ধরন, login-এর সময়, এগুলো কোনো গোপন জিনিস প্রমাণ করে না। IP অন্যের সঙ্গে ভাগ হতে পারে, VPN-এ বদলে যেতে পারে। ঢাকার একজন ব্যবহারকারী ঈদের ছুটিতে সিলেট গেলে তাঁর “স্থান” বদলায়, পরিচয় নয়। তাই এগুলো সন্দেহ বাড়ায় বা কমায়, নিজে প্রমাণ দেয় না। এই ব্যবহারকে বলে risk-based authentication: সংকেত অস্বাভাবিক হলে বাড়তি প্রমাণ চাওয়া। NIST-ও এটিকে অতিরিক্ত কৌশল হিসেবে দেখায়, factor হিসেবে নয়।

AAL: কত নিশ্চয়তা চাই

সব সেবায় একই মাত্রার যাচাই দরকার নেই। NIST SP 800-63B-4 তিনটি Authentication Assurance Level ঠিক করেছে। এটি মার্কিন সরকারি সংস্থার জন্য লেখা, বাংলাদেশে আইনি বাধ্যবাধকতা নয়, তবে সারা বিশ্বে মাপকাঠি হিসেবে ব্যবহার হয়।

বাস্তব অনুবাদ, যা আমাদের নিজের ব্যাখ্যা, NIST-এর নয়: একটি মতামত-লেখার সাইটে AAL1-এর কাছাকাছি চলতে পারে, টাকা বা গ্রাহকের ডেটায় AAL2 লক্ষ্য করুন, আর production-এর admin হিসাবে AAL3-এর ধারণা নিন। সিদ্ধান্ত নেবেন পর্ব ২-এর ঝুঁকির হিসাব থেকে, ফ্যাশন দেখে নয়। Admin হিসাবের বিশেষ নিয়ম আসবে পর্ব ২০-এ।

৩ · একটি login-এর ওপর কী কী বিপদ আসে

কাউকে হিসাবে ঢুকতে হলে তালা ভাঙার দরকার পড়ে না, চাবি পেলেই চলে। তাই অন্যের হিসাব দখল বা account takeover বেশির ভাগ সময় চাবি-কেন্দ্রিক। নিচের টেবিলে প্রতিটি ঝুঁকি ধারণার স্তরে দেওয়া হলো, সঙ্গে রক্ষার উপায়।

আরেকটি উৎসও মনে রাখুন: infostealer নামের malware ব্যবহারকারীর ব্রাউজার বা যন্ত্র থেকে login তথ্য চুরি করে। Mandiant ২০২৪ সালে একটি cloud data সেবার গ্রাহকদের হিসাব-দখল নিয়ে যে রিপোর্ট প্রকাশ করে, তাতে সেবাটির নিজের system ভাঙার প্রমাণ মেলেনি। বড় ক্ষতির ঘটনাগুলোতে তিনটি মিল ছিল: হিসাবে MFA ছিল না, চুরি হওয়া তথ্য বহু বছর পরও চালু ছিল, আর network সীমা ছিল না। সেখানে সবচেয়ে কাজের রক্ষা হতো খুব সাধারণ তিনটি নিয়ম।

এবার দেখুন একটি ভালো login-এর ভেতরে পরপর কী কী যাচাই হয়। “পরে” চাপুন, আর ডান পাশের মানগুলো খেয়াল করুন।

1receive request over TLS2check ip and account limits3load user, or a dummy record4verify slow hash in constant time5ask second factor if required6reset counter, new session7write login event

৪ · আধুনিক password নীতি: কম নিয়ম, বেশি সুরক্ষা

আপনি নিশ্চয়ই এই বার্তা দেখেছেন: “বড় হাতের অক্ষর, ছোট হাতের অক্ষর, অঙ্ক আর চিহ্ন থাকতে হবে, আর ৯০ দিন পরপর বদলাতে হবে।” এই নিয়মের নাম composition rule আর periodic rotation. শুনতে শক্ত, কিন্তু মানুষের আচরণের ফল উল্টো।

কেন উল্টো ফল? কারণ মানুষ নিয়ম মেনে চলেন, লক্ষ্য মেনে নয়। “চার ধরনের চিহ্ন” বললে অনেকে Password1!-এর মতো চেনা ছাঁচ বেছে নেন: শুরুতে বড় হাতের অক্ষর, শেষে অঙ্ক আর একটি চিহ্ন। Weir ও সহকর্মীদের ২০১০ সালের গবেষণা দেখায়, এমন নিয়মের মাপা entropy বাস্তবের অনুমান-প্রতিরোধকে ঠিকভাবে বোঝায় না। আর “৯০ দিনে বদলান” বললে Dhaka2026-এর পরে আসে Dhaka2027. Zhang, Monrose আর Reiter (CCS ২০১০) ৭,৭০০-র বেশি হিসাবের তথ্যে দেখান, পুরোনো password জানা থাকলে offline হিসাবে গড়ে প্রায় ৪১ শতাংশ হিসাবে নতুন password অনুমান করা যায়।

নিচের টেবিলে NIST SP 800-63B-4, Sec. 3.1.1.2-এর মূল শর্তগুলো দেওয়া হলো। এগুলো ২০২৬ সালের অক্টোবরে মূল নথি থেকে মেলানো, তবু বাস্তবায়নের আগে আপনিও মূল পাতাটি পড়ে নেবেন। NIST-এর ভাষায় SHALL মানে বাধ্য, SHOULD মানে জোরালো সুপারিশ।

Password manager-এর আরেকটি নিরাপত্তা-সুবিধা আছে। এটি সাধারণত আসল domain মিলিয়ে পূরণ করে, তাই ভুয়া পাতায় চুপ করে থাকে। কিছু সাইট “নিরাপত্তার জন্য” paste বন্ধ রাখে। ফল হয় উল্টো: ব্যবহারকারী manager ছেড়ে ছোট, মনে রাখার মতো password-এ ফেরেন। আর লম্বা password-এর bcrypt-সীমা নিয়ে পর্ব ১৩ দেখুন। Server-এ password কীভাবে রাখবেন, সেটিও ওই পর্বের বিষয়।

সংখ্যায় দেখুন: দৈর্ঘ্য বনাম মিশ্রণ

সূত্র একটিই। প্রতি অক্ষরে k রকম মান এলোমেলোভাবে বাছলে, L অক্ষরের entropy = L × log₂k bit. এলোমেলো শব্দটি জরুরি। মানুষের বাছা password এই হিসাব থেকে অনেক দুর্বল।

দেখুন, ছোট হাতের ১৫ অক্ষর মিশ্র ৮ অক্ষরকে অনেক পেছনে ফেলে। নিচের সিমুলেটরে পুরোনো আর নতুন নিয়ম পাশাপাশি চলছে। এখানে পাসওয়ার্ডগুলো উদাহরণ মাত্র। পাতায় ছাপা কোনো password নিজে ব্যবহার করবেন না।

// Toy policy checker with a tiny blocklist. A real blocklist is far larger.
const BLOCK = ["password", "qwerty", "letmein", "admin", "welcome", "abcshop", "amarsonarbangla"];
const LEET = { "@": "a", "0": "o", "1": "l", "3": "e", "$": "s", "5": "s" };

function oldRule(pw) {                 // পুরোনো নিয়ম: ৮ অক্ষর, চার ধরনের চিহ্ন
  const kinds = [/[a-z]/, /[A-Z]/, /[0-9]/, /[^a-zA-Z0-9]/].filter(r => r.test(pw)).length;
  return pw.length >= 8 && kinds === 4 ? "PASS" : "FAIL";
}
function core(pw) {                    // ছোট হাতের অক্ষর, leet উল্টে, শেষের অঙ্ক-চিহ্ন বাদ
  const s = pw.toLowerCase().replace(/[^a-z0-9@$]+$/, "").replace(/[0-9]+$/, "");
  return [...s].map(c => LEET[c] || c).join("").replace(/[^a-z]/g, "");
}
function newRule(pw, minLen) {         // নতুন নিয়ম: দৈর্ঘ্য আর blocklist
  if ([...pw].length < minLen) return "REJECT short";
  if (new Set(pw).size < 5) return "REJECT repetitive";
  const c = core(pw);
  if (BLOCK.some(b => c.startsWith(b))) return "REJECT blocklist";
  return "ACCEPT";
}
const samples = ["Password1!", "P@ssw0rd2026!", "Abcshop@2026", "Summer#2026",
  "amar-sonar-bangla-1971", "aaaaaaaaaaaaaaaa", "nodi-ilish-brishti-cha",
  "kathal tin jutar golpo"];
console.log("sample".padEnd(26) + "old".padEnd(6) + "new, single-factor (15)");
for (const pw of samples) {
  console.log(pw.padEnd(26) + oldRule(pw).padEnd(6) + newRule(pw, 15));
}
console.log("with MFA, minimum 8:");
for (const pw of ["P@ssw0rd2026!", "Abcshop@2026", "Summer#2026"]) {
  console.log(pw.padEnd(26) + newRule(pw, 8));
}

৫ · Throttling আর lockout: গতি কমানো, মানুষ না আটকানো

Online অনুমান ঠেকানোর উপায় হলো চেষ্টার গতি কমানো। দুটি শব্দ আলাদা করুন। Login throttling মানে ব্যর্থতার পরে অপেক্ষা করানো। Account lockout মানে হিসাব নির্দিষ্ট সময় বা স্থায়ীভাবে বন্ধ করা।

NIST SP 800-63B-4, Sec. 3.2.2 বলে, একটি হিসাবে একটি authenticator-এ পরপর ব্যর্থতা ১০০-র বেশি হওয়া চলবে না। সেখানে authenticator নিষ্ক্রিয় করতে হয়। সংখ্যাটি অবাক লাগতে পারে। কিন্তু blocklist আর ১৫ অক্ষর থাকলে ১০০টি অনুমানে মেলার সম্ভাবনা খুব কম। ১০০ হলো ঊর্ধ্বসীমা, প্রতিষ্ঠান চাইলে কম রাখতে পারে। NIST ঐচ্ছিকভাবে bot-পরীক্ষা, ক্রমে বাড়তে থাকা অপেক্ষা (যেমন ৩০ সেকেন্ড থেকে এক ঘণ্টা) আর risk-based কৌশলের কথাও বলে, যাতে অন্য কেউ আসল মালিককে আটকে দিতে না পারেন।

নিচের ডায়াগ্রামে একটি হিসাবের একটি সিদ্ধান্ত ধাপে ধাপে দেখুন। ধরে নেওয়া নীতি: ৩টি ব্যর্থতা বিনা অপেক্ষায়, তারপর ৩০ সেকেন্ড থেকে দ্বিগুণ হতে হতে সর্বোচ্চ ১ ঘণ্টা, আর ১০০-তে নিষ্ক্রিয়।

হিসাবে দেখুন: lockout কতটা ঠেকায়, কতটা ক্ষতি করে

ঠেকানো: ধরুন ৫ ব্যর্থতায় ১৫ মিনিট বন্ধ। ঘণ্টায় ৪ বার, দিনে ৯৬ বার। প্রতিবার ৫টি চেষ্টা মানে দিনে ৪৮০, বছরে ৪৮০ × ৩৬৫ = ১,৭৫,২০০টি অনুমান। অর্থাৎ শুধু সময়ের lockout অনুমান থামায় না, ধীর করে। তাই NIST-এর মতো মোট সংখ্যার ঊর্ধ্বসীমা দরকার।

ক্ষতি: ১০,০০০ হিসাবের সেবায় প্রতি হিসাবে ৫টি ভুল চেষ্টা মানে ৫০,০০০ অনুরোধ। ৯০০ সেকেন্ডে ছড়ালে সেকেন্ডে প্রায় ৫৫.৬টি অনুরোধেই সবাই বাইরে থাকতে পারেন। এটিও একধরনের denial of service. কাস্টমার সাপোর্টের ফোন বাজতে শুরু করবে, আর সেই চাপে ভুল সিদ্ধান্তের ঝুঁকিও বাড়ে।

Per-account, per-IP আর ধীরে-ছড়ানো ধরন

এবার সিমুলেটর। একটি কাল্পনিক login-প্রবাহে ৩০০টি ব্যর্থ চেষ্টা আছে, সবই নকল। আমরা শুধু গুনছি, চারটি নীতির অধীনে কতগুলো চেষ্টা password যাচাই পর্যন্ত পৌঁছায়। Limit ধরে নেওয়া: একটি হিসাবে ১৫ মিনিটে ৫, একটি IP-তে ২০. শেষের কলাম পুরো সাইটের ১৫ মিনিটের সর্বোচ্চ ব্যর্থতা।

// Toy login simulator: in-memory events, simulated clock, no network.
const WIN = 900;                              // 15 min, in simulated seconds
const LIMIT = { account: 5, ip: 20 };         // assumed policy
function run(events, useAccount, useIp) {     // returns attempts that reach the check
  const hist = {}, until = {};
  let checked = 0;
  for (const e of events) {
    const keys = [];
    if (useAccount) keys.push(["account", e.user]);
    if (useIp) keys.push(["ip", e.ip]);
    if (keys.some(([kind, id]) => (until[kind + id] || 0) > e.t)) continue;
    checked++;
    for (const [kind, id] of keys) {
      const k = kind + id;
      hist[k] = (hist[k] || []).filter(t => e.t - t < WIN).concat(e.t);
      if (hist[k].length >= LIMIT[kind]) until[k] = e.t + WIN;
    }
  }
  return checked;
}
const make = (gap, ip, user) => Array.from({ length: 300 },
  (_, i) => ({ t: i * gap, ip: ip(i), user: user(i) }));
const oneIp = () => "203.0.113.5", manyIp = i => "198.51.100." + (i % 250 + 1);
const oneUser = () => "rahima", manyUser = i => "user" + i;
const patterns = { "A one ip, one account  ": make(2, oneIp, oneUser),
  "B one ip, many accounts": make(5, oneIp, manyUser),
  "C many ip, one account ": make(20, manyIp, oneUser),
  "D many ip, many, slow  ": make(20, manyIp, manyUser) };
console.log("pattern                  none acct   ip both sitePeak15m");
for (const [name, ev] of Object.entries(patterns)) {
  const peak = Math.max(...ev.map(a => ev.filter(b => b.t >= a.t && b.t < a.t + WIN).length));
  const cols = [[0, 0], [1, 0], [0, 1], [1, 1]].map(([a, b]) => String(run(ev, a, b)).padStart(4));
  console.log(name, cols.join(" "), String(peak).padStart(6), peak > 30 ? "ALERT" : "");
}

২০২৪ সালের জানুয়ারিতে Microsoft জানায়, একটি পুরোনো test হিসাবে password spraying করে ঢোকা হয়েছিল, যাতে MFA ছিল না। তাদের প্রকাশিত বিবরণে চেষ্টা ছিল খুব অল্প, যাতে সহজে ধরা না পড়ে। শিক্ষাটি রক্ষকের জন্য: test আর পুরোনো হিসাবকেও একই নিয়মে আনুন, কারণ limit একা সব ধরে না।

৬ · Account enumeration: বার্তা যেন গোপন কথা না বলে

“এই email-এ কোনো হিসাব নেই” বার্তাটি ব্যবহারকারীর কাজে লাগে। কিন্তু সেটি বাইরের মানুষকেও জানিয়ে দেয়, কোন ঠিকানা আপনার সেবায় আছে, কোনটি নেই। একে বলে account enumeration. হিসাবের অস্তিত্ব নিজেই তথ্য। ধরুন একটি রোগের সহায়তা সেবা বা ঋণের অ্যাপ। সেখানে হিসাব আছে জানা গেলেও ব্যক্তিগত ক্ষতি হতে পারে। আর phishing-ও তখন নিশানা পায়।

শেষ সারিটিই সবচেয়ে সূক্ষ্ম। Argon2id-এর মতো ধীর hash ব্যবহার করলে হিসাব থাকা আর না থাকার উত্তরে স্পষ্ট সময়ের ফারাক হয়। পর্ব ১৩-এর ধীর hash যে সুরক্ষা দেয়, সেটিই এখানে তথ্য ফাঁস করতে পারে, যদি হিসাব না থাকলে তা বাদ দেওয়া হয়। নকশাটি নিচে উদাহরণ হিসেবে দেখুন। এটি pseudocode, চালানোর জন্য নয়।

# অনিরাপদ ধরন: দুই পথ, দুই বার্তা, দুই রকম সময়
user = find_user(email)
if user is None:
    return error("no such user")          # দ্রুত, আর পরিচয় ফাঁস করে
if not verify_hash(password, user.hash):
    return error("wrong password")

# নিরাপদ ধরন: এক পথ, এক বার্তা, প্রায় এক সময়
user = find_user(email)
stored = user.hash if user else DUMMY_HASH     # একই cost-এ আগে বানানো
ok = verify_hash(password, stored)
if user is None or not ok:
    return error("username or password incorrect")

৭ · Password reset: পেছনের দরজা, সবচেয়ে দুর্বল দরজা

সামনের দরজায় ভালো তালা লাগানো হলো। কিন্তু পেছনের একটি দরজা বলছে, “চাবি হারিয়েছেন? নাম বলুন, খুলে দিচ্ছি।” তাহলে সামনের তালার দাম কতটুকু? একটি হিসাবের নিরাপত্তা সবচেয়ে দুর্বল প্রবেশপথের সমান। পর্ব ৪-এর attack surface-এর কথা মনে করুন।

NIST SP 800-63B-4-এর Sec. 4.2 account recovery-কে আলাদা গুরুত্ব দেয়। Email, SMS বা ডাকে পাঠানো code-কে সেখানে recovery code বলা হয়। পাঠানো code-এ অন্তত ৬টি দশমিক অঙ্ক, আর আগে থেকে সংরক্ষণ করা code-এ অন্তত ৬৪ bit এলোমেলো মান চায়। মেয়াদ SMS-এ ১০ মিনিট, email-এ ২৪ ঘণ্টা পর্যন্ত। প্রতিটি recovery-তে ব্যবহারকারীকে জানাতে হয়। OWASP-এর Forgot Password Cheat Sheet যোগ করে: একই বার্তা, একই সময়, কড়া random, সীমিত আয়ু, একবার ব্যবহার, আর reset-এর পরে স্বয়ংক্রিয় login নয়।

নিচের ডায়াগ্রামে একটি নিরাপদ reset দেখুন। এখানে আসল token-এর বদলে example-token দেখানো হচ্ছে, আর পাশের hash তার আসল SHA-256 শুরুর অংশ।

1same reply for every address2token = secure_random(32 bytes)3store sha256(token), expiry4send link to registered email5check hash, expiry, unused6screen new password7mark token used, end sessions8notify owner, write log

একই নকশা এবার আসল কোডে। প্রথম লাইনগুলোতে একটি reset token-এর অনিরাপদ ধরন আছে: email আর সময় থেকে বানানো, তাই অনুমেয়। পরের অংশে নিরাপদ ধরন। সবই একটি কাল্পনিক in-memory টেবিলে।

import hashlib, hmac, secrets

def unsafe_token(email, clock):      # অনিরাপদ নকশা, শুধু তুলনার জন্য
    return hashlib.md5(f"{email}{clock}".encode()).hexdigest()

same = unsafe_token("a@example.com", 1000) == unsafe_token("a@example.com", 1000)
print("unsafe: same input gives same token:", same)

TTL = 1800                           # ৩০ মিনিট, simulated seconds
DB = {}                              # toy in-memory table
def fp(token):
    return hashlib.sha256(token.encode()).hexdigest()
def issue(user, now):                # নতুন token পুরোনোটিকে বাতিল করে
    token = secrets.token_urlsafe(32)        # 32 byte = 256 bit
    DB[user] = {"hash": fp(token), "expires": now + TTL, "used": False}
    return token
def redeem(user, token, now):
    row = DB.get(user)
    ok = row is not None and hmac.compare_digest(row["hash"], fp(token))
    if not ok or row["used"] or now > row["expires"]:
        return "rejected"            # কারণ ভেতরের log-এ, বাইরে একই বার্তা
    row["used"] = True
    return "ok"

t1 = issue("rahima", 0)
print("safe: token length:", len(t1), "| plain token in table:", t1 in str(DB))
print("wrong token, t=60      :", redeem("rahima", "example-token", 60))
print("right token, t=120     :", redeem("rahima", t1, 120))
print("same token again, t=130:", redeem("rahima", t1, 130))
t2 = issue("rahima", 5000)
print("late token, t=6801     :", redeem("rahima", t2, 6801))
t3, t4 = issue("rahima", 7000), issue("rahima", 7010)
print("older of two, t=7020   :", redeem("rahima", t3, 7020))
print("newest of two, t=7030  :", redeem("rahima", t4, 7030))

ছোট code-এর হিসাব: ৬ অঙ্কের code-এ ১০^৬ সম্ভাব্য মান। ৫টি চেষ্টায় সীমা রাখলে একটি code-এ মেলার সম্ভাবনা ৫ ÷ ১০^৬ = ০.০০০৫%. কিন্তু ১০ লাখ হিসাবে একই চেষ্টা ছড়ালে গড়ে ৫টি হিসাবে মিলতে পারে। তাই ছোট code-এ হিসাব-প্রতি নয়, পুরো সেবার limit-ও জরুরি। লম্বা link-token-এ এই ভয় নেই।

Security question: একটি বাতিল ধারণা

“আপনার মায়ের বিয়ের আগের নাম কী?” “প্রথম স্কুলের নাম?” এই উত্তরগুলো অনেকের ক্ষেত্রেই আত্মীয়, ফেসবুক বা সরকারি নথি থেকে জানা যায়। আর বদলানো যায় না। Google-এর গবেষকদের ২০১৫ সালের গবেষণা (Secrets, Lies, and Account Recovery, WWW ২০১৫) জানায়, security question ব্যবহারকারীর বাছা password-এর চেয়েও দুর্বল, আর একটি বড় অংশ নিজের উত্তর মনে রাখতে পারেননি। নতুন NIST নীতিতে password বাছার সময় এমন প্রশ্ন চাওয়া যাবে না। OWASP-ও একে একমাত্র reset পদ্ধতি হিসেবে ব্যবহার করতে নিষেধ করে।

SMS OTP: ভালো, তবে সীমাসহ

পর্ব ১৬-এর আগে একটি সরাসরি কথা বলে রাখি। SMS-এ পাঠানো OTP মোবাইল ব্যাংকিংসহ অনেক জায়গায় পরিচিত, আর শুধু password-এর চেয়ে অনেক ভালো। কিন্তু এর সীমা আছে। SP 800-63B-4 টেলিফোন নেটওয়ার্কে out-of-band code পাঠানোকে “restricted” বলে: ব্যবহার করা যায়, তবে অন্য authenticator বিকল্পও দিতে হবে। ঝুঁকি মূলত তিনটি: operator-কে ধোঁকা দিয়ে নম্বর সরিয়ে নেওয়া (SIM swap), ফোনে থাকা ক্ষতিকর app, আর ফোনে প্রতারণা করে code জেনে নেওয়া। শেষটির উত্তর এক লাইনে: কোনো কর্মী, ব্যাংক বা অফিস কখনো আপনার OTP চাইবে না। আর SMS code ভুয়া পাতায় টাইপ করলে phishing থেকে রক্ষা দেয় না। এ নিয়ে পরের পর্বে বিস্তারে দেখব।

৮ · মানুষ নয় এমন পরিচয়, আর login log

Service account আর API key

সব login মানুষের নয়। রাত ২টার backup job, payment সেবার সঙ্গে সংযোগ, CI pipeline, এরাও পরিচয় ব্যবহার করে। এগুলোকে বলে non-human identity. এর দুই প্রধান রূপ service account আর API key. বড় প্রতিষ্ঠানে এদের সংখ্যা মানুষের চেয়ে অনেক বেশি হতে পারে, কিন্তু মালিক প্রায়ই অস্পষ্ট।

সমস্যা হলো, মানুষের নিয়ম এখানে হুবহু চলে না। Script-এর ফোনে OTP যায় না। Password সাধারণত কোডে বা config-এ বসে যায়, আর কেউ বদলায় না কারণ “কিছু ভেঙে যাবে”। মানুষ চাকরি ছাড়ে, হিসাব থেকে যায়।

Key rotation নীতি ও secret store দেখতে Secrets ও KMS, আর cloud-এর পরিচয়ের যাচাই দেখতে IAM policy evaluation পড়ুন। Machine-to-machine token পর্ব ১৮-এ, আর vault পর্ব ২০-এ আসবে।

Login log আর alert: কী দেখবেন

রক্ষা ব্যর্থ হতে পারে, তাই দেখার ব্যবস্থা লাগে। প্রতিটি login ঘটনার audit log-এ থাকবে: সময়, হিসাব, উৎস IP, device-এর মোটা বিবরণ, ফল, কারণ, আর কোন factor ব্যবহৃত হলো। থাকবে না: password, OTP, token বা সম্পূর্ণ reset link. OWASP ব্যর্থ login আর lockout নজরে রাখতে বলে।

নিচের Bash ব্লকে একটি নকল log আপনার চোখের সামনে তৈরি হচ্ছে, IP-গুলো নথিপত্রের জন্য সংরক্ষিত ঠিকানা। এই ধরনের প্রশ্ন আপনি নিজের system-এর log-এ করতে পারেন।

cat > auth.log <<'EOF'
02:00:04 login_failed tania 198.51.100.7
02:00:31 login_failed rafiq 198.51.100.7
02:01:02 login_failed sumi 198.51.100.7
02:01:40 login_failed nabil 198.51.100.7
02:02:15 login_failed rahima 198.51.100.7
02:02:49 login_success rahima 198.51.100.7
02:03:20 password_changed rahima 198.51.100.7
09:10:11 login_failed karim 203.0.113.20
09:10:30 login_success karim 203.0.113.20
09:45:02 login_success tania 203.0.113.44
EOF

echo "== distinct accounts failed per ip =="
awk '$2=="login_failed" {print $4, $3}' auth.log | sort -u |
  awk '{n[$1]++} END {for (ip in n) print n[ip], ip}' | sort -rn

echo "== success from an ip that failed on 3+ accounts =="
awk '$2=="login_failed" {k=$4 " " $3; if (!(k in seen)) {seen[k]=1; n[$4]++}}
     $2=="login_success" && n[$4]>=3 {print $1, $3, $4, "REVIEW"}' auth.log

echo "== sensitive change right after that login =="
awk '$2=="login_success" {who[$3 " " $4]=1}
     $2=="password_changed" && (($3 " " $4) in who) {print $1, $3, $4}' auth.log

৯ · AI-এর যুগে login কোড আর নীতি

Login আর reset কোড AI খুব দ্রুত লিখে দেয়, আর দেখতে পরিপাটি হয়। কিন্তু এই পথের ভুল সাধারণ bug-এর মতো নয়। এটি সরাসরি হিসাব-দখলের রাস্তা। আর AI প্রায়ই পুরোনো ইন্টারনেটের অভ্যাস নকল করে।

AI-এর পরামর্শ হাতে পেলে — যাচাইয়ের চেকলিস্ট

• NIST বা OWASP-এর দাবি মূল পাতা খুলে নিজে মিলিয়েছি
• Reset token-এর উৎস, মেয়াদ, একবার ব্যবহার আর hash রাখা দেখেছি
• নিজের test system-এ থাকা ও না-থাকা হিসাবের উত্তর পাশাপাশি মিলিয়েছি
• Prompt-এ কোনো আসল password, key বা ব্যক্তিগত তথ্য দিইনি
• Diff লাইন ধরে পড়েছি, কোনো check বন্ধ করা হয়নি
• Lockout বা হিসাব বন্ধ করার মতো সিদ্ধান্তে শেষ কথা একজন মানুষ দিচ্ছেন