পাঠ ১৯ · ৬০-এর মধ্যে · মডিউল ৫
Home / Courses / Cybersecurity & Ethical Hacking / ক্রিপ্টোগ্রাফিক ফেইলিওর

A02: ক্রিপ্টোগ্রাফিক ফেইলিওর

A02: Cryptographic failures
৮ মিনিট পড়া মধ্যবর্তী · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • "Sensitive Data Exposure" থেকে "Cryptographic Failures" নামকরণ কেন পরিবর্তিত হলো (symptom বনাম root cause)
  • সবচেয়ে সাধারণ চারটি ক্রিপ্টো ব্যর্থতা — cleartext ট্রান্সমিশন, দুর্বল অ্যালগরিদম, হার্ডকোডেড কী, মিসিং at-rest এনক্রিপশন
  • কেন দ্রুত হ্যাশ ফাংশন (SHA-256/MD5) পাসওয়ার্ডের জন্য বিপজ্জনক, আর ধীর হ্যাশ (PBKDF2) কেন সঠিক
  • Python stdlib দিয়ে সঠিক পাসওয়ার্ড-হ্যাশিং প্যাটার্ন হাতে-কলমে দেখা

১ · "Sensitive Data Exposure" থেকে "Cryptographic Failures"

২০১৭ সালের OWASP তালিকায় এই ক্যাটাগরির নাম ছিল "Sensitive Data Exposure" — কিন্তু এই নাম শুধু লক্ষণ (symptom) বর্ণনা করত: ডেটা ফাঁস হয়েছে। ২০২১ সংস্করণে নাম বদলে Cryptographic FailuresCryptographic Failuresক্রিপ্টোগ্রাফির ভুল ব্যবহার বা অনুপস্থিতির কারণে সংবেদনশীল ডেটা এক্সপোজড হওয়া — root cause-ভিত্তিক নামকরণ। করা হয়েছে — কারণ ডেটা এক্সপোজ হওয়ার আসল কারণ (root cause) প্রায় সবসময় ক্রিপ্টোগ্রাফির ভুল ব্যবহার বা সম্পূর্ণ অনুপস্থিতি। L01-এর CIA Triad মনে করুন — এই পুরো ক্যাটাগরি সরাসরি Confidentiality রক্ষার ব্যর্থতা নিয়ে।

২ · সাধারণ ক্রিপ্টোগ্রাফিক ব্যর্থতাগুলো

Cleartext ট্রান্সমিশন
HTTPS/TLS ছাড়া সংবেদনশীল ডেটা পাঠানো — L08-এর প্যাকেট-স্নিফিং পাঠে দেখা হয়েছিল, নেটওয়ার্কে যে কেউ তা পড়ে ফেলতে পারে।
দুর্বল অ্যালগরিদম
পাসওয়ার্ড সংরক্ষণে MD5 বা SHA1 ব্যবহার — এগুলো দ্রুত ও (MD5-এর ক্ষেত্রে) ক্রিপ্টোগ্রাফিকভাবে ভাঙা, আধুনিক হার্ডওয়্যারে সহজেই brute-force করা যায়।
হার্ডকোডেড কী
এনক্রিপশন কী সরাসরি সোর্স কোডে লেখা — কোড লিক হলে (বা পাবলিক রিপোতে ভুলে কমিট হলে) কী-ও সাথে সাথে ফাঁস হয়ে যায়।
মিসিং at-rest এনক্রিপশন
ডেটাবেসে সংবেদনশীল ফিল্ড (যেমন জাতীয় পরিচয়পত্র নাম্বার) আনএনক্রিপ্টেড রাখা — ডেটাবেস ব্যাকআপ চুরি হলে সরাসরি পঠনযোগ্য।

৩ · পাসওয়ার্ড হ্যাশিং — কেন "দ্রুত" খারাপ, "ধীর" ভালো

