Account-এর কাজ — signup, email যাচাই, password reset আর rate limit

১ · Signup: দরজা খোলা, তথ্য বন্ধ

পর্ব ৪৫ থেকে ৪৮-এ login আর permission দেখেছি। কিন্তু একটি দোকানের account শুধু login নয়। মানুষ নতুন account খোলেন, password ভোলেন, ফোন বদলান, চলেও যান। এই পর্বের বেশিরভাগ বাগ login-এর পাশের এই ছোট পথগুলোতে থাকে, কারণ এগুলো কম চলে আর কম পরীক্ষা হয়।

প্রথম নিয়মের নাম user enumeration ঠেকানো। পর্ব ২১-এ (বড় form) শব্দটি পেয়েছেন: উত্তর দেখে বোঝা যায় কোন email বা ফোন নম্বর এই সাইটে আছে। এই তালিকা দিয়ে প্রতারক বিশ্বাসযোগ্য phishing পাঠান, আর অন্য সাইটের ফাঁস হওয়া password মিলিয়ে দেখেন, যাকে বলে credential stuffing.

Signup-এ সবচেয়ে সাধারণ ভুল হলো এই উত্তর: 409 email already exists. এর সমাধান: email আগে থেকে থাকুক বা না থাকুক, উত্তর একই থাকবে, আর পরের খবরটি যাবে মেইলে। আসল মালিকই শুধু সেই মেইল পড়তে পারেন।

app.post('/api/signup', async (req, res) => {
  const email = norm(req.body.email), pw = req.body.password;
  const bad = await policy(pw);                     // অংশ ২
  if (bad) return res.status(422).json({ error: bad });
  const hash = await argon2.hash(pw, ARGON);        // দুই পথেই একই কাজ
  const r = await q(`INSERT INTO users(email,password_hash) VALUES($1,$2)
                     ON CONFLICT (email) DO NOTHING RETURNING id`, [email, hash]);
  if (r.rowCount) {
    const t = await createToken(r.rows[0].id, 'verify_email', 60 * 24);
    enqueueMail(verifyMail(email, t));
  } else {
    enqueueMail(alreadyHaveAccountMail(email));
  }
  res.status(202).json(ok202);
});

ON CONFLICT দুটি কাজ করে। আগে SELECT করে পরে INSERT করলে race থাকত, আর দুই পথে ডেটাবেসের কাজও আলাদা হতো। argon2.hash দুই পথেই চলে, কারণ এটি এই route-এর সবচেয়ে ধীর ধাপ। Password hash-এর তত্ত্ব আছে Password সংরক্ষণ পর্বে, আর আমরা OWASP-এর সেই ন্যূনতম মান নিয়েছি: Argon2id, m=19456, t=2, p=1.

সত্যিকারের run · Express 5.3.0, PostgreSQL 18.6, Node.js 24.15 · ~/bazarghar · সব ঠিকানা কল্পিত · কোনো মেইল বাইরে যায়নি · বাংলা বার্তা ছাঁটা

POST signup rahim (new)     202 {"message":"অনুরোধ পেয়েছি। …"}
POST signup rahim (again)   202 {"message":"অনুরোধ পেয়েছি। …"}
  MAIL to=rahim@example.com | বাজারঘর: আপনার email যাচাই করুন
  MAIL to=rahim@example.com | বাজারঘর: এই email-এ আগেই account আছে

দুটি উত্তর হুবহু এক। পার্থক্য শুধু মেইলের বাক্সে। এই পর্বের সব পথ একটি Express অ্যাপে চলেছে: ডেটা আসল PostgreSQL-এ, session আর limit আসল Redis 8.10.3-এ, আর মেইল ধরেছে নিজের কম্পিউটারের একটি নকল SMTP server. লেখার সময়ের অন্য version: argon2 0.45.1, redis client 6.3.1. পাতার কোড ল্যাবের কোড থেকে ছোট করা, তাই কিছু সাহায্যকারী function-এর নাম আলাদা।

২ · Password-এর নিয়ম: NIST আসলে কী বলে

অনেক সাইট এখনো বলে “একটি বড় হাতের অক্ষর, একটি সংখ্যা, একটি চিহ্ন”, আর ৯০ দিন পরপর বদলাতে হবে। বর্তমান নির্দেশিকা NIST SP 800-63B-4 (২০২৫) এর উল্টো কথা বলে। নিচের কথাগুলো NIST-এর প্রকাশিত পাতা থেকে মিলিয়ে নেওয়া। এটি মার্কিন সরকারি সংস্থার জন্য লেখা, তবে সারা বিশ্ব একে মানদণ্ড ধরে।

কেন দৈর্ঘ্য? মিশ্র অক্ষরের নিয়ম মানুষকে Password1! এর মতো অনুমেয় ছাঁচে ঠেলে দেয়। প্রতিটি নতুন অক্ষর সম্ভাবনাকে গুণ করে বাড়ায়, তাই লম্বা বাক্যাংশ মনে রাখা সহজ, ভাঙা কঠিন। বাংলা বাক্যাংশও ভালো, কিন্তু একটি ফাঁদ আছে: pw.length UTF-16 ইউনিট গোনে, code point নয়। আর একই লেখা ভিন্ন ফোনে ভিন্ন Unicode ক্রমে আসতে পারে, তাই NIST hash করার আগে NFC normalization করা উচিত বলে। আমাদের [...pw.normalize('NFC')].length এই কাজই করে।

ফাঁস-তালিকা, password না পাঠিয়েই

