intermediate#security#hashing#databaseUpdated: 2026-07-15

পাসওয়ার্ড কীভাবে সংরক্ষিত হয়?

তুমি ভাবো ওয়েবসাইট তোমার পাসওয়ার্ড একটা ঘরে লিখে রাখে। নিরাপদ সাইট তা করে না — করলে হ্যাকার ডেটাবেজ চুরি করলেই সব ব্যবহারকারীর পাসওয়ার্ড সরাসরি পেয়ে যেত।

কেন এই সাবধানতা দরকার হলো?

ইন্টারনেটের শুরুর দিকে অনেক ওয়েবসাইট সত্যিই Plain Text-এ (হুবহু) পাসওয়ার্ড রাখত। বারবার বড় ডেটাবেজ ফাঁসের ঘটনায় (একবারে কোটি কোটি পাসওয়ার্ড ফাঁস) দেখা গেছে, একই পাসওয়ার্ড মানুষ একাধিক সাইটে ব্যবহার করে — একটি সাইট ফাঁস হলে হ্যাকার সেই পাসওয়ার্ড দিয়ে ব্যাংক অ্যাকাউন্টও খুলে ফেলতে পারত। এই বিপর্যয় এড়াতেই Hashing পদ্ধতি প্রমিত (standard) হয়ে ওঠে।

ধাপ ১ — Hashing: একমুখী রূপান্তর

সাইট পাসওয়ার্ডকে একটা Hash Function দিয়ে এমন এলোমেলো, নির্দিষ্ট-দৈর্ঘ্যের স্ট্রিং-এ বদলে দেয়, যেটা উল্টে আসল পাসওয়ার্ড বের করা প্রায় অসম্ভব।

"hsc2026"  →  hash function (SHA-256 ইত্যাদি)  →  a3f9c1e8b2...
একই ইনপুট সবসময় একই hash দেয়, কিন্তু hash থেকে ইনপুট ফেরানো কার্যত অসম্ভব।

কেন "একমুখী"? সাধারণ গণিতের বিপরীত অপারেশন থাকে (যোগের বিপরীত বিয়োগ), কিন্তু Hash Function এমনভাবে ডিজাইন করা যে তার কোনো "বিপরীত সূত্র" নেই — শুধু হাজার কোটি সম্ভাব্য ইনপুট একে একে চেষ্টা করে (Brute Force) মিলিয়ে দেখা ছাড়া উপায় নেই, যা বাস্তবে অবাস্তব সময়সাপেক্ষ।

ধাপ ২ — ডেটাবেজে শুধু Hash

ডেটাবেজে আসল পাসওয়ার্ড নয়, শুধু তার Hash জমা থাকে।

ইউজারডেটাবেজে জমা থাকে
rahima3f9c1e8b2... (hash)
karim7d2e9f0a1c... (hash)

ধাপ ৩ — লগইনের সময় মেলানো

তুমি লগইনের সময় পাসওয়ার্ড দিলে সাইট তাৎক্ষণিকভাবে সেটার Hash বের করে, ডেটাবেজে সংরক্ষিত Hash-এর সাথে তুলনা করে। দুটো Hash মিললে লগইন সফল হয় — অথচ সিস্টেম কখনোই তোমার আসল পাসওয়ার্ড "জানে না" বা সংরক্ষণ করে না।

ধাপ ৪ — Salt: বাড়তি সুরক্ষা

শুধু Hashing-এও একটি সমস্যা আছে — যদি দুজন ব্যবহারকারীর পাসওয়ার্ড একই হয় (যেমন দুজনেই "123456" ব্যবহার করে), তাদের Hash-ও হুবহু একই হবে। হ্যাকার আগে থেকে তৈরি করা "Rainbow Table" (লক্ষ লক্ষ সাধারণ পাসওয়ার্ড ও তাদের Hash-এর তালিকা) দিয়ে এই মিল ধরে ফেলতে পারে।

সমাধান: প্রতিটি পাসওয়ার্ডের সাথে একটা আলাদা র‍্যান্ডম Salt (এলোমেলো অতিরিক্ত অক্ষরগুচ্ছ) যোগ করে তারপর Hash করা হয় — ফলে দুজনের আসল পাসওয়ার্ড এক হলেও তাদের Hash সম্পূর্ণ ভিন্ন হয়ে যায়, Rainbow Table কাজ করে না।

"123456" + Salt(x7k9) → hash → ফলাফল A
"123456" + Salt(p2m4) → hash → ফলাফল B (সম্পূর্ণ ভিন্ন, যদিও মূল পাসওয়ার্ড একই)

বাস্তব জীবনের সাথে মিল

🏠 অ্যানালজি: Hashing অনেকটা ডিম ভাঙার মতো — ডিম থেকে অমলেট বানানো সহজ, কিন্তু অমলেট থেকে আবার আস্ত ডিম ফিরিয়ে আনা অসম্ভব। ডেটাবেজে "অমলেট" (hash) থাকে; সাইট যাচাই করতে নতুন করে "অমলেট" বানিয়ে (নতুন hash করে) আগেরটার সাথে মেলায়, "ডিম" (আসল পাসওয়ার্ড) কখনো ফিরিয়ে আনার দরকার হয় না।

কেন এত সাবধানতা?

ডেটাবেজ চুরি গেলেও হ্যাকার শুধু Hash (ও Salt) পায় — আসল পাসওয়ার্ড নয়। ভালোভাবে Salt করা Hash ভাঙতে বাস্তবে হাজার-লক্ষ বছর সময় লাগতে পারে। এজন্যই দায়িত্বশীল সাইট "পাসওয়ার্ড ভুলে গেছ?" অপশনে পুরোনো পাসওয়ার্ড কখনো দেখায় না — শুধু নতুন পাসওয়ার্ড সেট করতে বলে, কারণ তারা নিজেরাও পুরোনোটা জানে না।

Hashing বনাম Encryption

বৈশিষ্ট্যHashingEncryption
দিকএকমুখী, উল্টানো যায় নাদ্বিমুখী, সঠিক Key দিয়ে উল্টানো যায়
উদ্দেশ্যযাচাই (verification)গোপন রাখা, পরে ফিরিয়ে পড়া
উদাহরণপাসওয়ার্ডমেসেজিং অ্যাপে চ্যাট (End-to-End Encryption)

🔗 HSC সিলেবাস সংযোগ

  • অধ্যায় ১: তথ্য নিরাপত্তা, ক্রিপ্টোগ্রাফি, সাইবার ক্রাইম।
  • অধ্যায় ৬: ডেটাবেজে সংবেদনশীল তথ্য সংরক্ষণ।

📝 HSC পরীক্ষার প্রস্তুতি

  • Hashing কী? ডেটাকে নির্দিষ্ট দৈর্ঘ্যের একমুখী কোডে রূপান্তরের প্রক্রিয়া।
  • Hashing বনাম Encryption? Encryption উল্টানো যায় (Key দিয়ে), Hashing যায় না।
  • Salt কেন? একই পাসওয়ার্ডের Hash আলাদা করতে, Rainbow Table আক্রমণ ঠেকাতে।
  • সাধারণ ভুল: Hashing-কে Encryption ভাবা — দুটো ভিন্ন উদ্দেশ্যে ব্যবহৃত ভিন্ন প্রযুক্তি।

📚 সারাংশ

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