একটি সাধারণ ভুল ধারণা: "হ্যাশ করলেই তো নিরাপদ।" কিন্তু hashlib.sha256-এর মতো ফাংশন ইচ্ছাকৃতভাবে অত্যন্ত দ্রুত — এটি ফাইল-ইন্টিগ্রিটি চেকের জন্য (L01) উপযুক্ত, কিন্তু পাসওয়ার্ডের জন্য বিপজ্জনক। কেন? কারণ একজন আক্রমণকারী যদি হ্যাশড পাসওয়ার্ডের একটি ডাটাবেস চুরি করে, একটি দ্রুত হ্যাশ ফাংশন দিয়ে সে প্রতি সেকেন্ডে লক্ষ লক্ষ সম্ভাব্য পাসওয়ার্ড ট্রাই করতে পারে (L30-এ brute force নিয়ে বিস্তারিত)।

এর সমাধান হলো PBKDF2PBKDF2Password-Based Key Derivation Function 2 — একটি ইচ্ছাকৃতভাবে ধীর হ্যাশ ফাংশন যা একটি "work factor" (iteration count) নিয়ে কাজ করে, brute-force আক্রমণকে হাজার-গুণ ব্যয়বহুল করে তোলে। Python stdlib-এ hashlib.pbkdf2_hmac হিসেবে পাওয়া যায়।-এর মতো একটি ইচ্ছাকৃতভাবে ধীর (deliberately slow) হ্যাশ ফাংশন ব্যবহার করা — এটি একটি "work factor" (iteration count) নেয়, যা যত বেশি হবে প্রতিটি একক পাসওয়ার্ড-চেষ্টার খরচ তত বাড়বে, brute-force আক্রমণকে ব্যবহারিকভাবে অসম্ভব করে তুলবে।

Python
import hashlib

password = "MyBankPassword!2024"
salt = b"a-unique-random-salt-per-user"

# ভুল প্যাটার্ন: একটি সাধারণ, দ্রুত হ্যাশ — পাসওয়ার্ডের জন্য অনুপযুক্ত
naive_hash = hashlib.sha256(password.encode()).hexdigest()

# সঠিক প্যাটার্ন: PBKDF2 — ইচ্ছাকৃতভাবে ধীর, একটি work-factor (iterations) সহ
correct_hash = hashlib.pbkdf2_hmac(
    "sha256",            # অন্তর্নিহিত হ্যাশ অ্যালগরিদম
    password.encode(),   # আসল পাসওয়ার্ড
    salt,                # প্রতি-ইউজার ইউনিক সল্ট (rainbow table প্রতিরোধ করে, L39-এ বিস্তারিত)
    200_000,             # work factor — যত বেশি iteration, brute-force তত ব্যয়বহুল
).hex()

print("প্লেইন SHA-256 (ভুল প্যাটার্ন):")
print(" ", naive_hash)
print()
print("PBKDF2, 200,000 iterations (সঠিক প্যাটার্ন):")
print(" ", correct_hash)
print()
print("SHA-256 প্রতি সেকেন্ডে লক্ষ লক্ষ বার চালানো যায় -> brute-force সহজ।")
print("PBKDF2 প্রতিটি চেষ্টায় ইচ্ছাকৃতভাবে ২,০০,০০০ গুণ বেশি কাজ করে -> brute-force ব্যবহারিকভাবে অসম্ভব।")

    
মূল কথা · Key takeaway

"হ্যাশ করা হয়েছে" আর "সঠিকভাবে হ্যাশ করা হয়েছে" — এই দুটো এক জিনিস নয়। ফাইল-ইন্টিগ্রিটি বা ডিজিটাল সিগনেচারের জন্য দ্রুত হ্যাশ (SHA-256) ঠিক আছে, কিন্তু পাসওয়ার্ড সংরক্ষণের জন্য সবসময় একটি ইচ্ছাকৃতভাবে ধীর, সল্টেড অ্যালগরিদম (PBKDF2, bcrypt, বা Argon2) ব্যবহার করতে হবে। "কোন হ্যাশ ব্যবহার করব" প্রশ্নের উত্তর সবসময় নির্ভর করে কী রক্ষা করছেন তার উপর।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ "Sensitive Data Exposure" নাম থেকে "Cryptographic Failures"-এ পরিবর্তন কেন একটি গুরুত্বপূর্ণ conceptual উন্নতি?

