Session আর token — cookie, JWT আর নিরাপদ logout

১ · HTTP মনে রাখে না, তাই session লাগে

HTTP নিজে থেকে আগের কথা মনে রাখে না। প্রতিটি request নতুন, যেন আগের সঙ্গে কোনো সম্পর্ক নেই। একে বলে stateless. Password যাচাই হলো একবার, কিন্তু পরের ক্লিকে server আর জানে না আপনি কে। প্রতি ক্লিকে password পাঠানো বিপজ্জনক, ঝামেলারও। তাই login-এর পর server একটি ছোট প্রমাণ দেয়। পরের প্রতিটি request সেই প্রমাণ সঙ্গে নিয়ে আসে। এই ধারাবাহিক পরিচয়ের নামই session.

System design-এর দিক থেকে session store কীভাবে মাপবেন, কীভাবে ভাগ করবেন, তা আছে System Design কোর্সের session পর্বে. এখানে আমরা দেখব নিরাপত্তার দিক।

২ · Session ID: এলোমেলো, লম্বা আর login-এর পরে নতুন

Server-side session-এ browser পায় শুধু একটি session ID. এর কাজ একটাই, store-এর একটি সারি খুঁজে দেওয়া। তাই এতে কোনো অর্থ থাকবে না: ব্যবহারকারীর নম্বর, সময় বা email নয়। তিনটি শর্ত মনে রাখুন।

• এলোমেলো: ID আসবে CSPRNG থেকে, যেমন Python-এর secrets. সাধারণ random বা ক্রমিক সংখ্যা চলবে না।
• যথেষ্ট লম্বা: OWASP Session Management Cheat Sheet ন্যূনতম ৬৪ bit entropy চায়, মানে পুরো এলোমেলো হলে ১৬টি hex অক্ষর। NIST SP 800-63B (Revision 4, ২০২৫)-ও session secret-এর জন্য অন্তত ৬৪ bit চায়। ১২৮ bit বা ২৫৬ bit নিতে খরচ প্রায় নেই, তাই বেশিই নিন।
• পুরোটাই এলোমেলো: লম্বা ID-র অর্ধেক স্থির হলে শক্তিও অর্ধেক নয়, তার চেয়েও খারাপ। ১৬ hex অক্ষরের ৮টি স্থির হলে থাকে ৩২ bit.

অনুমান করতে কত সময় লাগবে?

হিসাবটি সহজ। ধরুন ID-তে b bit entropy, আক্রমণকারী প্রতি সেকেন্ডে rটি অনুমান পাঠাতে পারে, আর একই সময়ে Sটি session বৈধ। প্রতি অনুমানে সফল হওয়ার সম্ভাবনা S / 2^b. তাই যেকোনো একটি session মেলাতে গড় অনুমান 2^b / S, আর গড় সময়:

লক্ষ করুন, S যত বড়, লক্ষ্য তত সহজ, কারণ যেকোনো একজনের session মিললেই ক্ষতি। নিচের হিসাবে r = 10,000 আর S = 100,000 ধরা হয়েছে। দুটোই ধরে নেওয়া মান।

// গড় অনুমান-সময়: E = 2^b / (r × S)
const r = 1e4;     // প্রতি সেকেন্ডে অনুমান (ধরে নেওয়া মান)
const S = 1e5;     // একসঙ্গে বৈধ session (ধরে নেওয়া মান)
const YEAR = 365.25 * 24 * 3600;

function pretty(sec) {
  if (sec < 3600) return sec.toFixed(1) + " seconds";
  return (sec / YEAR).toExponential(2) + " years";
}

console.log("bits  hex-chars  base64url-chars  expected time");
for (const b of [32, 64, 128]) {
  const hex = String(b / 4).padEnd(10);
  const b64 = String(Math.ceil(b / 6)).padEnd(16);
  const sec = 2 ** b / (r * S);
  console.log(String(b).padEnd(5), hex, b64, pretty(sec));
}

// rate limit করলে r কমে: 64 bit, 10 অনুমান/সেকেন্ড
console.log("64 bit, r=10/s:", pretty(2 ** 64 / (10 * S)));

import hashlib, secrets

sid = secrets.token_urlsafe(32)                 # 256 bit, cookie-তে যাবে
sid_hash = hashlib.sha256(sid.encode()).hexdigest()   # store-এ শুধু এটি

