পাসওয়ার্ড হ্যাশিং আসলে আপনাকে কী থেকে সুরক্ষা দেয়

সংক্ষিপ্ত সংস্করণ

পাসওয়ার্ড হ্যাশিং ব্যবহারকারীদের সুরক্ষা দেয় যখন আপনার পাসওয়ার্ড ডেটাবেস চুরি হয়ে যায়।

এটাই এর প্রধান কাজ। একমাত্র বিবরণ নয়, পুরো নিরাপত্তা মডেলও নয়, কিন্তু পাসওয়ার্ড সরাসরি সংরক্ষণ না করে হ্যাশ করার কেন্দ্রীয় কারণ এটি।

সঠিকভাবে হ্যাশ করা পাসওয়ার্ড উল্টে বের করা কঠিন। কোনো আক্রমণকারী যদি আপনার user table-এর একটি কপি পায়, তার যেন সঙ্গে সঙ্গে জানা না হয়ে যায় যে Alice-এর পাসওয়ার্ড Spring2026!। বরং তারা একটি সংরক্ষিত হ্যাশ পায়, যেটিকে অনুমানের সঙ্গে মিলিয়ে পরীক্ষা করতে সময়, অর্থ এবং হার্ডওয়্যার লাগে।

এই পার্থক্যটি গুরুত্বপূর্ণ। পাসওয়ার্ড হ্যাশিং নিজে নিজে login নিরাপদ করার জন্য নয়। এটি phishing থামায় না। এটি কারও আপনার login form-এ ফাঁস হওয়া পাসওয়ার্ড চেষ্টা করা থামায় না। এটি login-এর পর session cookie সুরক্ষিত রাখে না। এটি সময় কিনে দেয় এবং একটি খুব নির্দিষ্ট ব্যর্থতার পরে ক্ষতি কমায়: আপনার password verifier storage প্রকাশ হয়ে যায়।

এই সীমারেখা বুঝলে আপনি algorithm, work factor, reset, logging, এবং incident response নিয়ে ভালো সিদ্ধান্ত নেবেন।

পাসওয়ার্ড হ্যাশ কী

পাসওয়ার্ড হ্যাশ হলো পাসওয়ার্ডের ওপর একটি one-way function প্রয়োগের ফলাফল, সাধারণত একটি unique salt এবং ইচ্ছাকৃতভাবে ধীর password-hashing algorithm সহ।

কোনো ব্যবহারকারী account তৈরি করলে, সিস্টেমের মোটামুটি এভাবে কাজ করা উচিত:

1. HTTPS-এর মাধ্যমে পাসওয়ার্ড গ্রহণ করা।
2. একটি random, unique salt তৈরি করা।
3. পাসওয়ার্ড এবং salt-কে Argon2id, bcrypt, scrypt, বা PBKDF2-এর মতো password-hashing function-এর মধ্য দিয়ে চালানো।
4. algorithm name, parameters, salt, এবং resulting hash সংরক্ষণ করা।
5. মূল পাসওয়ার্ড ফেলে দেওয়া।

পরে ব্যবহারকারী login করলে, সিস্টেম জমা দেওয়া পাসওয়ার্ড এবং সংরক্ষিত parameters দিয়ে একই hashing process পুনরাবৃত্তি করে। resulting hash যদি stored hash-এর সঙ্গে মেলে, login সফল হয়।

গুরুত্বপূর্ণ অংশটি হলো: application-এর মূল পাসওয়ার্ড জানা দরকার নেই। জমা দেওয়া পাসওয়ার্ড expected result তৈরি করে কি না, শুধু তা যাচাই করলেই যথেষ্ট।

এ কারণেই reversible encryption দিয়ে পাসওয়ার্ড সংরক্ষণ করা সাধারণত ভুল model। আপনার application যদি প্রতিটি পাসওয়ার্ড decrypt করতে পারে, তাহলে decryption key চুরি করা যে কেউ একই কাজ করতে পারে। পাসওয়ার্ড সাধারণত উল্টো পথে যাচাই-অযোগ্য হওয়া উচিত, কেবল লুকানো নয়।

