Password নিরাপদে রাখা — salt, Argon2 আর bcrypt

১ · Server-এর password জানার দরকারই নেই

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

এবার ভাবুন, একদিন একটি পুরোনো backup ভুল জায়গায় পড়ে রইল। তখন কী হলো? শুধু এই বাজারের হিসাব নয়। মানুষ একই password বহু জায়গায় ব্যবহার করেন। তাই আপনার ভুলের দাম দেবে গ্রাহকের email, ফেসবুক, এমনকি অফিসের হিসাবও।

Encryption করলে হবে না কেন?

অনেকে ভাবেন, “তাহলে password encrypt করে রাখি।” কিন্তু encryption ফেরত পড়ার জন্যই বানানো। একে বলা হয় reversible encryption. Login-এর সময় server-কে key হাতে রাখতেই হয়। তাহলে key সাধারণত database-এর কাছাকাছি থাকে, আর দুটি একসঙ্গে ফাঁস হলে সব password একসঙ্গে খোলা। কর্মী, backup আর debug tool সবার জন্য একটি বাড়তি পথ খুলে যায়। “Password ভুলে গেলে আমরা email-এ পাঠিয়ে দেব” যদি কোনো সেবা বলে, বুঝবেন তারা password ফেরত পড়তে পারে। সেটিই সমস্যার লক্ষণ।

২ · দ্রুত hash কেন ভুল হাতিয়ার

Hash function এক দিকের ছাপ দেয়। এর মৌলিক কথা পর্ব ০৯-এর বিষয়, আর গভীর আলোচনা আছে Cryptography basics-এ। তাহলে মনে হতে পারে, SHA-256(password) রাখলেই তো হলো। ফাইলের ছাপের জন্য SHA-256 চমৎকার। Password-এর জন্য নয়। কারণটি বুঝতে হলে আগে বিপদটি বুঝতে হবে।

যে বিপদ ঠেকাচ্ছি: ফাঁসের পরে অফলাইনে অনুমান

দুই রকম অনুমান আছে। Online guessing-এ কেউ আপনার login পাতায় বারবার চেষ্টা করেন। সেখানে আপনার হাতে নিয়ন্ত্রণ আছে: rate limit, lockout, MFA. কিন্তু database ফাঁস হলে খেলাটি বদলে যায়। ফাঁস হওয়া কপি অন্যের হাতে, তখন আর আপনার server-এ আসতে হয় না। প্রতিটি অনুমানের ফল নিজের মেশিনেই মেলানো যায়, আপনি log-এও কিছু দেখবেন না। একে বলে offline guessing.

Hash উল্টো করা যায় না, কিন্তু অনুমান করে মেলানো যায়। তাই মানুষের বাছা password-এর নিরাপত্তা নির্ভর করে দুটি সংখ্যার ওপর: password কত অনিশ্চিত (entropy), আর একটি অনুমান পরীক্ষার দাম কত। প্রথমটি ব্যবহারকারীর হাতে। দ্বিতীয়টি আপনার হাতে।

৩ · Salt: একই password, আলাদা ছাপ

Salt ছাড়া hash-এ দুটি সমস্যা থাকে। প্রথমত, একই password-এর ছাপ সবসময় একই। হাজার জন একই password নিলে টেবিলে হাজারটি একই সারি, দেখলেই বোঝা যায়। দ্বিতীয়ত, জনপ্রিয় password-এর ছাপ আগে থেকে হিসাব করে টেবিলে রাখা যায়, পরে শুধু খুঁজে নিলেই চলে। এমন টেবিলের একটি পরিচিত রূপ rainbow table.

Salt হলো প্রতিটি হিসাবের জন্য আলাদা একটি এলোমেলো মান। Password-এর সঙ্গে মিশিয়ে hash করা হয়, আর hash-এর পাশেই খোলা অবস্থায় রাখা হয়।

Salt গোপন নয়, এটি মনে রাখা জরুরি। Salt একটি অনুমানকে সহজ বা কঠিন করে না। সে যা করে তা হলো, এক ধাক্কায় সবাইকে যাচাই করার সুবিধা কেড়ে নেওয়া। NIST SP 800-63B (Revision 4, ২০২৫) ন্যূনতম ৩২ bit salt চায়। RFC 9106 Argon2-র জন্য ১২৮ bit সুপারিশ করে। সাধারণত ১৬ byte নিরাপদ এলোমেলো উৎস থেকে নিলে সমস্যা থাকে না।