এই উদাহরণের দ্বিতীয় লাইনটি একটি ভালো অভ্যাস। Store-এ ID-র বদলে তার SHA-256 রাখলে store ফাঁস হলেও সেখান থেকে চালু cookie পাওয়া যায় না। ID নিজেই ২৫৬ bit এলোমেলো, তাই এখানে পর্ব ১৩-এর ধীর hash লাগে না। পর্ব ৯-এর দ্রুত hash-ই যথেষ্ট। Log-এ কাঁচা ID কখনো নয়। OWASP salt দেওয়া hash লিখতে বলে, যাতে ঘটনা মেলানো যায়, কিন্তু ID হাতে না আসে।

Session fixation: ধারণা আর প্রতিরক্ষা

Session fixation-এ সমস্যাটি চুরি নয়, উল্টো। কোনো কারণে ব্যবহারকারীর browser-এ আগে থেকেই এমন একটি ID বসে আছে, যা অন্য কেউ জানেন। Login-এর পর server যদি সেই ID-টিই রেখে দেয় আর তাকে “লগইন করা” বলে ধরে, তাহলে জানা ID-টি সরাসরি লগইন করা session হয়ে যায়। ভুলটি ID নিয়ে নয়, ভুল হলো পরিচয় বদলানোর সময় ID না বদলানো।

প্রতিরক্ষা সোজা:

• Login, password বদল, role বদল, অর্থাৎ যেকোনো privilege বদলে নতুন ID, পুরোনোটি server-এ মুছে ফেলা।
• শুধু server-এর তৈরি ID গ্রহণ করা। অচেনা ID এলে নতুন ID দেওয়া এবং ঘটনাটি log করা।
• ID শুধু cookie-তে। URL-এ কখনো নয়, কারণ URL ইতিহাস, log আর Referer-এ ছড়ায়।
• __Host- নাম ব্যবহার করা, যাতে অন্য subdomain সেই নামের cookie বসাতে না পারে।

নিচের ধাপগুলোতে একটি login থেকে logout পর্যন্ত পুরো পথ দেখুন। Cookie-র মানটি নকল। Store-এর hash হলো example-token-3fa9-এর আসল SHA-256-এর শুরুর অংশ।

Set-Cookie: anon=example-anon-7c21;
  Path=/; Secure; HttpOnly
লগইন-পূর্ব ID, পরিচয় এখনো নেই

user=rahima, password=<user-input>
hash মিলল, MFA ঠিক আছে
privilege বদলাচ্ছে: ID-ও বদলাতে হবে

anon row: deleted
sid_hash   = 0c4cb2f16f59af1f…
user       = rahima
created    = 10:00
last_seen  = 10:00
device     = Chrome, Android

Set-Cookie: __Host-sid=
  example-token-3fa9;
  Path=/; Secure; HttpOnly;
  SameSite=Lax
Set-Cookie: anon=; Path=/;
  Max-Age=0

Cookie: __Host-sid=
  example-token-3fa9
sha256(ID) = 0c4cb2f16f59af1f…
সারি পাওয়া গেছে
10:07: দুই সীমার ভেতরে
last_seen  = 10:07
200 OK, rahima-র অর্ডার

store: 0c4cb2f16f59af1f… deleted
Set-Cookie: __Host-sid=; Path=/;
  Secure; HttpOnly; Max-Age=0
পুরোনো কপি এলে: সারি নেই, 401

৩ · Cookie-র flag: কোনটি কী থামায়

একটি cookie হলো ছোট নাম আর মান, যা server বলে দেয়, আর browser পরের request-এ নিজে থেকে পাঠায়। কয়েকটি attribute ঠিক করে কখন, কোথায়, কার কাছে সেটি যাবে। ভালো একটি শুরুর লাইন এমন:

Set-Cookie: __Host-sid=example-token; Path=/; Secure; HttpOnly; SameSite=Lax

NIST SP 800-63B-4 session cookie-র জন্য HTTPS-only বাধ্যতামূলক করেছে, আর HttpOnly ও SameSite=Lax বা Strict সুপারিশ করেছে। একই দলিল বলে, cookie-র মেয়াদের ওপর ভরসা করে timeout চালানো যাবে না। OWASP Strict-কে আগে রাখে, তবে বাইরের লিংক থেকে এলে লগইন না দেখানোর মতো অসুবিধা আসতে পারে। তাই ব্যাংকিং ধরনের সাইটে Strict, সাধারণ সাইটে Lax বহুল প্রচলিত আপস।