হ্যাশিং আপনাকে কী থেকে সুরক্ষা দেয়

1. ডেটাবেস breach-এর পর তাৎক্ষণিক পাসওয়ার্ড প্রকাশ

কোনো আক্রমণকারী যদি plaintext passwords-সহ একটি database চুরি করে, ক্ষতি তাৎক্ষণিক। প্রতিটি পাসওয়ার্ড প্রকাশিত। ব্যবহারকারীরা শুধু আপনার site-এ নয়, যেখানে যেখানে তারা সেই পাসওয়ার্ড পুনরায় ব্যবহার করেছেন, সেখানেও ঝুঁকিতে থাকেন।

ডেটাবেসে যদি well-hashed passwords থাকে, আক্রমণকারীর কাজ বেশি। তাদের candidate passwords অনুমান করতে হবে, সঠিক salt এবং parameters দিয়ে প্রতিটি guess hash করতে হবে, এবং result তুলনা করতে হবে।

দুর্বল পাসওয়ার্ডের ক্ষেত্রে এটি এখনও দ্রুত হতে পারে। শক্তিশালী unique passwords-এর ক্ষেত্রে এটি অবাস্তব হয়ে উঠতে পারে।

হ্যাশিং একটি বিপর্যয়কর disclosure-কে দৌড়ে পরিণত করে: আক্রমণকারীরা অনেকগুলো পাসওয়ার্ড crack করার আগে ব্যবহারকারীরা কি পাসওয়ার্ড reset করতে পারবেন এবং আপনি কি incident নিয়ন্ত্রণে আনতে পারবেন?

এটি নিখুঁত নয়। এটি এখনও একটি breach। কিন্তু এটি নাটকীয়ভাবে ভালো failure mode।

2. আপনার পুরো user base-এর বিরুদ্ধে bulk attacks

Salt হলো password storage-এর একটি গুরুত্বপূর্ণ অংশ, কারণ এগুলো attackers-কে precomputed tables দিয়ে একসঙ্গে অনেক ব্যবহারকারীর ওপর কার্যকরভাবে আক্রমণ করতে বাধা দেয়।

Salt secret নয়। এটি hash-এর পাশে সংরক্ষিত থাকে। এর কাজ uniqueness।

দুই ব্যবহারকারী একই পাসওয়ার্ড বেছে নিলে, unique salts নিশ্চিত করে যে তাদের stored hashes আলাদা হবে। এতে attackers এক নজরে দেখতে পারে না যে অনেক ব্যবহারকারী একই পাসওয়ার্ড ব্যবহার করছেন। এটি classic rainbow table attacks-ও ঠেকায়, যেখানে attackers password-to-hash mappings-এর বিশাল precomputed lists ব্যবহার করে।

Salt না থাকলে, একটি cracked hash একই পাসওয়ার্ড ব্যবহারকারী সব user-কে প্রকাশ করে দিতে পারে। Salt থাকলে, প্রতিটি password guess প্রতিটি user-এর জন্য আলাদাভাবে পরীক্ষা করতে হয়।

3. দ্রুত offline guessing

Attackers একবার password database পেয়ে গেলে, তারা offline guess করতে পারে। এর মানে আপনার login rate limits, CAPTCHA, IP blocking, এবং monitoring আর গুরুত্ব রাখে না। আক্রমণকারী নিজের hardware-এ guesses পরীক্ষা করতে পারে।

এখানেই algorithm choice গুরুত্বপূর্ণ।

SHA-256 এবং SHA-512-এর মতো general-purpose hashes দ্রুত হওয়ার জন্য তৈরি। File integrity এবং digital signatures-এর জন্য এটি ভালো। Password storage-এর জন্য এটি খারাপ।

Password-hashing algorithms ধীর, tunable, এবং কখনও কখনও memory-hard হওয়ার জন্য ডিজাইন করা। Argon2id, bcrypt, scrypt, এবং PBKDF2 সবই আপনাকে cost parameters সামঞ্জস্য করতে দেয়, যাতে প্রতিটি guess অর্থপূর্ণ সময় নেয়।