নিচের ডায়াগ্রামে signup আর login-এর পুরো পথ দেখুন। মানগুলো আসল PBKDF2 হিসাব, ডেমোর জন্য কম cost আর ছোট salt নিয়ে।

1receive password over TLS2salt = secure_random(8)3hash = pbkdf2(password, salt)4store(user, salt, cost, hash)5login: load salt and cost6recompute, compare_digest

একই কাজ এবার আসল কোডে। Python-এর hashlib.pbkdf2_hmac আর hmac.compare_digest ব্যবহার করে দেখুন।

import hashlib, hmac

ITER = 1000      # শুধু ডেমোর জন্য কম; বাস্তবের মান অংশ ৫-এ

def make_hash(password, salt_hex):
    salt = bytes.fromhex(salt_hex)
    return hashlib.pbkdf2_hmac("sha256", password.encode(), salt, ITER, 16)

def verify(password, salt_hex, stored):
    fresh = make_hash(password, salt_hex)
    return hmac.compare_digest(fresh, stored)   # constant-time তুলনা

# আউটপুট মেলানোর জন্য salt স্থির; বাস্তবে secrets.token_bytes(16)
same_pw = "nodi-ilish-brishti-cha"
db = {}
for user, salt in [("rahima", "9f2c4a71d03e5b86"),
                   ("karim", "41e07bd2c9a5163f")]:
    db[user] = (salt, make_hash(same_pw, salt))
    print(f"{user:7} salt={salt} hash={db[user][1].hex()}")

print("same hash for same password?", db["rahima"][1] == db["karim"][1])

salt, stored = db["rahima"]
print("login, correct password :", verify(same_pw, salt, stored))
print("login, one extra letter :", verify(same_pw + "a", salt, stored))

৪ · ধীর আর memory-খেকো: PBKDF2, bcrypt, scrypt, Argon2id

ধীর করার প্রথম উপায় হলো একই হিসাব বহুবার ঘোরানো। একে বলে key stretching. কিন্তু শুধু ঘোরালেই সব মেটে না। অনেক core-ওয়ালা GPU আর বিশেষ চিপ একসঙ্গে বহু হিসাব চালাতে পারে, যদি প্রতিটি হিসাবে memory কম লাগে। তাই পরের ধাপ হলো memory-hard নকশা।

একটি বিষয় খেয়াল করুন। ভালো password hash তার ফলাফলের সঙ্গে নিজের নিয়মও লিখে রাখে: কোন algorithm, কত cost, কোন salt. একে self-describing বা নিজের পরিচয় বহনকারী record বলা যায়। NIST-ও cost আর scheme-এর তথ্য রাখতে বলে, যাতে পরে নতুন নিয়মে যাওয়া যায়। নিচের কোডে দেখুন record কীভাবে নিজেই যাচাইয়ের সব তথ্য বহন করে।

import hashlib, hmac, unicodedata

def norm(pw):                       # NFC: একই লেখা, একই bytes
    return unicodedata.normalize("NFC", pw).encode()

def encode(pw, salt, n, r, p):
    key = hashlib.scrypt(norm(pw), salt=salt, n=n, r=r, p=p, dklen=16)
    return f"scrypt${n}${r}${p}${salt.hex()}${key.hex()}"

def verify(pw, record):
    _, n, r, p, salt, key = record.split("$")
    fresh = hashlib.scrypt(norm(pw), salt=bytes.fromhex(salt),
                           n=int(n), r=int(r), p=int(p), dklen=16)
    return hmac.compare_digest(fresh.hex(), key)

salt = bytes.fromhex("c04e91aa6b27d358")   # ডেমোর জন্য স্থির
# ডেমোর জন্য কম cost; বাস্তবের ন্যূনতম মান অংশ ৫-এর টেবিলে
for n in (2**10, 2**12):
    rec = encode("amar-sonar-bangla-1971", salt, n, 8, 1)
    mib = 128 * n * 8 / 2**20       # scrypt-এর memory = 128 x N x r bytes
    print(f"N={n:5} memory={mib:.0f} MiB")
    print(" ", rec)

