পাঠ ২৫ · ৬০-এর মধ্যে · মডিউল ৫
Home / Courses / Cybersecurity & Ethical Hacking / A07 অথেন্টিকেশন ফেইলিওর

A07: আইডেন্টিফিকেশন ও অথেন্টিকেশন ফেইলিওর

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

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

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

১ · A07 — পরিচয় যাচাই প্রক্রিয়ার দুর্বলতাসমূহ

Identification and Authentication FailuresIdentification and Authentication Failuresব্যবহারকারীর পরিচয় সঠিকভাবে যাচাই বা নিশ্চিত করতে ব্যর্থ হওয়ার সাথে সম্পর্কিত দুর্বলতার একটি ক্যাটাগরি — শুধু "ভুল পাসওয়ার্ড" নয়, পুরো অথেন্টিকেশন প্রক্রিয়ার ডিজাইন ও বাস্তবায়ন। একটি অ্যাপ্লিকেশনের সবচেয়ে গুরুত্বপূর্ণ নিরাপত্তা-সীমারেখাগুলোর একটি — কারণ একবার এই সীমারেখা ভাঙা গেলে আক্রমণকারী সরাসরি ভুক্তভোগীর পরিচয় নিয়ে কাজ করতে পারে।

দুর্বল/সাধারণ পাসওয়ার্ড অনুমোদন
"123456" বা "password"-এর মতো সহজে অনুমানযোগ্য পাসওয়ার্ড গ্রহণ করা, কোনো ন্যূনতম শক্তি-পরীক্ষা ছাড়াই।
রেট-লিমিটিং না থাকা
লগইন এন্ডপয়েন্টে ব্যর্থ চেষ্টার কোনো সীমা না থাকা — সীমাহীন ব্রুট-ফোর্স চেষ্টার সুযোগ (ties to L30)।
প্রেডিক্টেবল সেশন আইডি
সেশন টোকেন যদি ক্রমিক সংখ্যা বা সহজে অনুমানযোগ্য প্যাটার্নে তৈরি হয়, আক্রমণকারী অন্য ইউজারের সেশন অনুমান করতে পারে।
লগআউটে টোকেন ইনভ্যালিডেট না হওয়া
লগআউটের পরেও পুরনো সেশন টোকেন কার্যকর থেকে গেলে, চুরি হওয়া একটি পুরনো টোকেনও কাজে লাগানো যায়।

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

২ · কেন রেট-লিমিটিং সবচেয়ে গুরুত্বপূর্ণ একক নিয়ন্ত্রণ

যদি একটি লগইন এন্ডপয়েন্ট সীমাহীন সংখ্যক চেষ্টার অনুমতি দেয়, তাহলে একজন আক্রমণকারী প্রোগ্রাম্যাটিকভাবে হাজার হাজার (এমনকি লক্ষ লক্ষ) পাসওয়ার্ড অনুমান চেষ্টা করতে পারে — এটিই ব্রুট-ফোর্স আক্রমণBrute-Force Attackসম্ভাব্য প্রতিটি (বা একটি বড় তালিকার) পাসওয়ার্ড ধারাবাহিকভাবে চেষ্টা করে সঠিকটি খুঁজে বের করার আক্রমণ কৌশল — L30-এ বিস্তারিত। (L30-এ বিস্তারিত)। এমনকি একটি "মোটামুটি শক্তিশালী" পাসওয়ার্ডও সীমাহীন চেষ্টার সামনে চিরকাল টিকতে পারে না। রেট-লিমিটিং (কয়েকটি ব্যর্থ চেষ্টার পর সাময়িক বা স্থায়ী লকআউট) এই আক্রমণকে ব্যবহারিকভাবে অসম্ভব করে তোলে — আক্রমণকারী প্রতি লকআউট-উইন্ডোতে মাত্র কয়েকটি অনুমান চেষ্টা করতে পারবে, যা কার্যকর ব্রুট-ফোর্সের জন্য অপর্যাপ্ত।

৩ · প্রতিরক্ষা চেকলিস্ট

  • পাসওয়ার্ড কমপ্লেক্সিটি ও ব্রিচ-লিস্ট চেকিং — নতুন পাসওয়ার্ড সেট করার সময় তা পরিচিত-লিক-হওয়া পাসওয়ার্ড তালিকার সাথে না মেলে তা যাচাই করা।
  • রেট-লিমিট/লকআউট — নির্দিষ্ট সংখ্যক ব্যর্থ চেষ্টার পর অ্যাকাউন্ট সাময়িকভাবে লক করা।
  • ক্রিপ্টোগ্রাফিকভাবে র‍্যান্ডম সেশন টোকেন — অনুমানযোগ্য নয় এমন দীর্ঘ, র‍্যান্ডম টোকেন ব্যবহার করা।
  • MFA — বিশেষ করে সংবেদনশীল কাজের জন্য দ্বিতীয় প্রমাণ-ফ্যাক্টর দাবি করা।

৪ · কোড ডেমো — লগইন রেট-লিমিটিং ও লকআউট