তালিকা মিলাতে গিয়ে পুরো password বাইরে পাঠালে সেটিই নতুন ফাঁস। সমাধানের নাম k-anonymity ভিত্তিক খোঁজ। Password-এর SHA-1 ছাপের প্রথম ৫টি hex অক্ষর পাঠানো হয়। সেবা ওই শুরুর সব ছাপের বাকি অংশ ফেরায়। মিলটি আপনার server নিজে করে, তাই সেবা জানতেই পারে না কোনটি খোঁজা হলো।

হিসাব: ৫টি hex মানে ১৬^৫ = ১০,৪৮,৫৭৬টি ঝুড়ি। ধরে নিই তালিকায় ১০০ কোটি ছাপ আছে। তাহলে এক ঝুড়িতে গড়ে ১০০ কোটি ÷ ১০,৪৮,৫৭৬ ≈ ৯৫৪টি। সেবা ৯৫৪টির মধ্যে আপনারটি আলাদা করতে পারে না। এখানে SHA-1 গোপনীয়তার জন্য নয়, শুধু তালিকার সূচি হিসেবে। Password জমা রাখা হচ্ছে Argon2id-তেই। ল্যাবে আমরা কোনো বাইরের সেবায় যাইনি। Local একটি নকল তালিকা-সেবা চালিয়েছি, আর সে কী দেখল তা ছেপেছি।

সত্যিকারের run · নকল তালিকা-সেবা, শুধু local · সব password বানানো

signup pw short-pass-12 (13)         422 {"error":"too_short"}
signup pw password1234567 (15, list) 422 {"error":"breached"}
signup pw AAAAaaaa1111!!!!           202 {"message":"অনুরোধ পেয়েছি। …"}
signup pw (বাংলা বাক্যাংশ)              202 {"message":"অনুরোধ পেয়েছি। …"}
 full sha1 of the sample: 648B54E01222585930982009E68112AC270DE1EE
 range requests seen by the list service: /range/5CF9B /range/336F6 /range/648B5 /range/2A64F /range/76DC8

তৃতীয় লাইনটি দেখুন। AAAAaaaa1111!!!! দুর্বল, কিন্তু আমাদের ছোট তালিকায় নেই বলে পাস করেছে। এটি নিয়মের সীমা: তালিকা শুধু জানা জিনিস ধরে। NIST তাই প্রত্যাখ্যানের কারণ জানাতে আর ভালো password বাছাইয়ের পরামর্শ দিতেও বলে। এই 422 উত্তরে email-এর কোনো খবর নেই, কারণ policy চলে ডেটাবেস দেখার আগে।

৩ · Email যাচাই: token, hash আর একবার ব্যবহার

কেউ অন্যের email দিয়ে account খুললে মালিকের বাক্সে আপনার মেইল জমবে, আর পরে সেই মানুষ password reset চাইলে গোলমাল বাধবে। তাই যাচাই লাগে: “এই ঠিকানা আপনার তো?” এর জন্য একটি token মেইলে পাঠানো হয়।

ডাকঘরের রেজিস্ট্রি চিঠির কথা ভাবুন। চিঠিতে একটি গোপন নম্বর, আর ডাকঘরের খাতায় ওই নম্বরের একটি ছাপ। খাতা চুরি হলেও ছাপ থেকে নম্বর পাওয়া যায় না। প্রাপ্ত নম্বরটি একবার দেখালে কাজ শেষ, পরে আর চলে না। Token-এর চারটি নিয়ম এখানেই:

Password-এ Argon2id কিন্তু token-এ সাধারণ SHA-256 কেন? Password মানুষের বানানো, তাই অনুমান করা যায়, আর ধীর hash সেই অনুমানকে দামি করে। ২৫৬ bit এলোমেলো token অনুমানই করা যায় না, তাই ধীর হওয়ার দরকার নেই। দ্রুত hash এখানে ঠিক হাতিয়ার।

Nodemailer আর নিজের নকল SMTP

মেইল পাঠাতে Nodemailer ব্যবহার করব (লেখার সময়ে 10.3.1). আসল ঠিকানায় মেইল পাঠিয়ে শেখা ঠিক নয়। তাই smtp-server package (3.21.3) দিয়ে নিজের কম্পিউটারে একটি SMTP server চালানো হলো, যা মেইল নিয়ে শুধু জমায়। উন্নয়নের সময় Mailpit-এর মতো টুলও এই কাজ করে, তবে এই ল্যাবে সেটি চালানো হয়নি।

import { SMTPServer } from 'smtp-server';
import { simpleParser } from 'mailparser';
import nodemailer from 'nodemailer';

const box = [];
const smtp = new SMTPServer({
  authOptional: true, disabledCommands: ['STARTTLS'],
  onData(stream, session, cb) {
    simpleParser(stream).then((m) => { box.push(m); cb(); }, cb);
  },
});
smtp.listen(38566, '127.0.0.1');

const mailer = nodemailer.createTransport({
  host: '127.0.0.1', port: 38566, secure: false, ignoreTLS: true, // শুধু local ল্যাবে
});
const info = await mailer.sendMail({ from, to, subject, text });

সত্যিকারের run · Nodemailer 10.3.1 আর smtp-server 3.21.3 · মেইল এই কম্পিউটারের বাইরে যায়নি

{
  accepted: [ 'rahim@example.com' ],
  rejected: [],
  response: '250 OK: message queued',
  envelope: { from: 'no-reply@bazarghar.example', to: [ 'rahim@example.com' ] }
}
captured: "বাজারঘর" <no-reply@bazarghar.example> -> rahim@example.com
subject : বাজারঘর: আপনার email যাচাই করুন
text    : যাচাই করতে: https://bazarghar.example/verify-email?token=SAMPLE
headers : from to subject message-id content-transfer-encoding date mime-version content-type