rec = encode("amar-sonar-bangla-1971", salt, 2**10, 8, 1)
print("record carries its own cost:", verify("amar-sonar-bangla-1971", rec))

# একই বাংলা অক্ষর য়, দুই রকম Unicode গঠন
one, two = "য়", "য়"
print("raw strings equal?", one == two)
print("bytes before NFC :", len(one.encode()), len(two.encode()))
print("after NFC login  :", verify(two, encode(one, salt, 2**10, 8, 1)))

৫ · কোন parameter, আর নিজের server-এ cost মাপা

নিচের মানগুলো OWASP Password Storage Cheat Sheet থেকে নেওয়া, ২০২৬ সালের অক্টোবরে মিলিয়ে দেখা। এই সংখ্যাগুলো সময়ের সঙ্গে বদলায়, তাই আসল পাতা দেখে নেবেন। মনে রাখবেন, এগুলো ন্যূনতম মান, লক্ষ্য নয়।

উৎসভেদে সংখ্যা আলাদা হতে পারে, আর সেটি স্বাভাবিক। RFC 9106-এর দুটি সুপারিশ হলো t=1, p=4, m=2 GiB, আর memory কম থাকলে t=3, p=4, m=64 MiB. OWASP-এর ন্যূনতম মান এর চেয়ে অনেক ছোট, কারণ দুটি আলাদা প্রশ্নের উত্তর: একটি “নিরাপদ শুরু কোথায়”, অন্যটি “সম্ভব হলে কতটা”।

Cost কীভাবে ঠিক করবেন

1. আপনার আসল production-এর মতো মেশিনে মাপুন, নিজের laptop-এ নয়।
2. ন্যূনতম মান থেকে শুরু করে cost বাড়ান, যতক্ষণ peak সময়ে login ধীর না হয়। OWASP-এর সাধারণ নিয়ম: একটি hash হিসাবে এক সেকেন্ডের কম লাগা উচিত। অনেক দল এর চেয়ে কম সময় বেছে নেন, যেমন ২০০ থেকে ৫০০ ms. এটি কোনো মান নয়, চর্চা।
3. Server-এর ক্ষমতা হিসাব করুন। প্রতিটি login CPU আর memory খায়, তাই ধীর hash নিজেই denial of service-এর পথ খুলতে পারে। Login পথে rate limit আর সর্বোচ্চ একসঙ্গে-চলা hash-এর সীমা রাখুন।
4. Cost record-এ লিখে রাখুন, আর হার্ডওয়্যার বদলালে আবার মাপুন।

খরচের হিসাব: ধীর hash রক্ষকের অবস্থান কীভাবে বদলায়

সূত্রটি সহজ। E bit entropy-র password-এ সম্ভাব্য মান 2^Eটি। গড়ে অর্ধেকে মিলবে ধরলে সময় = 2^E−1 ÷ হার। এখানে দুটি হার শুধু ধরে নেওয়া: দ্রুত hash-এ সেকেন্ডে 10¹⁰টি, ধীর hash-এ 10³টি। আসল হার hardware আর parameter-ভেদে অনেক বদলায়। এই তুলনার উদ্দেশ্য অনুপাত দেখা।

পূর্ণ উদাহরণ (৪০ bit): 2³⁹ = 549,755,813,888. দ্রুত hash-এ 549,755,813,888 ÷ 10¹⁰ ≈ ৫৫ সেকেন্ড। ধীর hash-এ ÷ 10³ ≈ 5.5 × 10⁸ সেকেন্ড ≈ ১৭.৪ বছর। একই password, শুধু আপনার বাছা algorithm বদলানোয় এক মিনিট থেকে সতেরো বছর।

// সব হার ধরে নেওয়া মান, শুধু দুই hash-এর খরচ তুলনার জন্য।
// কোনো আসল hardware বা আসল algorithm-এর মাপ নয়।
const FAST = 1e10;      // দ্রুত hash: প্রতি সেকেন্ডে পরীক্ষা (assumed)
const SLOW = 1e3;       // ধীর hash: প্রতি সেকেন্ডে পরীক্ষা (assumed)