নতুন systems-এর জন্য Argon2id ব্যাপকভাবে সুপারিশ করা হয়, কারণ এটি CPU time এবং memory—দুটিই প্রয়োজন করার মতো করে configure করা যায়, যা large-scale GPU cracking-কে বেশি ব্যয়বহুল করে। bcrypt এখনও সাধারণ এবং ভালোভাবে configure করা হলে গ্রহণযোগ্য, যদিও password length handling-এর মতো সীমাবদ্ধতা আছে। PBKDF2 এখনও কিছু compliance-driven environments-এ ব্যবহৃত হয়, বিশেষ করে যেখানে FIPS-validated components প্রয়োজন।

নীতিটি সহজ: legitimate logins গ্রহণযোগ্যভাবে দ্রুত রাখুন, আর billions of guesses ব্যয়বহুল করুন।

হ্যাশিং আপনাকে কী থেকে সুরক্ষা দেয় না

1. Phishing

কোনো ব্যবহারকারী যদি fake login page-এ নিজের পাসওয়ার্ড টাইপ করেন, আপনার server-এ hashing সাহায্য করবে না। আপনার system দেখার আগেই attacker পাসওয়ার্ড পেয়ে যায়।

এখানে defenses আলাদা: multi-factor authentication, passkeys, user education, domain hygiene, phishing-resistant authentication, এবং সতর্ক password reset flows।

Password hashing stored secrets-এর জন্য backstop। ব্যবহারকারীদের প্রতারিত হয়ে সেই secrets দিয়ে দেওয়া থেকে রক্ষা করার defense নয়।

2. Credential stuffing

Credential stuffing ঘটে যখন attackers একটি service থেকে ফাঁস হওয়া username এবং password pairs নিয়ে অন্য service-এ চেষ্টা করে।

আপনার password hashes চমৎকার হতে পারে, তবুও users পাসওয়ার্ড reuse করলে credential stuffing কাজ করতে পারে।

এটি আপনার login form-এর বিরুদ্ধে একটি online attack, আপনার database-এর বিরুদ্ধে offline attack নয়। এই ঝুঁকি কমাতে আপনার rate limiting, anomaly detection, breached-password checks, MFA, এবং এমন sensible lockout policies দরকার যা সহজ denial-of-service সুযোগ তৈরি করে না।

যে কোনো exposed form-এর ক্ষেত্রেই একই ব্যবহারিক চিন্তা প্রযোজ্য। আপনি যদি আপনার authentication surface পর্যালোচনা করেন, তাহলে আপনার contact form কেন আপনার সবচেয়ে বড় spam liability তা পড়া মূল্যবান; mechanics আলাদা, কিন্তু শিক্ষা একই: public inputs-এর abuse controls দরকার, শুধু clean backend code নয়।

3. Logs বা analytics-এ ধরা পড়া পাসওয়ার্ড

Hashing তখনই সাহায্য করে, যখন plaintext password দ্রুত ফেলে দেওয়া হয় এবং কখনও অন্য কোথাও copy করা হয় না।

সাধারণ failures-এর মধ্যে আছে:

• Failed login attempts-এ full request bodies log করা।
• Passwords error monitoring tools-এ পাঠানো।
• Session replay products-এ password fields capture করা।
• খারাপভাবে ডিজাইন করা reset বা migration flows-এ URLs-এর মধ্যে credentials রাখা।
• Imports-এর সময় temporary plaintext passwords সংরক্ষণ করা।

এই ভুলগুলো password hashing পুরোপুরি bypass করে। Plaintext যদি logs, backups, data warehouses, বা third-party tools-এ পৌঁছে যায়, আপনার hash function অপ্রাসঙ্গিক।

Password fields-কে toxic data হিসেবে বিবেচনা করুন। Logging-এর আগে সেগুলো redact করুন। Analytics থেকে বাদ দিন। URLs থেকে দূরে রাখুন। Production traces-এ কারা access পাবে তা সীমিত করুন।

4. দুর্বল session security

Login-এর পর ব্যবহারকারীর browser সাধারণত একটি session cookie বা token পায়। সেই token চুরি হলে, attacker-এর পাসওয়ার্ডের প্রয়োজন নাও হতে পারে।