৪ · Timeout আর সত্যিকারের logout

Session অনন্তকাল চলতে পারে না। সময়ের সীমা না থাকলে একবার ফাঁস হওয়া cookie চিরকাল কাজ করে। দুটি ঘড়ি লাগে, দুটি আলাদা বিপদের জন্য।

NIST SP 800-63B-4 অনুযায়ী AAL2-তে সামগ্রিক পুনঃপ্রমাণীকরণ ২৪ ঘণ্টার মধ্যে আর inactivity ১ ঘণ্টা (দুটিই সুপারিশ), AAL3-তে ১২ ঘণ্টা (বাধ্যতামূলক) আর ১৫ মিনিট (সুপারিশ)। মনে রাখবেন, এই সংখ্যা একটি মানদণ্ডের, সবার জন্য একই মান নয়। অ্যাপের ঝুঁকি দেখে ঠিক করুন, আর সবচেয়ে জরুরি কথা: দুটি ঘড়িই চলবে server-এ। Browser-এর timer যে কেউ বদলাতে পারে।

নিচের খেলনা store-এ IDLE = 15 আর ABSOLUTE = 120 মিনিট। ঘড়ি সিমুলেটেড। তিনজনের গল্প আলাদা, চালিয়ে দেখুন।

// খেলনা session store: ID real নয়, ঘড়ি সিমুলেটেড (মিনিট)
function mulberry32(a) { return () => { a = a + 0x6D2B79F5 | 0;
  let t = Math.imul(a ^ a >>> 15, 1 | a);
  t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t;
  return ((t ^ t >>> 14) >>> 0) / 4294967296; }; }
const rnd = mulberry32(17);
const IDLE = 15, ABSOLUTE = 120;
const store = new Map();

function login(user, now) {
  const id = "sid-" + Math.floor(rnd() * 2 ** 24).toString(16).padStart(6, "0");
  store.set(id, { user, created: now, last: now });
  return id;
}
function request(id, now) {
  const s = store.get(id);
  if (!s) return "401 no session";
  if (now - s.last >= IDLE) { store.delete(id); return "401 idle timeout"; }
  if (now - s.created >= ABSOLUTE) { store.delete(id); return "401 absolute timeout"; }
  s.last = now;
  return "200 " + s.user;
}
const log = (t, msg) => console.log("t=" + String(t).padEnd(4), msg);

const a = login("rahima", 0);
for (const t of [10, 20, 40, 41]) log(t, a + " " + request(a, t));

const b = login("karim", 50);
for (let t = 64; t <= 176; t += 14) log(t, b + " " + request(b, t));

const c = login("sadia", 200);
log(205, c + " " + request(c, 205));
store.delete(c);                        // logout: server-এ মুছল
log(207, c + " " + request(c, 207) + " (same cookie)");
console.log("rows left in store:", store.size);

Logout মানে কী?

অনেক সাইটের logout শুধু browser-এর cookie মুছে দেয়। ব্যবহারকারী লগইন পাতা দেখেন, কিন্তু cookie-র কোনো কপি কোথাও থাকলে সেটি দিব্যি চলে। এটি রেস্তোরাঁর ক্যাশমেমো ছিঁড়ে ফেলার মতো, খাতায় হিসাব থেকেই যায়। সত্যিকারের logout-এ যা হয়:

1. Server session-এর সারি মুছে ফেলে। এটিই আসল কাজ, OWASP-ও একে বাধ্যতামূলক বলে।
2. Refresh token থাকলে তার পুরো family বাতিল করে।
3. Cookie মুছতে একই নাম, Path আর attribute দিয়ে Max-Age=0 পাঠায়।
4. সংবেদনশীল পাতায় Cache-Control: no-store রাখে, প্রয়োজনে Clear-Site-Data header-ও পাঠায়, যাতে পেছনে ফিরে পুরোনো পাতা না আসে।
5. ঘটনাটি log করে: কে, কোন device, কখন।

একটি ফোন হারালে শুধু সেই device থেকে logout সম্ভব নয়। তাই ভালো সাইটে থাকে একটি device list, অর্থাৎ বর্তমান session-এর তালিকা: কোন device, কখন শেষ দেখা, মোটামুটি কোন এলাকা। প্রতিটি সারির পাশে “সাইন আউট” চাপলে store-এর সেই সারি মুছে যায়। “সব device থেকে সাইন আউট” আর password বদলে অন্য সব session শেষ করা, দুটোই রাখুন। ব্যাখ্যা সহজ: খাতার সারি মুছলেই সেই টোকেন অকেজো।