function human(sec) {
  if (sec < 1) return "<1 sec";
  if (sec < 3600) return (sec / 60).toFixed(1) + " min";
  if (sec < 86400) return (sec / 3600).toFixed(1) + " hours";
  if (sec < 86400 * 365.25) return (sec / 86400).toFixed(1) + " days";
  return (sec / (86400 * 365.25)).toExponential(1) + " years";
}

console.log("Average cost to exhaust half of the space");
console.log("entropy".padEnd(9) + "fast hash".padEnd(16) + "slow hash");
for (const bits of [20, 30, 40, 50, 60, 72]) {
  const half = 2 ** (bits - 1);
  console.log((bits + " bit").padEnd(9) +
    human(half / FAST).padEnd(16) + human(half / SLOW));
}
console.log("slowdown factor:", (FAST / SLOW).toExponential(0));

// Salt-এর প্রভাব: একটি অনুমান ১০ লাখ ব্যবহারকারীর ওপর যাচাই করতে কত hash?
const users = 1000000;
console.log("hashes per guess, no salt    :", 1);
console.log("hashes per guess, unique salt:", users);

// রক্ষকের নিজের খরচ: peak সময়ে কত CPU core আর memory লাগবে?
const logins = 100, hashSec = 0.25, memMiB = 19;   // ধরে নেওয়া মান
const busy = logins * hashSec;
console.log("server cores busy at peak:", busy);
console.log("server memory for hashing:", busy * memMiB, "MiB");

৬ · Pepper: database-এর বাইরে রাখা গোপন চাবি

Salt গোপন নয়। তাহলে এমন কিছু কি রাখা যায়, যা database ফাঁস হলেও ফাঁস হবে না? Pepper সেটিই। এটি সবার জন্য একটি (বা কয়েকটি) গোপন key, যা database-এর বাইরে রাখা হয়। NIST SP 800-63B “pepper” শব্দটি ব্যবহার করে না, তবে একই ধারণায় গোপন key দিয়ে বাড়তি একটি keyed hash বা encryption ধাপের কথা বলে, আর key আলাদা রাখতে বলে।

Key management: pepper-এর আসল কাজ এখানেই

• কোথায় থাকবে: database-এর বাইরে, secret vault বা HSM-এ। OWASP আর NIST দুটোই আলাদা রাখতে বলে। Source code বা repository-তে নয়।
• কীভাবে বানাবেন: নিরাপদ এলোমেলো উৎস থেকে। মানুষের বানানো লেখা pepper নয়।
• Version রাখুন: প্রতিটি record-এ pepper-এর version লিখুন। না হলে পরে কোন key দিয়ে যাচাই হবে, তা জানা যাবে না।
• হারালে বিপদ: Pepper হারালে সব hash অকেজো, সবাইকে reset করতে হবে। তাই এর backup-ও আলাদা, নিরাপদ জায়গায় চাই।

পরিবর্তনের প্রশ্নটি কঠিন। Pepper দুইভাবে লাগানো যায়: hash করার আগে password-এ, অথবা hash-এর ফলাফলে HMAC দিয়ে। OWASP সতর্ক করে, এভাবে লাগানো pepper ব্যবহারকারীর password না জেনে বদলানো যায় না, ফাঁস হলে সবার reset লাগতে পারে। অন্য পথ হলো hash-এর ফলাফল key দিয়ে encrypt করা, যা key বদলের সময় সবটা নতুন key-তে আবার encrypt করতে দেয়। Dropbox ২০১৬ সালের প্রকৌশল-লেখায় নিজেদের এমন নকশার কথা জানিয়েছিল: bcrypt-এর ফল AES-256 দিয়ে encrypt, পরিবর্তনযোগ্য pepper হিসেবে। এটি একটি প্রকাশিত উদাহরণ, সবার জন্য নিয়ম নয়। এখানে একটিমাত্র সঠিক উত্তর নেই, trade-off আছে।

৭ · পুরোনো hash আপগ্রেড আর bcrypt-এর ৭২ byte সীমা

আপনার system হয়তো দশ বছরের পুরোনো, আর টেবিলে MD5 বা SHA-1 আছে। সবার password আপনার জানা নেই, তাই একবারে বদলানো সম্ভব নয়। তাহলে উপায়? লগইনের মুহূর্তটি। ওই একটি মুহূর্তেই password server-এর হাতে আসে।