নিচের কোড সেলটি সম্পূর্ণ স্যান্ডবক্সড — এটি একটি ভুয়া ইন-মেমরি ইউজার-ডেটাবেস ও একটি "ব্যর্থ চেষ্টা" কাউন্টার ব্যবহার করছে। কোনো বাস্তব নেটওয়ার্ক অথেন্টিকেশন সার্ভার এখানে জড়িত নয় — এটি শুধু লকআউট-লজিকটি প্রদর্শন করছে।

Python
# ভুয়া ইউজার-ডেটাবেস — শুধুই ইন-মেমরি ডিকশনারি
correct_passwords = {"anika": "S3cur3P@ss!"}

# প্রতিটি ইউজারের ব্যর্থ-চেষ্টার সংখ্যা ট্র্যাক করার জন্য
failed_attempts = {}
MAX_ATTEMPTS = 5

def login(username, password):
    if failed_attempts.get(username, 0) >= MAX_ATTEMPTS:
        return "লকড আউট — খুব বেশি ব্যর্থ চেষ্টার কারণে এই অ্যাকাউন্ট সাময়িকভাবে বন্ধ"

    correct = correct_passwords.get(username)
    if correct is not None and password == correct:
        failed_attempts[username] = 0  # সফল লগইনে কাউন্টার রিসেট
        return "লগইন সফল"

    failed_attempts[username] = failed_attempts.get(username, 0) + 1
    remaining = MAX_ATTEMPTS - failed_attempts[username]
    if remaining <= 0:
        return "ভুল পাসওয়ার্ড — এই ছিল শেষ সুযোগ, অ্যাকাউন্ট এখন লকড"
    return f"ভুল পাসওয়ার্ড — আর {remaining}টি চেষ্টা বাকি আছে"

# একজন আক্রমণকারী "anika"-র পাসওয়ার্ড ব্রুট-ফোর্স করার চেষ্টা করছে
guesses = ["12345", "password", "anika123", "qwerty", "letmein", "S3cur3P@ss!"]

for i, guess in enumerate(guesses, start=1):
    result = login("anika", guess)
    print(f"চেষ্টা #{i} (\"{guess}\"): {result}")

    
লক্ষ্য করুন — প্রথম ৫টি ভুল চেষ্টার পরই অ্যাকাউন্ট লকড হয়ে যায়, এবং ষষ্ঠ চেষ্টায় সঠিক পাসওয়ার্ড (S3cur3P@ss!) দেওয়া সত্ত্বেও লগইন প্রত্যাখ্যান করা হয় — কারণ ততক্ষণে অ্যাকাউন্টটি লকড। এটাই রেট-লিমিটিং-এর মূল শক্তি: এটি সঠিক পাসওয়ার্ড পরে পাওয়া গেলেও আক্রমণকারীকে থামিয়ে দেয়, কারণ বাস্তব ব্যবহারকারী প্রথম কয়েকটি চেষ্টাতেই সঠিক পাসওয়ার্ড দিয়ে দেয় — শুধুমাত্র একজন আক্রমণকারীই শত শত ভুল চেষ্টা করবে।
বাস্তব সিস্টেমে লকআউট সাধারণত স্থায়ী না রেখে একটি সময়-উইন্ডো (যেমন ১৫ মিনিট) পরে স্বয়ংক্রিয়ভাবে পুনরায় খুলে দেওয়া হয় — যাতে একজন বৈধ ব্যবহারকারী নিজের পাসওয়ার্ড কয়েকবার ভুল টাইপ করলে স্থায়ীভাবে লক না হয়ে যান (এটি নিজেই একটি Availability/ব্যবহারযোগ্যতা বিবেচনা, ties to L01-এর CIA Triad)।
মূল কথা · Key takeaway

A07-এর বেশিরভাগ ফিক্সই ব্যয়বহুল নতুন প্রযুক্তি নয় — এগুলো মৌলিক, সুপরিচিত নিয়ন্ত্রণ (রেট-লিমিটিং, র‍্যান্ডম টোকেন, MFA) যা প্রায়ই শুধু বাস্তবায়ন করতে ভুলে যাওয়া হয়। প্রতিটি অথেন্টিকেশন ফ্লো ডিজাইন করার সময় জিজ্ঞাসা করুন: "একজন আক্রমণকারী এই চেষ্টাটি কতবার পুনরাবৃত্তি করতে পারবে, এবং তাকে থামানোর নিয়ন্ত্রণ কোথায়?"

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

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

প্র ০১ রেট-লিমিটিং কেন সঠিক পাসওয়ার্ড দিয়েও লগইন ব্লক করে দিতে পারে — এটি কি একটি ডিজাইন ত্রুটি নাকি ইচ্ছাকৃত?