250 OK মানে শুধু “পরের server নিল”, মালিকের হাতে পৌঁছানো নয়। Production-এ ignoreTLS থাকবে না, TLS আর লগইন লাগবে। SPF, DKIM, DMARC আর transactional mail-এর বিস্তার পর্ব ৬৩-তে আসবে, আর তত্ত্ব আছে DNS ও email নিরাপত্তা পর্বে। এবার পুরো পথটি দেখুন। মানগুলো আসল run-এর, ছাঁটা।

POST /api/signup
{ "email": "rahim@example.com", "password": "…" }
উত্তর: 202 {"message":"অনুরোধ পেয়েছি। …"}

purpose    verify_email
token_hash 1e624508a63e1307…
ttl        1 day
used_at    null

to: rahim@example.com
token: Wf-peFIc… (৪৩ অক্ষর)
sha256(token) মিলল db-র সাথে: true

POST /api/login (ঠিক password)
403 {"error":"email_not_verified"}

POST /api/verify-email { token }
UPDATE … SET used_at = now() … RETURNING user_id
200 {"verified":true}

same token    400 {"error":"invalid_or_expired"}
wrong token   400 {"error":"invalid_or_expired"}
expired token 400 {"error":"invalid_or_expired"}

নিচের মডেলে একটি array হলো টেবিল, আর ঘড়িটি নকল, তাই ৩০ মিনিট অপেক্ষা করতে হয় না। crypto আসল। শেষ দুটি লাইনে দেখুন ফাঁস হওয়া ছাপ token হিসেবে চলে কি না।

const { randomBytes, createHash } = require('node:crypto');
let now = 0;                                   // নকল ঘড়ি (মিনিট)
const rows = [];                               // নকল account_tokens টেবিল
const hash = (t) => createHash('sha256').update(t).digest('hex');

function issue(userId) {
  const token = randomBytes(32).toString('base64url');
  rows.push({ userId, tokenHash: hash(token), expiresAt: now + 30, usedAt: null });
  return token;                                // শুধু mail-এ যাবে
}
function consume(token) {
  const h = hash(token);
  const row = rows.find((r) => r.tokenHash === h);
  if (!row) return 'invalid';
  if (row.usedAt !== null) return 'invalid';   // তিনটি পথেই একই উত্তর
  if (row.expiresAt <= now) return 'invalid';
  row.usedAt = now;
  return 'ok';
}
const a = issue(42);
console.log('token length :', a.length);
console.log('stored       :', Object.keys(rows[0]).join(','));
console.log('raw in table :', JSON.stringify(rows).includes(a));
now = 5;
console.log('t=5  use     :', consume(a));
now = 6;
console.log('t=6  reuse   :', consume(a));
console.log('t=6  garbage :', consume('x'.repeat(43)));
const b = issue(42);
now = 40;                                      // ৩৪ মিনিট পরে
console.log('t=40 expired :', consume(b));
const c = issue(42);
const leaked = rows[2].tokenHash;              // ধরুন টেবিল ফাঁস হলো
console.log('t=40 use hash:', consume(leaked));
console.log('t=40 real one:', consume(c));

৪ · Password reset: একই উত্তর, একই সময়, একবার

Reset হলো password ছাড়াই account-এ ঢোকার বৈধ পথ। তাই এটি login-এর মতোই গুরুত্বপূর্ণ। প্রথমে উত্তর। জানা আর অজানা email-এ একই লেখা, একই status. নিচের আসল node:http server-এ ভুল আর ঠিক, দুটি পথই আছে।

const http = require('node:http');
const users = new Set(['rahim@example.com']);
let mailsSent = 0, jobs = 0;
const body = JSON.stringify({ message: 'If that address is right, a mail is on its way.' });

function naive(email, res) {                    // ভুল নকশা
  if (!users.has(email)) { res.statusCode = 404; return res.end('{"error":"no such user"}'); }
  mailsSent++; res.end(body);
}
function uniform(email, res) {                  // একই উত্তর, কাজ পরে
  jobs++;
  setImmediate(() => { if (users.has(email)) mailsSent++; });
  res.statusCode = 202; res.end(body);
}
const server = http.createServer((req, res) => {
  let raw = ''; req.on('data', (c) => (raw += c));
  req.on('end', () => (req.url === '/naive' ? naive : uniform)(JSON.parse(raw).email, res));
});
server.listen(0, '127.0.0.1', async () => {
  const url = `http://127.0.0.1:${server.address().port}`;
  const ask = async (path, email) => {
    const r = await fetch(url + path, { method: 'POST', body: JSON.stringify({ email }) });
    return `${r.status} ${await r.text()}`;
  };
  const list = ['rahim@example.com', 'ghost@example.com'];
  for (const path of ['/naive', '/uniform']) {
    const [k, u] = [await ask(path, list[0]), await ask(path, list[1])];
    console.log(path.padEnd(9), 'same answer:', k === u);
    console.log('  known  :', k.slice(0, 44));
    console.log('  unknown:', u.slice(0, 44));
  }
  await new Promise((r) => setImmediate(r));
  console.log('mails sent:', mailsSent, ' jobs queued:', jobs);
  server.close();
});

লেখা এক হলেও সময় কথা বলে

উত্তর এক হলেই শেষ নয়। জানা email-এ যদি মেইল পাঠিয়ে তবে উত্তর দেন, সময় বেশি লাগবে। এই পার্থক্য দিয়ে তথ্য বের করাকে বলে timing leak. আমরা একই Express অ্যাপে তিনটি নকশা মাপলাম, প্রতিটিতে ২০০ জোড়া অনুরোধ, পালা করে।