1r = load(user)2ok = verify(password, r)3if not ok: reject4if r.alg or r.cost is old:5    r = new_hash(password)6    save(r)7start_session()

এবার চারটি খেলনা record-এ নীতিটি চালিয়ে দেখুন। এখানে toyHash real নয়, শুধু ধারণার জন্য। আসল সিস্টেমে library-র needs_rehash ধরনের সুবিধা থাকলে সেটিই ব্যবহার করবেন।

// খেলনা সিমুলেটর: toyHash real নয়, শুধু ধারণার জন্য
function toyHash(pw, salt, cost) {
  let h = 2166136261;
  for (let i = 0; i < cost; i++)
    for (const c of salt + pw) h = Math.imul(h ^ c.charCodeAt(0), 16777619) >>> 0;
  return h.toString(16).padStart(8, "0");
}
let s = 7;                                    // স্থির seed, তাই ফল একই থাকে
const newSalt = () => ((s = Math.imul(s, 48271) >>> 0) & 0xffff).toString(16);
const TARGET = { alg: "slow", cost: 1024 };

const rec = (alg, cost, pw) => { const salt = newSalt();
  return { alg, cost, salt, hash: toyHash(pw, salt, cost) }; };
const db = {
  rahima: rec("fast", 1, "pw-rahima"),
  karim: rec("slow", 256, "pw-karim"),
  sadia: rec("slow", 1024, "pw-sadia"),
  nabil: rec("fast", 1, "pw-nabil"),
};

function login(user, pw) {
  const r = db[user];
  if (toyHash(pw, r.salt, r.cost) !== r.hash)
    return console.log(`${user}: wrong password, record unchanged`);
  const stale = r.alg !== TARGET.alg || r.cost < TARGET.cost;
  if (stale) db[user] = rec(TARGET.alg, TARGET.cost, pw);   // password এখন হাতে আছে
  console.log(`${user}: ok` + (stale ? `, upgraded ${r.alg}/${r.cost} -> slow/1024` : ", already current"));
}
login("rahima", "pw-rahima"); login("karim", "wrong-guess");
login("karim", "pw-karim");   login("sadia", "pw-sadia");

const left = Object.keys(db).filter(u => db[u].cost < TARGET.cost);
console.log("still on old hash:", left.join(", "));
for (const u in db) console.log(u.padEnd(7), db[u].alg, db[u].cost, db[u].salt, db[u].hash);

পুরোনো দুর্বল hash-কে সরাসরি নতুন ধীর hash-এর ভেতরে মুড়ে রাখার একটি অন্তর্বর্তী পথও আছে, যাতে অপেক্ষার সময়েও সবাই ধীর স্তরে থাকেন। OWASP এটিকে সাময়িক ধরে, আর পরের login-এ সরাসরি password-এর hash-এ ফিরতে বলে। এতে বাড়তি জটিলতা আছে, আর জোড়া লাগানো অংশ নিজে পরীক্ষা না করে চালানো ঠিক নয়।

bcrypt-এর ৭২ byte সীমা

bcrypt ইনপুটের ৭২ byte পর্যন্তই ব্যবহার করে। Byte, অক্ষর নয়। ইংরেজিতে এক অক্ষর এক byte. কিন্তু UTF-8-এ একটি বাংলা অক্ষর সাধারণত ৩ byte. তাই মাত্র ২৪টি বাংলা অক্ষরেই (24 × 3 = 72) সীমা শেষ, আর বাকি অংশ কোনো কাজে আসে না। কিছু library চুপচাপ বাকি অংশ ফেলে দেয়, কিছু error দেয়। আপনার library কী করে, তা পরীক্ষা করে জেনে নিন।

৮ · ফাঁস হলে কী মানে, আর কী করবেন

একই ঘটনা, একই চুরি হওয়া টেবিল। কিন্তু ক্ষতি নির্ভর করে আপনি আগে কী বেছেছিলেন তার ওপর। নিচে দুটি হিসাবই example-pass-1 password নিয়েছে। ছয় রকম সংরক্ষণে ফাঁস হওয়া ফাইলটি কেমন দেখায় আর তার অর্থ কী, তা দেখুন।