Password hashing cross-site scripting, insecure cookies, session fixation, weak token generation, বা অতিরিক্ত দীর্ঘ session lifetimes থেকে সুরক্ষা দেয় না।

Session cookies-এর নিজস্ব review প্রাপ্য: HttpOnly, Secure, উপযুক্ত SameSite, short-lived high-risk sessions, এবং password changes-এ server-side invalidation। বিস্তৃত privacy এবং browser landscape-ও বদলাতে থাকে, যেমন 2026 সালে cookies-এর জন্য কী বদলেছে-এ আলোচনা করা হয়েছে।

5. দুর্বল password reset এবং account recovery

অনেক account takeover পাসওয়ার্ড দিয়ে শুরু হয় না। সেগুলো reset flow দিয়ে শুরু হয়।

Reset tokens যদি predictable, long-lived, referrer headers-এর মাধ্যমে leaked, বা compromised email accounts-এ পাঠানো হয়, password hashing আপনাকে বাঁচাবে না।

High-entropy reset tokens, short expiry windows, one-time use, এবং clear user notifications ব্যবহার করুন। যেহেতু email প্রায়ই recovery channel, basic domain authentication-ও গুরুত্বপূর্ণ। আপনার team যদি DNS records-কে রহস্যময় আনুষ্ঠানিকতা হিসেবে দেখে, তাহলে MX, SPF, DKIM এবং DMARC নিয়ে developer-friendly tour দিয়ে শুরু করুন।

Algorithm choice: এখন কী ব্যবহার করবেন

নতুন applications-এর জন্য, আপনার platform ভালোভাবে support করলে Argon2id ব্যবহার করুন। এটি Password Hashing Competition-এর winner এবং password storage-এর জন্য তৈরি, GPU-heavy cracking প্রতিরোধসহ।

একটি যুক্তিসঙ্গত modern hierarchy এ রকম:

1. Argon2id নতুন systems-এর জন্য, যেখানে available।
2. bcrypt যখন Argon2id practical নয় এবং bcrypt support mature।
3. scrypt যখন memory-hard configuration ভালোভাবে supported।
4. PBKDF2 যেখানে platform বা compliance constraints-এর কারণে প্রয়োজন।

Plain SHA-256, SHA-512, MD5, বা sha256(password + salt)-এর মতো homegrown combination এড়িয়ে চলুন। Fast hashes password storage functions নয়। Clever custom constructions সাধারণত boring standard ones-এর চেয়ে খারাপ হয়।

Algorithm trivia ঘিরে নিজের password policy বানানো থেকেও বিরত থাকুন। 12-rule password composition checklist যদি users-কে predictable patterns-এর দিকে ঠেলে দেয়, তাহলে তা তাদের উপকার করে না। Longer unique passwords, password managers, breached-password screening, এবং MFA সাধারণত বেশি গুরুত্বপূর্ণ।

Cost factors set-and-forget নয়

Password hashing-এর parameters আছে। Argon2id-এর memory, iterations, এবং parallelism আছে। bcrypt-এর cost factor আছে। PBKDF2-এর iteration count আছে।

এই values আপনার production environment-এর ভিত্তিতে বেছে নেওয়া উচিত। খুব কম হলে attackers সস্তায় guess করতে পারে। খুব বেশি হলে আপনার login system ধীর বা denial-of-service-এর ঝুঁকিতে পড়ে।

একটি ব্যবহারিক target প্রায়ই আপনার actual servers-এ প্রতি password verification-এ কয়েক দশ থেকে কয়েক শত milliseconds-এর মধ্যে থাকে, traffic এবং risk-এর ওপর নির্ভর করে। High-security systems বেশি বেছে নিতে পারে। Consumer-scale systems-এর careful capacity planning দরকার হতে পারে।

পাঁচ বছর আগের blog post থেকে cost factor copy করবেন না। Hardware বদলায়। Libraries বদলায়। আপনার traffic বদলায়।

Parameters সময়ে সময়ে review করুন এবং rehashing-এর পরিকল্পনা করুন। একটি সাধারণ pattern হলো প্রতিটি hash-এর সঙ্গে algorithm এবং parameters সংরক্ষণ করা। Successful login-এর সময়, stored parameters outdated হলে, submitted password-কে নতুন configuration দিয়ে rehash করে record update করুন।