"Sensitive Data Exposure" শুধু ফলাফল বর্ণনা করে ("ডেটা ফাঁস হয়েছে") — এটি ডেভেলপারকে বলে না ঠিক কী ঠিক করতে হবে। "Cryptographic Failures" সরাসরি root cause-এ ফোকাস করে — এটি স্পষ্ট করে দেয় যে সমাধান খুঁজতে হবে এনক্রিপশন/হ্যাশিং বাস্তবায়নে, শুধু "আরও সতর্ক থাকা"-র মতো অস্পষ্ট পরামর্শে নয়।

প্র ০২ একই SHA-256 ফাংশন L01-এ ফাইল-ইন্টিগ্রিটি চেকের জন্য "ভালো" বলা হয়েছিল, অথচ এই পাঠে পাসওয়ার্ডের জন্য "খারাপ" বলা হচ্ছে কেন — এটা কি স্ববিরোধী?

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

প্র ০৩ হার্ডকোডেড এনক্রিপশন কী কেন বিশেষভাবে বিপজ্জনক, শুধু "কী চুরি হতে পারে" ছাড়াও আরেকটি কারণ কী হতে পারে?

সরাসরি চুরি ছাড়াও, হার্ডকোডেড কী ঘোরানো (rotate) করা কঠিন — যদি কী কখনো compromise হয়, প্রতিটি ডিপ্লয়মেন্টে কোড পরিবর্তন করে নতুন কী বসাতে হয়, যা ধীর ও ঝুঁকিপূর্ণ প্রক্রিয়া। সঠিক অনুশীলন হলো কী একটি আলাদা, সুরক্ষিত সিক্রেট-ম্যানেজমেন্ট সিস্টেমে রাখা, যাতে দ্রুত ও নিরাপদে পরিবর্তন করা যায়।

অনুশীলন

  1. চিন্তা করুন: আপনার ব্যবহৃত কোনো অ্যাপ যদি ডেটাবেসে পাসওয়ার্ড প্লেইন SHA-256 দিয়ে সংরক্ষণ করে, আর সেই ডেটাবেস চুরি হয়ে যায় — এর প্রভাব কী হতে পারে?

    যেহেতু SHA-256 দ্রুত, আক্রমণকারী একটি সাধারণ কম্পিউটার দিয়েই কোটি কোটি সাধারণ/লিকড পাসওয়ার্ড চেষ্টা করে অনেক ইউজারের আসল পাসওয়ার্ড উদ্ধার করতে পারবে (dictionary attack, L30)। যেহেতু মানুষ প্রায়ই একই পাসওয়ার্ড একাধিক সাইটে ব্যবহার করে, এটি অন্য সাইটেও credential-stuffing আক্রমণের পথ খুলে দেয়।

  2. পরীক্ষা করুন: উপরের কোড সেলে 200_000 সংখ্যাটি বদলে 1 করে দেখুন — hash আউটপুট বদলে যায় কিনা লক্ষ করুন।

    হ্যাঁ, আউটপুট সম্পূর্ণ বদলে যাবে — কারণ iteration count নিজেই হ্যাশ-প্রসেসের অংশ, শুধু "একবার বেশি হ্যাশ চালানো" নয়। তবে মূল শিক্ষণীয় বিষয়: iterations=1 কার্যত plain হ্যাশের সমতুল্য দ্রুত হয়ে যায় — তাই বাস্তব সিস্টেমে সবসময় একটি যথেষ্ট বড় work-factor বজায় রাখা জরুরি।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
L18 · A01: ব্রোকেন অ্যাক্সেস কন্ট্রোল