সত্যিকারের run · একটি local কম্পিউটারে একবার · network নেই · এটি সাধারণ ফল নয় · limiter বন্ধ রেখে মাপা

naive login   known    n=200 p50   21.81 ms  p95   27.10 ms
naive login   unknown  n=200 p50    1.05 ms  p95    1.59 ms
              p50 gap 20.76 ms
fixed login   known    n=200 p50   21.48 ms  p95   25.21 ms
fixed login   unknown  n=200 p50   21.36 ms  p95   24.89 ms
              p50 gap 0.12 ms
naive forgot  known    n=200 p50  107.10 ms  p95  119.91 ms
naive forgot  unknown  n=200 p50    0.92 ms  p95    1.43 ms
              p50 gap 106.18 ms
mail later    known    n=200 p50    0.95 ms  p95    1.46 ms
mail later    unknown  n=200 p50    0.53 ms  p95    0.89 ms
              p50 gap 0.42 ms
all later     known    n=200 p50    0.37 ms  p95    0.63 ms
all later     unknown  n=200 p50    0.37 ms  p95    0.72 ms
              p50 gap 0.01 ms

তিনটি শিক্ষা। Login-এ অজানা email-এ password hash না করলে ২০ ms-এর ফাঁক হয়, যা জানা email-এর ঠিক argon2.verify-এর সময়। সমাধান: অজানা হলেও একটি নকল hash-এর সাথে verify চালানো। Reset-এ SMTP-র অপেক্ষাই ১০৬ ms বাড়িয়েছে। শুধু মেইল পরে পাঠালেও ০.৪২ ms রয়ে গেল, কারণ জানা email-এ দুটি বাড়তি ডেটাবেস লেখা আছে। ফাঁক ছোট, কিন্তু বহু নমুনায় গড় নিলে ছোট ফাঁকও ধরা পড়ে। সবচেয়ে পরিষ্কার সমাধান হলো উত্তরকে অস্তিত্বের ওপর নির্ভরই করতে না দেওয়া।

app.post('/api/forgot', (req, res) => {
  const email = norm(req.body.email);
  later(() => forgotJob(email, req));   // উত্তরের পরে, durable queue-তে (পর্ব ৬২)
  res.json(ok202);
});

async function forgotJob(email, req) {
  const u = await findActiveUser(email);
  const lim = await limiter.hit(`rl:forgot:${acctId(email)}`, 60 * M, 4); // মেইল-বোমা ঠেকায়
  if (!u || lim.over) return;
  const raw = newToken();
  await cancelOldResetTokens(u.id);
  await saveToken(u.id, 'reset', hashToken(raw), '30 min');
  enqueueMail(resetMail(email, `${APP_URL}/reset-password?token=${raw}`));
}

লিংকের ঠিকানা আসে config-এর APP_URL থেকে, অনুরোধের Host header থেকে নয়। Host থেকে বানালে কেউ ভুয়া header পাঠিয়ে আসল মালিকের মেইলে নিজের সাইটের লিংক ঢোকাতে পারতেন, যাকে বলে host header injection. আসল run-এ ভুয়া X-Forwarded-Host দিয়েও মেইলের লিংক ছিল https://bazarghar.example.

forgot known    200 {"message":"অনুরোধ পেয়েছি। …"}
forgot unknown  200 {"message":"অনুরোধ পেয়েছি। …"}
bodies identical: true  status equal: true

UPDATE account_tokens SET used_at = now() -- পুরোনো reset
INSERT … purpose = 'reset', expires ৩০ মিনিট
MAIL to=rahim@example.com | বাজারঘর: password নতুন করুন

GET /reset-password?token=…
Referrer-Policy: no-referrer
Cache-Control: no-store

POST /api/reset { token, password }
BEGIN; UPDATE … used_at … RETURNING;
UPDATE users SET password_hash …; COMMIT;
উত্তর: 200 {"ok":true,"sessionsEnded":2}

reset, same token again  400 {"error":"invalid_or_expired"}

GET me, old phone session   401 {"error":"not_signed_in"}
GET me, old laptop session  401 {"error":"not_signed_in"}

login with old password  401 {"error":"invalid_credentials"}
login with new password  200 {"ok":true}
MAIL to=rahim@example.com | বাজারঘর: আপনার password বদলেছে

“একবারই” কথাটি race-এও সত্য হতে হবে

অসাবধান কোড আগে SELECT করে দেখে token ঠিক আছে, তারপর ধীর password hash, শেষে used_at বসায়। মাঝের ২০ ms-এ বাকি অনুরোধও পাস করে যায়। এটি পর্ব ৪৩-এর (Application-এ transaction) সেই race condition. একই token-এ ১২টি অনুরোধ একসাথে পাঠিয়ে দেখলাম।

সত্যিকারের run · তিন দফা · local কম্পিউটারে একবার

check-then-act   round 1 200: 6 400: 6
check-then-act   round 2 200: 11 400: 1
check-then-act   round 3 200: 12 400: 0
atomic UPDATE    round 1 200: 1 400: 11
atomic UPDATE    round 2 200: 1 400: 11
atomic UPDATE    round 3 200: 1 400: 11

UPDATE account_tokens SET used_at = now()
 WHERE token_hash = $1 AND purpose = $2
   AND used_at IS NULL AND expires_at > now()
RETURNING user_id, new_value;

যাচাই আর ব্যবহার একই statement-এ, তাই PostgreSQL-এর row lock একজনকেই জিততে দেয়। Hash-এর তুলনা ডেটাবেসের index-এ, আর purpose মেলানোয় email যাচাইয়ের token দিয়ে password reset করা যায় না। মেয়াদ ফুরানো সারি মুছতে একটি নির্ধারিত কাজ রাখুন।