Peppers: উপযোগী, কিন্তু বিকল্প নয়

Pepper হলো password-hashing process-এ যোগ করা একটি secret value, যা database থেকে আলাদাভাবে সংরক্ষিত থাকে, প্রায়ই secrets manager বা hardware security module-এ।

Salt-এর বিপরীতে, pepper অবশ্যই secret থাকতে হবে।

Database leak হলেও application secrets leak না হলে peppers ক্ষতি কমাতে পারে। ভালো key management-সহ mature environments-এ এগুলো সবচেয়ে কার্যকর। একই attacker যদি database এবং application configuration—দুটিই চুরি করতে পারে, তাহলে এগুলো কম কার্যকর।

Pepper ব্যবহার করলে, rotation সতর্কভাবে পরিকল্পনা করুন। Design-এর ওপর নির্ভর করে এটি rotate করতে users-কে আবার login করতে বা passwords reset করতে হতে পারে। Pepper একটি additional layer, underlying hash settings দুর্বল করার কারণ নয়।

Operational checklist

আপনি যদি একটি বাস্তব system-এর দায়িত্বে থাকেন, practical checklist সংক্ষিপ্ত:

• Passwords শুধু standard password-hashing algorithm দিয়ে সংরক্ষণ করুন।
• প্রতি password-এর জন্য unique random salt ব্যবহার করুন।
• New builds-এর জন্য Argon2id পছন্দ করুন।
• Production-like hardware-এ cost parameters tune করুন।
• প্রতিটি hash-এর সঙ্গে algorithm এবং parameters সংরক্ষণ করুন।
• Parameters outdated হলে login-এর সময় rehash করুন।
• Passwords কখনও log করবেন না বা analytics tools-এ পাঠাবেন না।
• Credentials জমা দেওয়া হয় এমন সব জায়গায় TLS ব্যবহার করুন।
• Risk justified হলে MFA বা passkeys যোগ করুন।
• Reset flows-কে login flows-এর মতোই গুরুত্ব দিয়ে সুরক্ষিত করুন।
• Forced resets এবং user notification-এর জন্য incident plan রাখুন।

Password hashing আকর্ষণীয় কিছু নয়। এটি plumbing। কিন্তু এমন plumbing, যা নির্ধারণ করে একটি breach কেবল painful incident হবে, নাকি পুরো user base-এর disaster।

<!-- tool-cta:start -->

💡 এটি চেষ্টা করুন: Hash Generator দিয়ে দেখুন কীভাবে একই ইনপুট বিভিন্ন অ্যালগরিদমে ম্যাপ হয়, যা দ্রুত হ্যাশ এবং পাসওয়ার্ড-গ্রেড হ্যাশের পার্থক্যকে স্পষ্ট করে তোলে।

<!-- tool-cta:end -->

সৎ mental model

Password hashing নিয়ে ভাবার সেরা উপায় হলো এটি:

ব্যবহারকারী পাসওয়ার্ড টাইপ করার সময় hashing পাসওয়ার্ডকে সুরক্ষা দেয় না। ব্যবহারকারী logged in হওয়ার পর account-কে সুরক্ষা দেয় না। যারা web জুড়ে passwords reuse করেন, তাদের সুরক্ষা দেয় না।

এটি stored verifier-কে সুরক্ষা দেয়।

শুনতে সীমিত মনে হলেও এটি অত্যন্ত গুরুত্বপূর্ণ। Databases leak হয়। Backups leak হয়। Staging systems copy করা হয়। Vendors এমন access পায় যা তাদের থাকা উচিত নয়। Old exports object storage-এ এমন সময় পর্যন্ত পড়ে থাকে, যা কেউ মনে রাখে না।

এমন হলে, আপনার password storage design-ই পার্থক্য তৈরি করে: attackers কি passwords পাবে, নাকি একটি ব্যয়বহুল guessing problem পাবে।

পাসওয়ার্ড হ্যাশিং আসলে আপনাকে এটাই থেকে সুরক্ষা দেয়।