rahima  example-pass-1
karim   example-pass-1

rahima  6f1d09c2b7a4e035
karim   6f1d09c2b7a4e035
app.conf: DB_KEY=example-key

rahima  79f87c98a8c83899…
karim   79f87c98a8c83899…

rahima  a1f0  5c25871686ef3f52…
karim   6d3e  bef66de507b2b404…

rahima  scrypt$1024$8$1$c04e…$687adb62…
karim   scrypt$1024$8$1$5be1…$f4c4bec5…

rahima  scrypt$…$c04e…$b202dd5d…  p3
pepper p3 is in the vault, not here

কীভাবে জানবেন ফাঁস হয়েছে?

ফাঁস অনেক সময় নীরব। তাই নজরদারি দরকার: database থেকে অস্বাভাবিক বড় export, backup bucket-এ অচেনা access, আর অনেক হিসাবে অল্প সময়ে ব্যর্থ login, যা credential stuffing-এর লক্ষণ হতে পারে। ২০১৩ সালে Juels আর Rivest honeyword প্রস্তাব করেন: প্রতিটি হিসাবে কয়েকটি নকল password-ছাপ রাখা, যার কোনোটি দিয়ে login চেষ্টা হলে বোঝা যায় টেবিল বাইরে গেছে। এগুলোর log আর alert পর্ব ৫৫-এর বিষয়।

ফাঁসের পরে করণীয়

1. থামান আর প্রমাণ রাখুন। ফাঁসের পথ বন্ধ করুন, log সংরক্ষণ করুন। Incident management প্রক্রিয়া চালু করুন, বিস্তারিত পর্ব ৬১-তে।
2. কী গেছে তা বের করুন। কোন টেবিল, কত record, কোন hash, pepper কি নিরাপদ? উপরের ছয়টি ধাপের কোনটিতে আপনি আছেন, সেটিই পরের সিদ্ধান্ত ঠিক করে।
3. Key আর session বদলান। Pepper বা key-র ওপর সন্দেহ থাকলে নতুন key, আর সক্রিয় session বাতিল।
4. বাধ্যতামূলক reset. NIST নিয়মিত সময় পর পর password বদলাতে বাধ্য করা নিষেধ করে, কিন্তু ঝুঁকির প্রমাণ থাকলে বদলানো বাধ্যতামূলক। Reset-এর পথটিও যেন নিরাপদ হয়, শুধু ফাঁস হওয়া ডেটা দিয়ে যেন reset করা না যায়।
5. ব্যবহারকারীকে সৎভাবে জানান। কী হয়েছে, কী ডেটা গেছে, কী করবেন। বিশেষ করে বলুন, একই password অন্য জায়গায় থাকলে সেখানেও বদলান। সতর্কবার্তার পরে phishing বাড়তে পারে, তাই বার্তায় ক্লিক করার চাপ না দিয়ে নিজে সাইটে যেতে বলুন।
6. আইনি বাধ্যবাধকতা দেখুন। GDPR-এর ক্ষেত্রে article 33 সম্ভব হলে ৭২ ঘণ্টার মধ্যে কর্তৃপক্ষকে জানাতে বলে। বাংলাদেশের প্রেক্ষাপটের জন্য পর্ব ০৬ দেখুন, আর এটি আইনি পরামর্শ নয়।
7. শিখুন আর ঠিক করুন। সব পুরোনো hash আপগ্রেড, MFA বাড়ানো, আর দোষারোপহীন পর্যালোচনা।

৯ · ফাঁস হওয়া তালিকা মিলিয়ে দেখা আর ব্যবহারকারীর দিক

আপনার hash যত ভালোই হোক, ব্যবহারকারী যদি এমন password নেন যা আগে কোথাও ফাঁস হয়েছে, তবে সেটির প্রথমে পরীক্ষা হওয়ার সম্ভাবনাই বেশি। NIST তাই password বসানোর সময় পরিচিত, অনুমেয় বা ফাঁস হওয়া password-এর blocklist-এর সঙ্গে মেলানো বাধ্যতামূলক করেছে।