৫ · Email, ফোন বদল আর বাংলাদেশে phone OTP

Account দখলের পর প্রথম কাজ হয় যোগাযোগের ঠিকানা বদলানো, যাতে আসল মালিক reset করতে না পারেন। তাই বদলের পথে চারটি নিয়ম:

1. আবার পরিচয়: session থাকলেও বর্তমান password চাইতে হবে, যাকে বলে reauthentication. খোলা ল্যাপটপে কেউ বসলে এতে আটকাবে।
2. নতুন ঠিকানায় প্রমাণ: নতুন ঠিকানা token দিয়ে নিশ্চিত হওয়ার আগে কিছু বদলাবে না।
3. পুরোনো ঠিকানায় নোটিশ: মালিক দেখতে পাবেন, আর দাবি জানাতে পারবেন।
4. বদলের পরে session শেষ: সব ডিভাইস আবার login করবে।

সত্যিকারের run · email বদল · শুধু local SMTP

change, wrong password  401 {"error":"reauth_failed"}
change, right password  202 {"pending":true}
  MAIL to=rahim.new@example.com | বাজারঘর: নতুন email নিশ্চিত করুন
  MAIL to=rahim@example.com | বাজারঘর: email বদলের অনুরোধ
 email now: rahim@example.com          <- এখনো পুরোনো
confirm                 200 {"ok":true,"sessionsEnded":1}
 email now: rahim.new@example.com

Phone OTP: বাস্তব প্রয়োজন, আর তার সীমা

বাংলাদেশে অনেক ক্রেতার কাছে email-এর চেয়ে ফোন নম্বরই প্রধান পরিচয়, তাই OTP প্রায়ই দরকার হয়। নিয়মগুলো আগে দেখুন। NIST ফোন নেটওয়ার্কের OTP-কে restricted বলে, মানে চলতে পারে, কিন্তু ঝুঁকি বিচার করতে হবে আর বিকল্প দিতে হবে। SIM swap এর একটি কারণ। SMS gateway-র দাম, sender ID আর BTRC-র নিয়ম সময়ে বদলাতে পারে, তাই নিজের চুক্তি আর বর্তমান নিয়ম দেখে নেবেন।

শেষ সারিটিতে ফাঁদ আছে। ৬ অঙ্কের মাত্র ১০ লাখ মান। সাধারণ SHA-256 ছাপ ফাঁস হলে মুহূর্তেই সব মান চেষ্টা করে কোড বের করা যায়। তাই গোপন key-সহ HMAC, যে key Redis-এর বাইরে থাকে। আর লিংকের token-এর সাথে পার্থক্যটি মনে রাখুন: token-এ ২৫৬ bit, তাই সাধারণ hash যথেষ্ট; OTP-তে ২০ bit-এরও কম, তাই গোপন key আর চেষ্টার সীমা দুটোই লাগে।

সত্যিকারের run · দুটি run-এর লাইন একসাথে · নকল gateway, কোনো SMS যায়নি · নম্বর কল্পিত · কোড ঢেকে দেওয়া

start          202 {"sent":true,"ttl":300,"failsSoFar":0}
resend at once 429 {"error":"wait_before_resend"}
 gateway got: 01700000000 বাজারঘর কোড: ******. ৫ মিনিট বৈধ। কাউকে বলবেন না।
 redis hash: phone=01700000000 mac=7e5ccd2d2201d684… ttl 300
wrong 1        400 {"error":"invalid_or_expired","triesLeft":4}
right          200 {"ok":true}
 … অন্য কোডে পরপর ভুল …
wrong 5        400 {"error":"invalid_or_expired","triesLeft":0}
wrong 6        429 {"error":"too_many_wrong_codes"}
 after resend  {"sent":true,"ttl":300,"failsSoFar":3}   <- ভুলের গণনা থেকে গেল
 wrong again   {"error":"invalid_or_expired","triesLeft":1}

হিসাব: অনুমান আর খরচ

অনুমানের সম্ভাবনা। একটি কোডে ৫ বার চেষ্টা: ৫ ÷ ১০,০০,০০০ = ০.০০০৫%. দিনে ৫টি কোড ধরলে সর্বোচ্চ ২৫ চেষ্টা, অর্থাৎ ০.০০২৫%. সারা বছর একটি নম্বরে চালিয়ে গেলে ২৫ × ৩৬৫ = ৯,১২৫ চেষ্টা, সম্ভাবনা ১ − (১ − ১০^−৬)^৯১২৫ ≈ ০.৯১%. সীমা না থাকলে এই সংখ্যা ১০০%-এর দিকে যেত।

খরচ (অনুমান, কোনো gateway-র দাম নয়): ধরে নিই প্রতি SMS ৳০.৫০. প্রতিদিন ২০,০০০ signup, গড়ে ১.৩ বার পাঠানো: ২০,০০০ × ১.৩ × ০.৫০ = ৳১৩,০০০. এখন সীমা নেই এমন endpoint-এ একটি script সেকেন্ডে একটি অনুরোধ করে: ৮৬,৪০০ × ০.৫০ = ৳৪৩,২০০ দিনে, আসল ব্যবসার তিন গুণের বেশি। প্রতি IP-তে ঘণ্টায় ৫টি সীমা দিলে সেই IP থেকে ১২০ × ০.৫০ = ৳৬০. এই ধরনের অপব্যবহারের একটি বড় রূপের নাম SMS pumping. বাংলা SMS Unicode-এ যায়, তাই এক ভাগে ৭০ অক্ষর ধরে, ইংরেজির ১৬০ নয়। লম্বা বাংলা বার্তা দুই ভাগ হয়ে খরচ বাড়তে পারে। ফোনে নিজে কোড পূরণ করতে autocomplete="one-time-code" দিন।