৫ · JWT: তিন টুকরো, এক স্বাক্ষর

RFC 7519 (২০১৫) JWT (JSON Web Token)-এর সংজ্ঞা দেয়। এটি কিছু claim, মানে দাবি, যেগুলো স্বাক্ষর করা অবস্থায় এক জায়গা থেকে আরেক জায়গায় যায়। স্বাক্ষরের নিয়ম আছে JWS (RFC 7515)-এ। সাধারণ JWT তিনটি base64url টুকরো, মাঝে ডট।

তিন ধরনের স্বাক্ষর

HS256-এ যিনি যাচাই করতে পারেন, তিনি স্বাক্ষরও করতে পারেন, কারণ key একই। তাই দশটি service-কে key দিলে যেকোনো একটি ফাঁসেই সব token জাল করা সম্ভব। Public-key স্বাক্ষরে যাচাইকারী জাল করতে পারে না। এই একটি কারণেই বহু service-এর জগতে asymmetric স্বাক্ষর পছন্দের। HS256-এর key CSPRNG থেকে নিন, OWASP অন্তত ২৫৬ bit চায়, আর RFC 8725 মানুষের মনে রাখার মতো password-কে key হিসেবে নিষেধ করে। RFC 9864 (২০২৫) সাধারণ EdDSA নামটি deprecated করে নির্দিষ্ট Ed25519 নাম এনেছে। তাই নতুন কাজে আপনার library কোনটি সমর্থন করে দেখে নিন।

৬ · JWT যাচাই: verifier যা করতেই হবে

Token-এর সবকিছু আসে trust boundary-র বাইরে থেকে। এর header-ও আপনার নিয়ন্ত্রণে নয়। RFC 8725 (২০২০) JWT-র সেরা অনুশীলন লিখে রেখেছে। নিয়মগুলো সংক্ষেপে:

• Algorithm আপনি ঠিক করবেন। কোডে একটি স্থির তালিকা, যেমন শুধু HS256 বা শুধু EdDSA. Token-এর alg সেই তালিকায় না থাকলে বাতিল।
• প্রতিটি key একটি algorithm-এর জন্য। RFC 8725-এর ভাষায়, each key MUST be used with exactly one algorithm.
• iss মেলাতে হবে: আপনি যাঁকে বিশ্বাস করেন, token তাঁরই, আর স্বাক্ষরের key-ও তাঁর।
• aud মেলাতে হবে: token আপনার জন্যই লেখা। একই issuer-এর অন্য অ্যাপের token এখানে চলবে না।
• exp দেখতে হবে: এখনকার সময় তার আগে। Server-দের ঘড়ির সামান্য পার্থক্যের জন্য ছোট ছাড় চলে, ঘণ্টা নয়।
• Header-এর key-সংক্রান্ত মান বিশ্বাস নয়। kid শুধু আপনার জানা key-এর তালিকা থেকে বাছাই করতে কাজে লাগে। jku আর x5u দেখে বাইরে থেকে key আনা চলবে না, যদি না সেই ঠিকানা আপনার allowlist-এ থাকে।

ইতিহাসের দুটি ভুল, verifier-এর দৃষ্টিতে

২০১৫ সালে প্রকাশিত নিরাপত্তা-গবেষণা দেখায়, কিছু JWT library দুটি গোড়ার ভুল করত। দুটিরই শিকড় একটি: যাচাইয়ের নিয়ম ঠিক করছিল যাচাই হওয়ার আগের token-ই।

এবার একটি আসল HS256 token একটি একটি দাবি ধরে যাচাই করি। মানগুলো নিচের Python কোডের নকল key থেকে তৈরি। NOW সিমুলেটেড।

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJhdWQiOiJzaG9wLWFwaSIsInN1YiI6InVzZXItMTA0MiIsInJvbGUiOiJjdXN0b21lciIsImV4cCI6MTc5MzAwMDMwMH0
.ebFvWKwDiqaeqpU4lmWgmMGv8iJH6N04Jhw99b5GunE

একই নিয়ম এবার আসল hmac, hashlib আর base64 দিয়ে। শেখার জন্য এটি হাতে লেখা। বাস্তবে নিজের JWT parser না লিখে পরিচিত, রক্ষণাবেক্ষণ হওয়া library ব্যবহার করুন, আর তাতে algorithm তালিকা অবশ্যই দিন।