কিন্তু একটি ধাঁধা আছে। বাইরের কোনো তালিকা-সেবায় password পাঠিয়ে জিজ্ঞেস করলে সেটিই তো ফাঁস! সমাধান k-anonymity-ভিত্তিক খোঁজ: পুরো ছাপ নয়, শুধু প্রথম কয়েকটি অক্ষর পাঠানো। সেবাটি ওই শুরুর সঙ্গে মেলা বহু ছাপ ফেরত দেয়, আর আসল মিলটি হয় আপনার নিজের দিকে। Have I Been Pwned-এর Pwned Passwords এই ধারণার একটি পরিচিত উদাহরণ, যা SHA-1 ছাপের প্রথম ৫ hex অক্ষর ব্যবহার করে। অন্য সেবা বা নিজের সংরক্ষিত তালিকাও ব্যবহার করা যায়।

password: example-pass-1
SHA-1: 9BE84F856BCC258F0BD1…C8897

prefix: 9BE84
suffix: F856BCC258F0BD107…C8897
suffix stays on your side

range request: 9BE84
16^5 = 1,048,576 possible prefixes

0A1C…77D2:12
3FE9…10B4:1
F856…C8897:3
… many more

suffix found, seen 3 times (toy list)
reject: choose another password

ব্যবহারকারীর দিক: password manager

সবচেয়ে ভালো hash-ও এক জায়গার password পুনর্ব্যবহার ঠেকাতে পারে না। ব্যবহারকারীর সেরা অভ্যাসটি সহজ: প্রতিটি সেবায় আলাদা, লম্বা, এলোমেলো password, আর সেটি মনে রাখবে একটি password manager. ভাবুন একটি মজবুত আলমারি, ভেতরে সব চাবি। আপনি মনে রাখবেন শুধু আলমারির একটি শক্ত চাবি, যা হতে পারে কয়েকটি এলোমেলো শব্দের লম্বা বাক্যাংশ।

• এক সেবা ফাঁস হলে ক্ষতি সেখানেই থামে, এটিই সবচেয়ে বড় লাভ।
• Manager ঠিকানা মিলিয়ে তবেই password বসায়, তাই নকল সাইটে কিছুটা সুরক্ষাও পাওয়া যায়।
• মূল password আর recovery পথ হারালে সব হারাতে পারে। তাই সেগুলো নিরাপদে আলাদা জায়গায় রাখুন।
• Manager-এর ঝুঁকিও আছে: এটি একটি একক লক্ষ্য। তাই MFA আর বিশ্বস্ত, হালনাগাদ পণ্য জরুরি।

Developer হিসেবে আপনার দায়িত্ব: password field-এ paste আর autofill চালু রাখা। NIST password manager ব্যবহার করতে দেওয়া বাধ্যতামূলক করেছে, আর paste-ও অনুমতি দিতে বলে। পরে পর্ব ১৬-তে দেখবেন passkey এই পুরো সমস্যার অনেকটাই কীভাবে কমায়।

১০ · AI-এর যুগে password কোড

“একটি login system লিখে দাও” বললে AI সুন্দর, চলনসই কোড দেয়। আর চলনসই কোড সবচেয়ে বিপজ্জনক, কারণ ভুল hash-ও লগইন ঠিকই করে দেয়। ভুলটি ধরা পড়ে শুধু ফাঁসের দিনে।

AI-এর লেখা password কোড মেলানোর চেকলিস্ট

• Argon2id বা অন্য স্বীকৃত password hash, নিজের লেখা algorithm নয়
• প্রতি record-এ নিরাপদ এলোমেলো salt, আর record-এ cost লেখা
• Parameter মূল উৎসে নিজে মিলিয়েছি, আর নিজের server-এ মেপেছি
• Password log, error, URL বা analytics-এ যায় না, পরীক্ষা করেছি
• verify=False বা এমন “সহজ সমাধান” দিয়ে কোনো যাচাই বন্ধ করা হয়নি
• আসল secret বা গ্রাহকের ডেটা AI-তে পেস্ট করিনি
• ব্যবহারকারীর ওপর প্রভাব পড়ে এমন সিদ্ধান্তে (যেমন বাধ্যতামূলক reset) একজন মানুষের অনুমোদন আছে