৬ · TOTP আর recovery code

MFA-র তত্ত্ব আছে MFA ও passkey পর্বে, সেখানে দেখবেন কেন passkey সবচেয়ে phishing-প্রতিরোধী। এখানে আমরা সহজে চালু করা যায় এমন TOTP বানাব। Server আর ফোনের app একটি গোপন secret ভাগ করে। দুজনেই বর্তমান সময়কে ৩০ সেকেন্ডের ধাপে ভাগ করে, secret দিয়ে HMAC করে, আর ৬ অঙ্ক বের করে। কোনো network লাগে না। RFC 4226 (২০০৫) HOTP দেয়, আর RFC 6238 (২০১১) তার ওপর সময় বসায়।

const { createHmac } = require('node:crypto');

function hotp(secret, counter, digits, algo) {
  const c = Buffer.alloc(8);
  c.writeBigUInt64BE(BigInt(counter));
  const mac = createHmac(algo, secret).update(c).digest();
  const off = mac[mac.length - 1] & 0x0f;       // dynamic truncation
  const n = mac.readUInt32BE(off) & 0x7fffffff;
  return String(n % 10 ** digits).padStart(digits, '0');
}
const totp = (secret, t, digits = 8, algo = 'sha1', step = 30) =>
  hotp(secret, Math.floor(t / step), digits, algo);

// RFC 6238 Appendix B-এর test vector
const sha1 = Buffer.from('12345678901234567890');
const sha256 = Buffer.from('12345678901234567890123456789012');
const sha512 = Buffer.from('1234567890'.repeat(6) + '1234');
const v = [
  [59, '94287082', '46119246', '90693936'],
  [1111111109, '07081804', '68084774', '25091201'],
  [1234567890, '89005924', '91819424', '93441116'],
  [2000000000, '69279037', '90698825', '38618901'],
  [20000000000, '65353130', '77737706', '47863826'],
];
for (const [t, a, b, c] of v) {
  const got = [totp(sha1, t), totp(sha256, t, 8, 'sha256'), totp(sha512, t, 8, 'sha512')];
  const ok = got[0] === a && got[1] === b && got[2] === c;
  console.log(String(t).padEnd(12), got.join(' '), ok ? 'PASS' : 'FAIL');
}
console.log('six digits at t=59 :', totp(sha1, 59, 6));
console.log('t=60 is a new step :', totp(sha1, 60, 6));

এবার আসল অ্যাপে। পাঁচটি জিনিস খেয়াল করুন: secret database-এ AES-256-GCM দিয়ে এনক্রিপ্ট করা, কারণ server-কে আসল secret দরকার, তাই hash চলে না; প্রথম সঠিক কোড না দেওয়া পর্যন্ত TOTP চালু হয় না; recovery code-এর শুধু ছাপ জমে; একই কোড দ্বিতীয়বার চলে না; আর সময়ের ছাড় শুধু আগের এক ধাপ, যা RFC 6238-এর সুপারিশ।

সত্যিকারের run · otplib 13.6.0 · secret কেটে দেখানো · সব account কল্পিত

 secret: ZX27O2LK… length 32
 uri: otpauth://totp/Bazarghar:rahim.new%40example.com?secret=<secret>&issuer=Bazarghar
 in db: kbJOkmBJ7i/2Kjwc… enabled false contains plain secret: false
confirm wrong             400 {"error":"wrong_code"}
 confirm right 200 codes 10 sample XXXX-XXXX-XXXX-XXXX
login no code             401 {"error":"totp_required"}
login same code (replay)  401 {"error":"invalid_credentials"}
 waiting 12 s for the next 30 s step
login fresh code          200 {"ok":true}
same fresh code again     401 {"error":"invalid_credentials"}
 recovery first use 200 ok true replacement issued true
recovery second use       401 {"error":"invalid_credentials"}
 recovery_codes: { live: 10, total: 11 }

totp_last_step কলামে শেষ ব্যবহৃত ধাপ থাকে, আর নতুন login-এ UPDATE … WHERE totp_last_step < $2 শর্ত থাকে। NIST আর RFC 6238 দুটোই বলে একই OTP একবারের বেশি নেওয়া যাবে না। ফোন হারালে recovery code কাজে আসে। আমাদের প্রতিটি ৮০ bit, ১৬ অক্ষর, চার-চার ভাগে। NIST-এর শর্ত: অন্তত ৬৪ bit, hash করে জমা, ব্যবহারের পরে বাতিল, আর একটি নতুন code দেওয়া। Run-এর live: 10, total: 11 সেটিই দেখাচ্ছে। Code-গুলো একবারই দেখান, আর ব্যবহার হলে মেইলে জানান।

৭ · Login rate limit: IP, account আর lockout-এর ফাঁদ

পর্ব ২৬-এ (Middleware) rate limit-এর ধারণা, আর পর্ব ৪৪-এ (Cache আর Redis) Redis counter দেখেছেন। Login-এ একটি counter যথেষ্ট নয়, কারণ দুই রকম অপব্যবহার দুই দিক থেকে আসে:

• এক IP, বহু account: একটি সাধারণ password অনেক account-এ চেষ্টা, যাকে বলে password spraying. প্রতি account-এ চেষ্টা কম, তাই account-এর গণনায় ধরা পড়ে না।
• বহু IP, এক account: প্রতি IP-র গণনা কম, তাই IP limit ধরে না। এখানে account-এর গণনা লাগে।