import base64, hashlib, hmac, json

KEY = b"example-key-lesson-only-32-bytes"     # নকল key, 32 byte
ISS, AUD = "https://auth.example.com", "shop-api"
NOW = 1793000000                              # সিমুলেটেড ঘড়ি

def b64u(b): return base64.urlsafe_b64encode(b).rstrip(b"=").decode()
def unb64u(s): return base64.urlsafe_b64decode(s + "=" * (-len(s) % 4))
def js(d): return b64u(json.dumps(d, separators=(",", ":")).encode())
def mac(msg): return b64u(hmac.new(KEY, msg.encode(), hashlib.sha256).digest())

def sign(claims, alg="HS256"):
    msg = js({"alg": alg, "typ": "JWT"}) + "." + js(claims)
    return msg + "." + mac(msg)

def verify(token):
    head, body, sig = token.split(".")
    if json.loads(unb64u(head)).get("alg") != "HS256":
        return "REJECT alg"             # algorithm ঠিক করে server
    if not hmac.compare_digest(sig.encode(), mac(head + "." + body).encode()):
        return "REJECT signature"
    c = json.loads(unb64u(body))
    if c.get("iss") != ISS: return "REJECT iss"
    if c.get("aud") != AUD: return "REJECT aud"
    if not NOW < c.get("exp", 0): return "REJECT exp"
    return "ACCEPT sub=" + c["sub"]

good = {"iss": ISS, "aud": AUD, "sub": "user-1042", "role": "customer", "exp": NOW + 300}
h, b, s = sign(good).split(".")
print("payload, no key needed:", unb64u(b).decode())
print("valid     :", verify(sign(good)))
print("tampered  :", verify(h + "." + js({**good, "role": "admin"}) + "." + s))
print("expired   :", verify(sign({**good, "exp": NOW - 1})))
print("wrong alg :", verify(sign(good, alg="HS512")))
print("wrong aud :", verify(sign({**good, "aud": "other-api"})))

৭ · Revocation, ছোট access token আর refresh rotation

গেট পাসের সমস্যায় ফিরি। কর্মী চাকরি ছেড়ে গেলেন, কিন্তু তাঁর পাসের মেয়াদ আরও ত্রিশ দিন। দারোয়ান সিল দেখে ঢুকতে দেবেন, কারণ তাঁর কোনো খাতা নেই। JWT-র এটিই revocation সমস্যা: যাচাই যদি শুধু স্বাক্ষর আর সময়ের ওপর চলে, তাহলে মাঝপথে বাতিল করার কোনো জায়গা থাকে না।

পথ তিনটি। প্রতি request-এ একটি denylist দেখা, তবে তখন “store লাগে না” দাবিটি আর থাকে না। OWASP বলে তালিকা রাখলে jti আর iss দিয়ে রাখতে, পুরো token বা তার hash দিয়ে নয়। অথবা মেয়াদ খুব ছোট করা। তৃতীয় পথটি বহুল প্রচলিত, দুই token-এর নকশা:

ফলে বাতিলের সীমা নেমে আসে access token-এর মেয়াদে। Refresh token বাতিল করলে নতুন access token আর আসবে না, হাতে থাকা token বড়জোর আর কয়েক মিনিট চলবে। Logout-এর সততা এই কয়েক মিনিটের সমান। বেশি ঝুঁকির কাজে তাই server-side যাচাই বা token introspection রাখা হয়।

Rotation আর reuse detection

Refresh token দীর্ঘজীবী, তাই সে আকর্ষণীয় লক্ষ্য। Refresh token rotation-এ প্রতিটি refresh token একবারই চলে। ব্যবহার করলেই নতুন একটি আসে, পুরোনোটি বাতিল। একই login থেকে জন্ম নেওয়া সব token মিলে একটি token family. RFC 9700 (২০২৫, OAuth 2.0 Security Best Current Practice) ব্যাখ্যা করে: বাতিল হওয়া token যদি আবার আসে, server বুঝতে পারে কিছু গোলমাল, কিন্তু বুঝতে পারে না কে আসল গ্রাহক। তাই সে সক্রিয় refresh token বাতিল করে, আর ব্যবহারকারীকে আবার login করতে হয়। একই RFC বলে, public client-এর refresh token হয় sender-constrained হবে, নয় rotation ব্যবহার করবে।