এটি সম্পূর্ণ ইচ্ছাকৃত এবং সঠিক আচরণ। লকআউট নিয়ন্ত্রণ ঠিক এই কারণেই কাজ করে যে এটি "কে সঠিক পাসওয়ার্ড জানে" তার উপর নির্ভর করে না — এটি নির্ভর করে "কতবার চেষ্টা করা হয়েছে" তার উপর। যদি লকআউট শুধুমাত্র ভুল পাসওয়ার্ডেই প্রযোজ্য হতো এবং সঠিক পাসওয়ার্ড সবসময় লকআউট বাইপাস করতে পারত, তাহলে আক্রমণকারী কখনো সঠিক পাসওয়ার্ড খুঁজে পেলে লকআউট তাকে থামাতে পারত না — যা পুরো নিয়ন্ত্রণটিকেই অকার্যকর করে দিত। তাই "লকড হলে সঠিক পাসওয়ার্ডও প্রত্যাখ্যাত" হওয়াটাই সঠিক নিরাপত্তা-আচরণ (usability trade-off সহ, যা টাইম-উইন্ডো লকআউট দিয়ে ব্যালেন্স করা হয়)।

প্র ০২ একটি প্রেডিক্টেবল সেশন আইডি (যেমন ক্রমিক সংখ্যা ১, ২, ৩...) কীভাবে অপব্যবহার হতে পারে, যদি পাসওয়ার্ড সিস্টেম নিজেই পুরোপুরি নিরাপদ থাকে?

পাসওয়ার্ড সিস্টেম নিরাপদ থাকলেও, একজন আক্রমণকারী যদি জানে সেশন আইডিগুলো ক্রমিকভাবে বরাদ্দ হয়, তাহলে সে নিজে একটি বৈধ লগইন করে নিজের সেশন আইডি (যেমন ১০০০) দেখে নিতে পারে, এরপর আশেপাশের সংখ্যাগুলো (৯৯৯, ৯৯৮, ১০০১...) সরাসরি অনুমান করে অন্য সাম্প্রতিক লগইন করা ব্যবহারকারীদের সেশন "চুরি" করার চেষ্টা করতে পারে — পাসওয়ার্ড না জেনেও। এই কারণেই সেশন টোকেন পাসওয়ার্ডের মতোই ক্রিপ্টোগ্রাফিকভাবে অনির্ণেয় (unpredictable) হতে হবে, এমনকি যদি পাসওয়ার্ড ব্যবস্থা নিজে নিখুঁত হয়।

প্র ০৩ MFA থাকা সত্ত্বেও একটি অ্যাকাউন্ট কীভাবে এখনো ঝুঁকিতে থাকতে পারে — MFA কি "সম্পূর্ণ" সমাধান?

MFA একটি শক্তিশালী কিন্তু নিখুঁত-নয় নিয়ন্ত্রণ। যদি দ্বিতীয় ফ্যাক্টরটি নিজেই দুর্বল হয় (যেমন SMS-ভিত্তিক কোড, যা SIM-swapping আক্রমণের মাধ্যমে চুরি করা সম্ভব — M9-এর সোশ্যাল ইঞ্জিনিয়ারিং টেকনিকের সাথে সম্পর্কিত), বা ব্যবহারকারী নিজেই সোশ্যাল-ইঞ্জিনিয়ারিং করে দ্বিতীয় কোডটি একজন আক্রমণকারীকে বলে দেয় (একটি ভুয়া "সাপোর্ট কল"-এ), তাহলে MFA-ও বাইপাস হতে পারে। এটি মনে করিয়ে দেয় যে কোনো একক নিয়ন্ত্রণই "নিখুঁত" নয় — নিরাপত্তা সবসময় একাধিক স্তরের (defense-in-depth) সমষ্টি।

অনুশীলন

  1. চিন্তা করুন: উপরের কোডে MAX_ATTEMPTS যদি 1 করে দেওয়া হয়, তাহলে ব্যবহারকারীর অভিজ্ঞতায় (usability) কী সমস্যা হতে পারে?

    MAX_ATTEMPTS = 1 মানে একজন বৈধ ব্যবহারকারী যদি টাইপো করে একবারও ভুল পাসওয়ার্ড দেন (যা সম্পূর্ণ স্বাভাবিক মানবিক ভুল), তার অ্যাকাউন্ট সাথে সাথে লকড হয়ে যাবে। এটি নিরাপত্তা ও ব্যবহারযোগ্যতার (Availability, ties to L01) মধ্যে একটি ভারসাম্যহীন সিদ্ধান্ত — অতিরিক্ত কড়া রেট-লিমিটিং বৈধ ব্যবহারকারীদের জন্য প্রতিনিয়ত বিরক্তিকর অভিজ্ঞতা তৈরি করে। বাস্তবে ৩-৫টি চেষ্টা একটি সাধারণ ভারসাম্যপূর্ণ মান।

  2. পরীক্ষা করুন: কোড সেলে guesses তালিকার শুরুতেই সঠিক পাসওয়ার্ড "S3cur3P@ss!" রেখে Run চাপুন — লকআউট কি তবুও ট্রিগার হয়?

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

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

পূর্ববর্তী পাঠ
A06: ভালনারেবল ও আউটডেটেড কম্পোনেন্ট