Counter-টি sliding window-এ চলে। সাধারণ fixed window মিনিট বদলের মুহূর্তে শূন্য হয়, তাই সীমানার দুই পাশে দ্বিগুণ চেষ্টা ঢুকে যায়। নিচের মডেল সেটি দেখায়। ঘড়ি নকল, আর Redis-এর বদলে array.

// নকল ঘড়ি: সময় সেকেন্ডে। Redis-এর sorted set-এর বদলে একটি array
function slidingWindow(limit, windowSec) {
  const hits = new Map();
  return (key, now) => {
    const list = (hits.get(key) ?? []).filter((t) => t > now - windowSec);
    hits.set(key, list);
    if (list.length >= limit) return { ok: false, retry: list[0] + windowSec - now };
    list.push(now);
    return { ok: true, used: list.length };
  };
}
function fixedWindow(limit, windowSec) {
  const counts = new Map();
  return (key, now) => {
    const k = `${key}:${Math.floor(now / windowSec)}`;
    const n = (counts.get(k) ?? 0) + 1;
    counts.set(k, n);
    return { ok: n <= limit };
  };
}
const times = [58, 58, 59, 59, 59, 60, 60, 60, 61, 61];   // মিনিটের সীমানায় ১০টি চেষ্টা
const sw = slidingWindow(5, 60), fw = fixedWindow(5, 60);
const count = (fn) => times.filter((t) => fn('acct:42', t).ok).length;
console.log('attempts in 4 seconds :', times.length);
console.log('fixed window allowed  :', count(fw));
console.log('sliding window allowed:', count(sw));

const s2 = slidingWindow(3, 60);
for (const t of [0, 10, 20, 30, 59, 61, 70, 71, 82]) {
  const r = s2('ip:203.0.113.9', t);
  console.log(`t=${String(t).padStart(2)}`, r.ok ? `allowed (${r.used}/3)` : `blocked, wait ${r.retry}s`);
}

আসল অ্যাপে একই যুক্তি Redis-এর sorted set-এ, সময়কে score ধরে। পুরো ধাপটি একটি Lua script, তাই দুটি server-এর মাঝে race হয় না, আর সময় আসে Redis-এর TIME থেকে, যাতে সব server একই ঘড়ি দেখে।

local key, window, limit = KEYS[1], tonumber(ARGV[1]), tonumber(ARGV[2])
local t = redis.call('TIME')
local now = t[1] * 1000 + math.floor(t[2] / 1000)
redis.call('ZREMRANGEBYSCORE', key, 0, now - window)
local n = redis.call('ZCARD', key)
if ARGV[3] == 'hit' then
  redis.call('ZADD', key, now, now .. ':' .. ARGV[4])
  redis.call('PEXPIRE', key, window)
  n = n + 1
end
return n

একটি সতর্কতা: req.ip তখনই ঠিক, যখন trust proxy আপনার নিজের proxy পর্যন্তই সেট করা। নইলে যে কেউ X-Forwarded-For বদলে প্রতি অনুরোধে নতুন IP সাজতে পারেন। বাংলাদেশে মোবাইল নেটওয়ার্কে বহু গ্রাহক একই সার্বজনীন IP-তে থাকতে পারেন, তাই খুব কড়া IP limit সৎ ক্রেতাকেও আটকাতে পারে।

Lockout নাকি backoff

পুরোনো সমাধান account lockout: ৫ বার ভুল হলে account ১৫ মিনিট বন্ধ। সমস্যা হলো, চাবি থাকে হামলাকারীর হাতে। যে কেউ আপনার email জানলে ইচ্ছামতো আপনাকে বাইরে রাখতে পারেন। এটি একটি denial of service. তাই account-এ নয়, account আর IP-র জোড়ায় অপেক্ষা বাড়ানো ভালো: ভুলকারী নিজেই ধীর হন, মালিক নন। অপেক্ষা ৩০ সেকেন্ড থেকে দ্বিগুণ হতে হতে সর্বোচ্চ ১ ঘণ্টা, যা NIST-এর দেওয়া উদাহরণের সীমার মধ্যেই।

ভুলকারী  IP 203.0.113.9   (password জানেন না)
মালিক    IP 198.51.100.7  (ঠিক password জানেন)
account  rahim@example.com

401 401 401 401 401

lockout : 429(wait 900s) 429(wait 900s) 429(wait 900s)
backoff : 429(wait 30s)  429(wait 30s)  429(wait 30s)

429 {"error":"too_many_attempts","why":"account_lock"}
Retry-After 900

200 {"ok":true}

401:invalid_credentials  50
403:step_up_required      5  প্রথমটি ৫১তম চেষ্টায়
মালিক: 403 {"error":"step_up_required"}

সত্যিকারের run · Redis 8.10.3 · limiter চালু · সব email ও IP কল্পিত

--- one IP, many accounts (35)
 status counts { '401': 30, '429': 5 } first 429 at try 31
--- unknown account behaves the same
  rahim@example.com    401 401 401 401 401 429 429
  ghost@example.com    401 401 401 401 401 429 429
--- redis keys after 3 failures
  rl:acct:c9cf28d93acf3625 zset 3 pttl 3599997
  rl:ip:203.0.113.60 zset 3 pttl 599996
  rl:pair:c9cf28d93acf3625:203.0.113.60 string 3 pttl 3599995