1row = lookup(token)2if family_revoked(row): 4013if row.used:4  revoke(family); alert()5row.used = True6return new_token(family)

একই যুক্তি খেলনা কোডে। Token-গুলো স্টেপারের মানের সঙ্গে মিলবে, কারণ seed একই।

// খেলনা refresh server: token real নয়, শুধু ধারণার জন্য
function mulberry32(a) { return () => { a = a + 0x6D2B79F5 | 0;
  let t = Math.imul(a ^ a >>> 15, 1 | a);
  t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t;
  return ((t ^ t >>> 14) >>> 0) / 4294967296; }; }
const rnd = mulberry32(7);
const tokens = new Map();    // token -> {family, used}
const revoked = new Set();

function issue(family) {
  const t = "rt-" + Math.floor(rnd() * 2 ** 24).toString(16).padStart(6, "0");
  tokens.set(t, { family, used: false });
  return t;
}
function refresh(t) {
  const row = tokens.get(t);
  if (!row) return { status: "401 unknown" };
  if (revoked.has(row.family)) return { status: "401 family revoked" };
  if (row.used) {
    revoked.add(row.family);
    return { status: "401 REUSE, revoke " + row.family };
  }
  row.used = true;
  return { status: "200 rotated", next: issue(row.family) };
}
const show = (who, t, r = refresh(t)) =>
  (console.log(who.padEnd(8), t, "->", r.status, r.next || ""), r.next);
const r1 = issue("phone");
const lap = issue("laptop");
const r2 = show("phone", r1);
const r3 = show("phone", r2);
show("old copy", r1);        // আগেই ব্যবহার হওয়া token আবার এল
show("phone", r3);           // পুরো family বন্ধ
show("laptop", lap);         // অন্য device-এর family অক্ষত

৮ · Browser-এ কোথায় রাখবেন, আর opaque না JWT

এই প্রশ্নে “সম্পূর্ণ নিরাপদ জায়গা” বলে কিছু নেই, শুধু ভিন্ন ঝুঁকি। তুলনাটি দেখুন।

OWASP Session Management Cheat Sheet-এর অবস্থান পরিষ্কার: session ID, JWT বা refresh token web storage-এ নয়; পছন্দ HttpOnly; Secure; SameSite cookie অথবা Backend-for-Frontend. JavaScript কোর্সের web storage পর্ব এই API-গুলোর সাধারণ ব্যবহার দেখায়, আর web security পর্ব browser-এর দিকটি। মনে রাখুন, XSS থাকলে কোনো জায়গাই পুরো রক্ষা করে না। HttpOnly শুধু token বাইরে নিয়ে যাওয়া আটকায়, যা তবু বড় লাভ: হামলার সময় পাতা খোলা থাকার মধ্যে সীমিত হয়।

Opaque token, নাকি JWT?

Opaque token হলো অর্থহীন এলোমেলো মান, session ID-র মতোই। যাচাই হয় store বা issuer-এর কাছে জিজ্ঞেস করে।

সহজ সিদ্ধান্ত: একটি সাধারণ web app, যেখানে login থেকে পাতা একই সিস্টেমে, সেখানে server-side session-ই সঠিক। অনেক service একই token স্বাধীনভাবে যাচাই করবে, বা বাইরের issuer আছে, তখন ছোট মেয়াদের JWT মানায়। অনেক সিস্টেমে দুটোই থাকে: বাইরে opaque, ভেতরে gateway সেটিকে ছোট JWT-তে বদলে দেয়। “JWT আধুনিক” কোনো যুক্তি নয়। প্রশ্ন হলো, আপনার store-এর দাম কি revocation-এর দামের চেয়ে বেশি?

৯ · চুরির সংকেত, step-up আর সাড়া

প্রতিরোধ শতভাগ হয় না। ফোনের ম্যালওয়্যার বা ভুলে শেয়ার করা debug ফাইল থেকেও session বেরিয়ে যেতে পারে। Bearer token-এ server তফাত করতে পারে না, তাই আচরণ দেখতে হয়।

কোন সংকেত দেখবেন

• Refresh token reuse: সবচেয়ে শক্ত সংকেত, প্রায় সবসময় তদন্তযোগ্য।
• একই session-এ হঠাৎ পরিবেশ বদল: দূরের দেশ থেকে IP, ভিন্ন browser পরিচয়, একসঙ্গে দুই জায়গা থেকে ব্যবহার।
• অচেনা ID-র ঢেউ: একই উৎস থেকে অনেক ভুল session ID বা নকল স্বাক্ষরের token. এটি অনুমান বা ভুল client-এর সংকেত।
• স্বাক্ষর-ব্যর্থতা হঠাৎ বেড়ে যাওয়া: ভুল key রোল-আউট, নয়তো নকল token পরীক্ষা, দুটোই দেখার মতো।
• Session-এর পরেই সংবেদনশীল কাজ: email বদল, নতুন payout account, API key তৈরি।

একটি সতর্কতা। বাংলাদেশে মোবাইল ডেটায় অনেকে একই IP ভাগ করেন, আর IP ঘন ঘন বদলায়। তাই IP বদল মানেই চুরি নয়। OWASP-ও একে সংকেত হিসেবে দেখে, নিশ্চিত প্রমাণ হিসেবে নয়। IP-তে session শক্ত করে বাঁধলে সৎ ব্যবহারকারী বারবার ছিটকে পড়বেন। সংকেত এলে সরাসরি শাস্তি না দিয়ে আগে একটি প্রমাণ চান। সেটিই step-up.

Step-up authentication

Step-up authentication মানে সংবেদনশীল কাজের ঠিক আগে আবার প্রমাণ চাওয়া, session যত পুরোনোই হোক। ব্যাংকের অ্যাপে আগেই লগইন করা থাকলেও টাকা পাঠাতে PIN চাওয়া হয়, মোবাইল ব্যাংকিংয়ে সবার পরিচিত দৃশ্য। Password বা email বদল, payout বদল, MFA সরানো, admin কাজ, এসব জায়গায় নিয়মিত step-up রাখুন। সম্ভব হলে phishing-প্রতিরোধী passkey ব্যবহার করুন (পর্ব ১৬)।

Log আর সাড়া

Session-এর জীবনচক্র log করুন: তৈরি, ID বদল, timeout, logout, reuse. কাঁচা token নয়। নিচের উদাহরণটি একটি Sigma-ধরনের নিয়ম। আপনার auth service-এর নিজের log ধরে লেখা, field-এর নাম উদাহরণমাত্র।

title: Refresh token reuse detected
status: experimental
logsource:
  product: example-auth-service
  category: application
detection:
  selection:
    event_action: refresh_token_reuse
  condition: selection
level: high

সতর্কতা এলে সাড়াটি আগে ঠিক করা থাকে: সেই ব্যবহারকারীর সব family বাতিল, সব session শেষ, প্রয়োজনে password reset, ঘটনার সময়ের কাজ পর্যালোচনা, ব্যবহারকারীকে জানানো। স্বাক্ষরের key ফাঁসের সন্দেহ হলে key rotate করতে হয়, আর সেই key-তে দেওয়া সব token বাতিল বলে ধরতে হয়। এজন্যই kid আর একাধিক key রাখার পরিকল্পনা আগে থেকে দরকার। Log আর সাড়ার বিস্তারিত পর্ব ৫৫ ও পর্ব ৬১-তে।

১০ · AI-এর যুগে session আর token কোড যাচাই

“Express-এ JWT login লিখে দিন” বললে AI কয়েক সেকেন্ডে চলমান কোড দেয়। চলা আর নিরাপদ থাকা এক কথা নয়। এই বিষয়ে AI-র কিছু ভুল বারবার দেখা যায়।

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

• আসল key, cookie বা token prompt-এ বা বাইরের online decoder-এ দিইনি
• নিজের পরীক্ষায় বদলানো payload, মেয়াদ-শেষ token আর ভুল alg সত্যিই বাতিল হতে দেখেছি
• Logout-এর পরে পুরোনো cookie বা token দিয়ে আমার test সিস্টেমে 401 পেয়েছি
• Library-র version আর নিরাপত্তা-পরামর্শ তার মূল ডকুমেন্টে মিলিয়েছি
• AI-র উল্লেখ করা প্রতিটি RFC বা CVE মূল উৎসে খুঁজে দেখেছি
• Diff পড়েছি: কোনো যাচাই বন্ধ হয়নি, কোনো origin অকারণে খোলা হয়নি
• মানুষের ওপর প্রভাব ফেলে এমন সিদ্ধান্ত, যেমন account বন্ধ, মানুষই নিচ্ছেন