মাঝের দুটি লাইন খুব জরুরি। অজানা ghost-ও ঠিক একই সময়ে 429 পায়। Limit যদি শুধু আসল account-এ বসত, তবে limiter নিজেই enumeration-এর পথ হতো। Key-তে email-এর বদলে keyed hash, তাই Redis-এ ঠিকানা জমে না। NIST-এর ঊর্ধ্বসীমা হলো পরপর ১০০ ব্যর্থতা, এর চেয়ে কম রাখতে বাধা নেই। Login-এর এই limit Redis বন্ধ হলে কী করবে, তা আগে ঠিক করুন। পর্ব ৪৪-এর fail open cache-এ চলে, কিন্তু login-এ পুরো খোলা ছেড়ে দিলে ঝুঁকি। প্রতি process-এর একটি ছোট in-memory সীমা মাঝামাঝি পথ, যা এই ল্যাবে চালানো হয়নি।

৮ · Account মোছা, ডেটা রাখা আর audit trail

“আমার account মুছে দিন” শুনতে একটি DELETE মনে হয়। কিন্তু বাজারঘরে ওই ক্রেতার order আছে, হিসাবের দরকারে যা রাখতে হতে পারে। তাই মোছা দুই ধাপে। প্রথম ধাপে account বন্ধ, session শেষ, আর ফেরার একটি সময় (এই ল্যাবে ৩০ দিন, যা আমাদের নিজের ধরে নেওয়া মান)। দ্বিতীয় ধাপে একটি নির্ধারিত কাজ ব্যক্তিগত তথ্য মুছে দেয়, আর order একটি নামহীন সারির সাথে থাকে। পর্ব ৪১-এর (সম্পর্ক) soft delete এখানে শুধু প্রথম ধাপ। সেটিকেই মোছা বলে দাবি করা ঠিক নয়।

সত্যিকারের run · সময় বদলাতে deleted_at ৩১ দিন পিছিয়ে দেওয়া হয়েছে · সারি ছাঁটা

delete, wrong password  401 {"error":"reauth_failed"}
delete, right password  202 {"scheduled":true}
GET me after delete     401 {"error":"not_signed_in"}
login after delete      401 {"error":"invalid_credentials"}
purge, 30 day grace     200 {"purged":0}
purge, 31 days later    200 {"purged":1}

 id | email             | password_hash | phone | totp_enabled
 1  | deleted+1@invalid | null          | null  | false
 orders: id 1 | user_id 1 | total_paisa 125000

Audit trail আর ব্যবহারকারীকে জানানো

“কে, কখন, কোথা থেকে, কী করলেন”, এই হিসাবই audit trail. চায়ের দোকানের বাকির খাতার মতো: পাতা ছেঁড়া যায় না, শুধু নতুন লাইন বসে। Log-এর গঠন পর্ব ৩১-এ (Log আর config) দেখেছেন, কিন্তু audit আলাদা: ব্যবসা আর নিরাপত্তার প্রমাণ, তাই আলাদা টেবিল, শুধু যোগ করার অনুমতি। এতে token, password বা কোড কখনো নয়। আমরা user id-র বদলে keyed ছদ্মনাম রেখেছি, যাতে মুছে ফেলার পরেও ঘটনার হিসাব থাকে, কিন্তু সরাসরি মানুষ চেনা না যায়। ছদ্মনামও সাধারণত ব্যক্তিগত তথ্যের মধ্যেই ধরা হয়, তাই এরও মেয়াদ লাগে।

সত্যিকারের run · একই account-এর পুরো জীবন, ঘটনার সংখ্যাসহ · নোটিশের শেষ দুটি লাইন আলাদা run থেকে

signup                   1
email_verified           1
login_ok                 5
reset_requested          2
password_reset           1
login_failed             1
email_change_requested   1
email_changed            1
phone_changed            1
2fa_enabled              1
recovery_code_used       2
delete_requested         1
purged                   1
secrets in audit_log: 0
--- sign-in notice
first time on Laptop/1: [ 'বাজারঘর: নতুন জায়গা থেকে login' ]
second time on Laptop/1: []

নোটিশ পাঠান password, email, ফোন বা MFA বদলে, recovery code ব্যবহারে, আর নতুন জায়গা থেকে login-এ। NIST recovery-র পরে নোটিশ বাধ্যতামূলক করেছে, আর নোটিশে দাবি জানানোর পরিষ্কার পথ দিতে বলে। নতুন ডিভাইস চিনতে এই ল্যাব browser আর IP-র একটি hash রেখেছে, যা সহজ কিন্তু মোবাইল IP বদলালে বাড়তি মেইল দেবে। মেইলে এমন লিংক দেবেন না যা ক্লিক করলেই কিছু ঘটে।

৯ · AI-এর যুগে account flow

“Forgot password বানিয়ে দাও” বললে AI কয়েক সেকেন্ডে এমন কোড দেয় যা চলে। এখানেই বিপদ: এই পথের ভুলগুলোতে কোনো error আসে না, আর সাধারণ ব্যবহারে সব ঠিক দেখায়।

AI-এর লেখা account কোড হাতে পেলে

• দুটি email-এ, জানা ও অজানা, status, body আর header মিলিয়ে দেখেছি
• অন্তত ২০০ জোড়া অনুরোধে সময়ের p50 মেপেছি
• ডেটাবেসে token, OTP আর recovery code-এর সারি চোখে দেখেছি
• একই token-এ সমান্তরাল অনুরোধ পাঠিয়েছি, একটিই সফল হয়েছে
• Reset-এর পরে পুরোনো cookie দিয়ে অনুরোধ করে 401 পেয়েছি
• প্রতিটি নতুন package npm-এ আছে, আর API আমার version-এর docs-এ মিলিয়েছি
• Log আর audit টেবিলে token, password বা OTP খুঁজে দেখেছি, কিছু নেই