bcrypt বনাম Argon2: পাসওয়ার্ড হ্যাশিং সেটিংস বেছে নেওয়া

পাসওয়ার্ড হ্যাশিং কী সমস্যার সমাধান করে\n\nপাসওয়ার্ড হ্যাশিং ব্যাকএন্ডকে পাসওয়ার্ড সরাসরি সংরক্ষণ না করেই তা সংরক্ষণ করার সক্ষমতা দেয়। কেউ সাইন আপ করলে সার্ভার পাসওয়ার্ডকে একটি ওয়ান-ওয়ে ফাংশনের মাধ্যমে পাঠায় এবং ফলাফল (হ্যাশ) সংরক্ষণ করে। লগইনে, ব্যবহারকারী যে পাসওয়ার্ড টাইপ করেছে তা আবার হ্যাশ করে সংরক্ষিত মানের সঙ্গে তুলনা করা হয়।\n\nএকটি হ্যাশ এনক্রিপশন নয়। এটিকে ডিক্রিপ্ট করার উপায় নেই। এই ওয়ান-ওয়ে বৈশিষ্ট্যই পাসওয়ার্ডের জন্য হ্যাশিং ব্যবহারের কারণ।\n\nতাহলে কেন SHA-256 মত দ্রুত হ্যাশ ব্যবহার করবেন না? কারণ দ্রুতই আক্রমণকারীদের পছন্দ। যদি ডাটাবেস চুরি হয়, আক্রমণকারীরা এক একটি করে লগইন করে অনুমান করে না। তারা চুরি করা হ্যাশ তালিকার বিরুদ্ধে অফলাইনে অনুমান চালায় এবং তাদের হার্ডওয়্যারের ক্ষমতা অনুযায়ী দ্রুত অনুমান চালায়। GPU দিয়ে দ্রুত হ্যাশ বড় পরিসরে পরীক্ষা করা যায়। অনন্য সাল্ট থাকলেও একটি দ্রুত হ্যাশ এখনও ব্রুটফোর্স করার জন্য সস্তা হয়।\n\nবাস্তবসম্মত ব্যর্থতা মোডটা হলো: একটি ছোট ওয়েব অ্যাপের ইউজার টেবিল ব্রিচে চলে যায়। আক্রমণকারী ইমেইল এবং পাসওয়ার্ড হ্যাশ পায়। যদি সেই হ্যাশগুলো দ্রুত ফাংশন দিয়ে তৈরি হয়, সাধারণ পাসওয়ার্ড এবং ছোট ভ্যারিয়েশন দ্রুত টুটে যায়। তারপর আক্রমণকারী একই পাসওয়ার্ড অন্য সাইটে চেষ্টা করে (credential stuffing), বা আপনার অ্যাপের উচ্চ-প্রিভিলেজ ফিচারে প্রবেশের চেষ্টা করে।\n\nএকটি ভালো পাসওয়ার্ড হ্যাশ অনুমানকে ব্যয়বহুল করে তোলে। লক্ষ্য "অঘাত্য" নয়—লক্ষ্য হলো "অনেক ধীর ও ব্যয়বহুল যাতে আক্রমণ করা দরকারি না হয়।"\n\nএকটি পাসওয়ার্ড হ্যাশিং সেটআপ হওয়া উচিত:\n\n- একদিক থেকে (ওয়ান-ওয়ে) যাচাই করা যায়, উল্টানো যায় না\n- প্রতি অনুমান ধীর হতে হবে\n- সমান্তরাল হার্ডওয়্যারের (বিশেষ করে GPU) জন্য ব্যয়বহুল হতে হবে\n- বাস্তব লগইন এখনও স্বাভাবিক লাগার মতো দ্রুত হতে হবে\n- সময়ের সাথে কস্ট বাড়িয়ে নেওয়ার জন্য অ্যাডজাস্টেবল হতে হবে\n\n## এক মিনিটে bcrypt এবং Argon2\n\nযখন আপনি bcrypt বনাম Argon2 তুলনা করেন, আপনি বেছে নিচ্ছেন কিভাবে ডাটাবেস লিকের পরে পাসওয়ার্ড অনুমান ধীর করবেন।\n\nbcrypt পুরনো এবং বিস্তৃতভাবে সাপোর্টেড অপশন। এটি CPU-ভিত্তিকভাবে ব্যয়বহুল করার জন্য ডিজাইন করা এবং এর একটি প্রধান টিউনিং নাবব আছে: কস্ট ফ্যাক্টর। এটি "নির্বিচারে ভালো"—লাইব্রেরিতে সহজে পাওয়া যায়, ডিপ্লয় করা সহজ এবং পূর্বানুমেয়।\n\nArgon2 নতুন এবং মেমরি-হার্ড হওয়ার জন্য তৈরি। এটি প্রতিটি পাসওয়ার্ড অনুমানকে উল্লেখযোগ্য পরিমাণ RAM ব্যবহার করাতে পারে, শুধুমাত্র CPU নয়। এটা গুরুত্বপূর্ণ কারণ আক্রমণকারীরা প্রায়শই GPU বা বিশেষায়িত হার্ডওয়্যারে প্রচুর অনুমান সমান্তরালে চালিয়ে সফল হয়। মেমরি সেই ধরনের সমান্তরালে স্কেল করা কঠিন এবং ব্যয়বহুল।\n\nArgon2-এর তিনটি ভ্যারিয়েন্ট আছে:\n\n- Argon2i: কিছু সাইড-চ্যানেল আক্রমণের বিরুদ্ধে রেসিস্ট্যান্সে জোর দেয়\n- Argon2d: GPU প্রতিরোধে গুরুত্ব আরোপ করে, সাইড-চ্যানেল বিবেচনাগুলো সহ\n- Argon2id: উভয়ের একটি ব্যবহারিক মিশ্রণ, এবং পাসওয়ার্ড হ্যাশিংয়ের জন্য সাধারণ ডিফল্ট\n\nআপনার স্ট্যাক যদি Argon2id সাপোর্ট করে এবং আপনি নিরাপদভাবে মেমরি টিউন করতে পারেন, সাধারণত এটি আধুনিক ডিফল্ট হিসেবে সেরা। যদি পুরনো সিস্টেমের মাঝে সর্বোচ্চ সামঞ্জস্য দরকার হয়, তখন যথেষ্ট উচ্চ কস্ট ফ্যাক্টর সহ bcrypt এখনও একটি শক্তিশালী পছন্দ।\n\n## সবচেয়ে গুরুত্বপূর্ণ নিরাপত্তা বৈশিষ্ট্যগুলো\n\nমূল প্রশ্ন সহজ: যদি আক্রমণকারী পাসওয়ার্ড ডাটাবেস চুরি করে, বড় পরিসরে পাসওয়ার্ড অনুমান করা কতটা ব্যয়বহুল?\n\nbcrypt-এ আপনি কস্ট (ওয়ার্ক ফ্যাক্টর) নিয়ন্ত্রণ করেন। কস্ট বাড়ালে প্রতি অনুমান আরো সময় নেয়। এটি আক্রমণকারীদের ধীর করে দেয়, কিন্তু একই সাথে আপনার নিজের লগইন যাচাইও ধীর করে—তাই এটিকে এমন একটি বিন্দুতে টিউন করা হয় যা আক্রমণকারীদের জন্য কষ্টদায়ক কিন্তু ব্যবহারকারীদের জন্য গ্রহণযোগ্য।\n\nArgon2id-এ আপনি টাইম কস্টের পাশাপাশি মেমরি-হার্ডনেস যোগ করতে পারেন। প্রতিটি অনুমান CPU সময় এবং নির্দিষ্ট প্যাটার্নে RAM অ্যাক্সেস করে। GPU গুলো গণিত-ভিত্তিক কাজগুলোতে অত্যন্ত দ্রুত হতে পারে, কিন্তু প্রতিটি সমান্তরাল অনুমান যদি উল্লেখযোগ্য মেমরি চায় তবে GPU এর সুবিধা অনেকটাই কমে যায়।\n\nসাল্ট অপরিহার্য। প্রতিটি পাসওয়ার্ডের জন্য একটি অনন্য, র্যান্ডম সাল্ট:\n\n- প্রিকম্পিউটেড টেবিলকে আপনার ডাটাবেস জুড়ে পুনরায় ব্যবহার করা থেকে রোধ করে\n- একই পাসওয়ার্ড থাকা ব্যবহারকারীদের মধ্যে একই হ্যাশ তৈরি হওয়া রোধ করে\n\nসাল্ট দুর্বল পাসওয়ার্ডকে শক্তিশালী করে না। এগুলো মূলত ডাটাবেস ফাঁসের পর আক্রমণকারীদের প্রতি ব্যবহারকারীর ক্ষেত্রে বাস্তব কাজ করতে বাধ্য করে।\n\n## bcrypt-এর শক্তি ও সীমাবদ্ধতাসমূহ\n\nbcrypt এখনো ব্যাপকভাবে ব্যবহৃত, প্রায়ই কারণ এটি সব জায়গায় স্থাপন করা সহজ। এটি সাধারণত ভালো ফিট যখন আপনাকে বিস্তৃত আন্তর্জাতিক সামঞ্জস্য দরকার, আপনার স্ট্যাকের ক্রিপ্টো অপশন সীমিত, অথবা আপনি একটি সহজ টিউনিং লিভার চান।\n\nবড় “গটচা” হলো 72-বাইট পাসওয়ার্ড সীমা। bcrypt কেবল পাসওয়ার্ডের প্রথম 72 বাইট ব্যবহার করে এবং বাকি উপেক্ষা করে। দীর্ঘ পাসফ্রেজ বা পাসওয়ার্ড ম্যানেজার ব্যবহারকারীদের জন্য এটি আশ্চর্য হতে পারে।\n\nআপনি bcrypt বেছে নিলে পাসওয়ার্ড দৈর্ঘ্যের আচরণ স্পষ্ট করে জানান। অথবা একটি সর্বোচ্চ দৈর্ঘ্য (বাইটে, চরিত্রে নয়) জোর দিন অথবা দীর্ঘ ইনপুটগুলো ধারাবাহিকভাবে হ্যান্ডেল করুন। প্রধান বিষয় হলো নীরবে ট্রাঙ্কেশন এড়ানো যাতে ব্যবহারকারী যা মনে করছেন তার সাথে তাদের পাসওয়ার্ডটি মিলে যায়।\n\nbcrypt সমসাময়িক সমান্তরাল ক্র্যাকিং হার্ডওয়্যারের তুলনায় কম প্রতিরোধী। এর প্রতিরক্ষা এখনও বৈধ, কিন্তু এটি বিশেষভাবে প্রতি অনুমানকে ব্যয়বহুল রাখার উপর নির্ভর করে—অর্থাৎ কস্ট ফ্যাক্টর সঠিকভাবে নির্বাচন করা জরুরি।\n\nআপনি যদি নতুন সিস্টেম নির্মাণ করছেন বা উচ্চ-মূল্যের অ্যাকাউন্ট থাকে (পেইড প্ল্যান, অ্যাডমিন), তাহলে নতুন হ্যাশগুলোকে Argon2id-এ মাইগ্রেট করা এবং একই সাথে বিদ্যমান bcrypt হ্যাশগুলোকে ব্যবহারকারী লগইন করলে গ্রহণ করা সাধারণ ও কম-ঝুঁকির পথ।\n\n## Argon2-এর শক্তি ও ট্রেডঅফ\n\nArgon2 পাসওয়ার্ড হ্যাশিংয়ের জন্য তৈরি করা হয়েছে। বেশিরভাগ টিম Argon2id নির্বাচন করে কারণ এটি GPU প্রতিরোধ ও সাইড-চ্যানেল সুরক্ষার মধ্যে সমতা রাখে।\n\nArgon2id আপনাকে তিনটি প্যারামিটার দেয়:\n\n- Memory (m): প্রতিটি হ্যাশ চালানোর সময় কত RAM ব্যবহার হবে\n- Time/iterations (t): মেমরির উপর কতবার পাস করা হবে\n- Parallelism (p): কতটি লেইন ব্যবহার করবে (মাল্টি-কোর CPUs-এ সাহায্য করে)\n\nমেমরি হলো প্রধান সুবিধা। যদি প্রতিটি অনুমান উল্লেখযোগ্য পরিমাণ RAM চান, আক্রমণকারীরা একই সময়ে অনেকগুলো অনুমান চালাতে হলে RAM ক্ষমতা ও ব্যান্ডউইথের জন্য প্রচুর খরচ করতে হবে।\n\nনুকসান হলো অপারেশনাল: প্রতি হ্যাশ বেশি মেমরি লাগলে আপনার সার্ভার একসময়ে কম কনকারেন্ট লগইন হ্যান্ডেল করতে পারে। যদি আপনি মেমরি খুব বেশি সেট করেন, লগইন স্পাইকসের সময় কিউ তৈরি হওয়া, টাইমআউট বা আউট-অফ-মেমরি সমস্যা হতে পারে। এছাড়া দুর্ব্যবহার ভাবতেও হবে: অনেক কনকারেন্ট লগইন চেষ্টা যদি সীমাবদ্ধ না করা হয় তবে এটি রিসোর্স সমস্যা সৃষ্টি করতে পারে।\n\nArgon2id নিরাপদ ও ব্যবহারযোগ্য রাখতে এটাকে পারফরম্যান্স বৈশিষ্ট্যের মতো টিউন করুন:\n\n- প্রোডাকশন-সদৃশ হার্ডওয়্যারে বেঞ্চমার্ক করুন\n- কনকারেন্ট হ্যাশিং কাজ সীমাবদ্ধ করুন (ওয়ার্কার ক্যাপ, কিউ)\n- লগইন চেষ্টা রেট-লিমিট করুন এবং বারবার ব্যর্থ হলে লক আউট দিন\n- সার্ভিসগুলোর মধ্যে সেটিংস সঙ্গত রাখুন যাতে একটি দুর্বল এন্ডপয়েন্ট টার্গেট না হয়\n\n## বাস্তব ওয়েব ব্যাকএন্ডে পারফরম্যান্স খরচ\n\nপাসওয়ার্ড হ্যাশিংয়ে "দ্রুততাই ভালো" সাধারণত ভুল লক্ষ্য। আপনি চান প্রতিটি অনুমান আক্রমণকারীর জন্য ব্যয়বহুল হোক, তবু বাস্তব ব্যবহারকারীদের জন্য লগইন দ্রুত লাগে।\n\nএকটি ব্যবহারিক উপায় হলো আপনার প্রকৃত প্রোডাকশন হার্ডওয়্যারে প্রতিটি যাচাইয়ের জন্য একটি সময় বাজেট নির্ধারণ করা। অনেক টিম প্রায় 100 থেকে 300 ms প্রতি হ্যাশ চেক লক্ষ্য করে, কিন্তু সঠিক সংখ্যা আপনার ট্রাফিক ও সার্ভার নির্ভর। bcrypt ও Argon2-র মধ্যে পার্থক্য হলো আপনি কোথায় খরচ করছেন: bcrypt মূলত CPU সময়ে খরচ করে, যেখানে Argon2 মেমরি রিজার্ভও করতে পারে।\n\n### একটি লক্ষ্য সময় বেছে নিন, তারপর মাপুন\n\nএকটি লক্ষ্য হ্যাশ সময় বেছে নিন এবং প্রোডাকশন-সদৃশ শর্তে তা টেস্ট করুন। সাইনআপ/পাসওয়ার্ড-চেইঞ্জ হ্যাশিং এবং লগইন যাচাই দুটোই মাপুন, কিন্তু লগইনকে হট পাথ হিসেবে বিবেচনা করুন।\n\nহালকা ওজনের একটি মেজারমেন্ট প্ল্যান:\n\n- 1, 10, এবং 50 কনকারেন্ট লগইন চেক টেস্ট করুন এবং p50 ও p95 ল্যাটেন্সি রেকর্ড করুন\n- ক্যাশিং ও CPU বুস্টিং থেকে শব্দ কমাতে রানগুলো পুনরাবৃত্তি করুন\n- ডাটাবেস কল আলাদা মাপুন যাতে আপনি জানেন হ্যাশিং আসলে কত খরচ করছে\n- একই কন্টেইনার ও CPU লিমিট নিয়ে টেস্ট করুন যেটা আপনি ডিপ্লয় করবেন\n\n### স্পাইকগুলো গড়ের চেয়ে বেশি গুরুত্বপূর্ণ\n\nঅনেক সিস্টেম শিখরে ব্যর্থ হয়। যদি একটি মার্কেটিং ইমেইল ব্যবহারকারীদের লগইনে ঢেলে দেয়, আপনার হ্যাশিং সেটিংসই নির্ধারণ করবে সিস্টেম প্রতিক্রিয়াশীল থাকবে কি না।\n\nযদি একটি যাচাইকরণ 250 ms নেয় এবং আপনার সার্ভার একসাথে 40টি হ্যান্ডেল করতে পারে কিউ হওয়ার আগে, 500 লগইন অনুরোধের এক স্পাইক মিলিয়ন সেকেন্ডের অপেক্ষায় পরিণত করতে পারে। এমন পরিস্থিতিতে কস্ট সামান্য কমানো এবং শক্তিশালী রেট-লিমিট কড়া করা বাস্তবে নিরাপত্তা বাড়িয়ে দিতে পারে, তুলনায় প্যারামিটারগুলো এমন পর্যায়ে ঠেলে দেওয়া যেখানে লগইন এন্ডপয়েন্ট ভঙ্গুর হয়ে যায়।\n\n### ইন্টারঅ্যাকটিভ লগইনকে পূর্বানুমেয় রাখুন\n\nপ্রতিটি পাসওয়ার্ড অপারেশন একই জরুরীতা প্রয়োজন করে না। ইন্টারঅ্যাকটিভ লগইনের কস্ট স্থিতিশীল রাখুন, তারপর ভারী কাজ ক্রিটিকাল পাথের বাইরে নিয়ে যান। একটি সাধারণ প্যাটার্ন হলো rehash-on-login (সফল লগইনের ঠিক পরে ব্যবহারকারীর হ্যাশ আপগ্রেড করা) বা ব্যাকগ্রাউন্ড জবগুলো মাইগ্রেশন ও ইমপোর্টের জন্য ব্যবহার করা।\n\n## ধাপে ধাপে প্যারামিটার কিভাবে বাছবেন\n\nপ্যারামিটার টিউন করা মানে আক্রমণকারীদের প্রতি অনুমান খরচ বাড়ানো, ব্যবহারকারীর সাইন-ইন ধীর বা সার্ভারকে অস্থিতিশীল না করা।\n\n1. আপনার স্ট্যাক ভালভাবে কোন আলগোরিদম সাপোর্ট করে তা বেছে নিন। Argon2id যদি ভাল সাপোর্ট করে থাকে এটি সাধারণত ডিফল্ট; না হলে bcrypt ঠিক আছে।\n\n2. প্রোডাকশন-সদৃশ হার্ডওয়্যারে প্রতি হ্যাশের লক্ষ্য সময় সেট করুন। পিক লোডের সময়ও লগইন মসৃণ রাখে এমন কিছু বেছে নিন।\n\n3. টাইম হিট করার জন্য টিউন করুন। bcrypt-এ কস্ট ফ্যাক্টর সমন্বয় করুন। Argon2id-এ মেমরি, ইটারেশন, এবং প্যারালালিজম ব্যালান্স করুন। মেমরি হল আক্রমণকারীর অর্থনীতিকে সবচেয়ে বেশি পরিবর্তন করে।\n\n4. হ্যাশের সঙ্গে আলগোরিদম ও সেটিংস সংরক্ষণ করুন। বেশিরভাগ স্ট্যান্ডার্ড হ্যাশ ফরম্যাট এই বিবরণ এমবেড করে। এছাড়া নিশ্চিত করুন আপনার ডাটাবেস ফিল্ড যথেষ্ট লম্বা যেন হ্যাশ কখনও ট্রাঙ্কেট না হয়।\n\n5. রিহ্যাশ-অন-লগইন দিয়ে আপগ্রেড পরিকল্পনা করুন। যখন ইউজার লগইন করে, যদি তাদের সংরক্ষিত হ্যাশ আপনার বর্তমান পলিসির থেকে দুর্বল হয়, রিহ্যাশ করে তা প্রতিস্থাপন করুন।\n\n### একটি ব্যবহারিক স্টার্টিং পয়েন্ট\n\nপরিমাপের আগে যদি বেসলাইন দরকার হয়, সংরক্ষণ করে শুরু করুন এবং টাইমিং দেখে সামঞ্জস্য করুন।\n\n- bcrypt-এর জন্য অনেক দল কস্ট 12 থেকে শুরু করে এবং বাস্তব মাপ অনুযায়ী সামঞ্জস্য করে।\n- Argon2id-এর জন্য একটি সাধারণ বেসলাইন হলো মেমরি কয়েক দশমেগাবাইট থেকে কয়েক শত MB পরিসরে, টাইম কস্ট 2–4, এবং প্যারালালিজম 1–2।\n\nএগুলো নীতিমালা নয়, শুরু করার বিন্দু মাত্র। সঠিক সেটিংস হলো যা আপনার ট্রাফিক, হার্ডওয়্যার, ও পিক লগইন বারের সঙ্গে খাপ খায়।\n\n## পাসওয়ার্ড স্টোরেজ দুর্বল করে এমন সাধারণ ভুলসমূহ\n\nঅধিকাংশ ব্যর্থতা সেটআপের ফাঁক থেকে আসে, না আলগোরিদম ক্ষতিগ্রস্ত হওয়ায়।\n\nসাল্ট সম্পর্কিত ভুল বড় একটি সমস্যা। প্রতিটি পাসওয়ার্ডই নিজের আলাদা সাল্ট থাকা উচিত এবং সেটা হ্যাশের সঙ্গে সংরক্ষণ করতে হবে। সাল্ট পুনরায় ব্যবহার বা একটি গ্লোবাল সাল্ট ব্যবহার করলে আক্রমণকারীরা আপনার কাজ পুনরায় ব্যবহার করে একাউন্ট তুলনা করা সহজ করে তোলে।\n\nকস্ট উপেক্ষা আরেকটি ব্যাপক সমস্যা। দলগুলো প্রায়ই কম কস্ট নিয়ে চালু করে কারণ লগইন দ্রুত লাগে, তারপর কখনও তা পুনর্বিবেচনা করে না। হার্ডওয়্যার উন্নত হয়, আক্রমণকারীরা বড় হয়ে ওঠে, এবং আপনার একসময় ঠিক হওয়া সেটিংস সস্তা হয়ে যায়।\n\nArgon2 অতিরিক্ত টিউন করাও সাধারণ—মেমরি খুব বেশি বাড়ালে কাগজে ভালো দেখালেও বাস্তবে লগইন ধীর হওয়া, রিকুয়েস্ট ব্যাকলগ বা OOM ঘটতে পারে।\n\nপাসওয়ার্ড দৈর্ঘ্য হ্যান্ডলিং গুরুত্বপূর্ণ, বিশেষ করে bcrypt-এর 72-বাইট আচরণে। দীর্ঘ পাসওয়ার্ড অনুমোদন করে কিন্তু নীরবে ট্রাঙ্কেট করলে ব্যবহারকারীর জন্য বিভ্রান্তি ও নিরাপত্তা হ্রাস ঘটে।\n\nকয়েকটি ব্যবহারিক অভ্যাস বেশিরভাগ সমস্যা প্রতিরোধ করে:\n\n- প্রতিটি পাসওয়ার্ডের জন্য অনন্য সাল্ট ব্যবহার করুন (লাইব্রেরি দিয়ে জেনারেট করান)\n- লোড টেস্ট করুন এবং একটি নির্ধারিত সময় পরে সেটিংস পুনর্বিবেচনা করুন\n- Argon2 মেমরি টিউন করুন পিক ট্রাফিক অনুসারে, শুধু সিঙ্গেল-লগইন বেঞ্চমার্ক নয়\n- পাসওয়ার্ড দৈর্ঘ্যের সীমা স্পষ্ট এবং ধারাবাহিক করুন\n- লগইন এন্ডপয়েন্টের চারপাশে কনকারেন্সি লিমিট এবং মনিটরিং রাখুন\n\n## নিরাপদ সেটআপের দ্রুত চেকলিস্ট\n\nশিপ করার সময় ও ইনফ্রা পরিবর্তিত করার সময় এই সংক্ষিপ্ত তালিকাটি পাশে রাখুন:\n\n- প্রতিটি পাসওয়ার্ডে অনন্য সাল্ট, র্যান্ডমভাবে জেনারেট করে হ্যাশের সঙ্গে সংরক্ষণ করুন\n- পিক ট্রাফিক টিকে টিকে টেকসই এমন হ্যাশিং কস্ট, প্রোডাকশন-সদৃশ হার্ডওয়্যারে লোড টেস্ট সহ যাচাই করা\n- প্যারামিটারগুলো হ্যাশের সঙ্গে সংরক্ষিত রাখুন যাতে পুরনো একাউন্ট যাচাই করা যায় ও পরে কস্ট বাড়ানো যায়\n- অনলাইন আক্রমণ নিয়ন্ত্রণ, রেট-লিমিট এবং বারবার ব্যর্থ হলে সংক্ষিপ্ত লকআউট সহ\n- আপগ্রেড পথ, সাধারণত rehash-on-login\n\nএকটি সহজ সেনসিটি চেক: স্টেজিং টেস্ট চালান যেখানে সফল ও ব্যর্থ উভয় ধরনের লগইনের বর্ধিত পার্শ্বপ্রবাহ আছে এবং এন্ড-টু-এন্ড ল্যাটেন্সি, CPU ও RAM ব্যবহার পর্যবেক্ষণ করুন। যদি লগইন পাথ সংগ্রাম করে, কস্ট টিউন করুন এবং রেট-লিমিট কড়া করুন। মৌলিক জিনিসগুলো কেটে ফেলে "fix" করার চেষ্টা করবেন না, যেমন সাল্ট।\n\n## বাস্তব উদাহরণ: একটি ছোট ওয়েব অ্যাপে টিউনিং\n\nএকটি ছোট SaaS অ্যাপ কল্পনা করুন যার কয়েক হাজার ব্যবহারকারী আছে। দিনের বেশিরভাগ সময় ট্রাফিক স্থিতিশীল, কিন্তু নিউজলেটার পাঠানোর পরে বা কাজের দিনের শুরুতে দ্রুত লগইন বর্ধিত হয়। এখানেই পছন্দটি ক্যাপাসিটি প্ল্যানিংয়ে রূপ নেয়।\n\nআপনি Argon2id বেছে নিন অফলাইন ক্র্যাকিংয়ের খরচ বাড়ানোর জন্য। আপনার বাস্তব সার্ভারের উপর একটি টার্গেট যাচাইকরণ সময় (উদাহরণ: 100–250 ms) বেছে নিন, তারপর প্যারামিটারগুলো টিউন করুন যাতে তা মিট করে এবং RAM নজরে রাখুন, কারণ মেমরি সেটিংস একসাথে কতগুলো লগইন হ্যান্ডেল করা যায় তা সীমাবদ্ধ করতে পারে।\n\nএকটি ব্যবহারিক টিউনিং লুপ:\n\n- নম্র ইটারেশন ও প্যারালালিজম দিয়ে শুরু করুন\n- কনকারেন্সি অনিশ্চিত লাগতে শুরু করলে মেমরি বাড়ান যতক্ষণ না তা অস্বস্তিকর হয়\n- টাইম কস্ট সূক্ষ্ম করে ঠিক করতে ইটারেশন সামঞ্জস্য করুন\n- শুধুমাত্র সিঙ্গেল রিকোয়েস্ট নয়, সিমুলেটেড বার্ডস্টের সাথে পুনরায় পরীক্ষা করুন\n\nআপনি যদি ইতোমধ্যে দুর্বল সেটিংসের পুরনো হ্যাশ রাখেন, সেগুলো যাচাই চালিয়ে যান কিন্তু ধীরে ধীরে আপগ্রেড করুন। সফল লগইনের পরে রিহ্যাশ করুন এবং নতুন মান সংরক্ষণ করুন; সময়ের সাথে সক্রিয় ব্যবহারকারীরা বাধ্য ছাড়াই শক্তিশালী হ্যাশে চলে যাবে।\n\nরিলিজের পর, লগইনকে যে কোনও গুরুত্বপূর্ণ এনডপয়েন্টের মতো মনিটর করুন: টেইল ল্যাটেন্সি (p95/p99), বর্ধিত সময়ের CPU ও RAM, ব্যর্থ-লগইনের স্পাইক এবং পুরনো হ্যাশগুলো কিভাবে দ্রুত প্রতিস্থাপিত হচ্ছে।\n\n## পরবর্তী ধাপ: নিরাপদভাবে শিপ করুন এবং উন্নতি বজায় রাখুন\n\nআপনার পলিসি লিখে রাখুন এবং এটিকে জীবন্ত নীতির মতো দেখুন। উদাহরণস্বরূপ: “Argon2id সঙ্গে X মেমরি, Y ইটারেশন, Z প্যারালালিজম” বা “bcrypt কস্ট ফ্যাক্টর N,” এবং নোট রাখুন কোন তারিখে এটি বেছে নিয়েছেন এবং কবে পুনঃপর্যালোচনা করবেন (প্রতি 6–12 মাস ভালো শুরু)।\n\nআপগ্রেড পথ রাখুন যাতে পুরনো হ্যাশে আটকে না পড়েন। rehash-on-login সহজ এবং বেশিরভাগ সিস্টেমে ভালোভাবে কাজ করে।\n\nএকটি শক্তিশালী হ্যাশ সাহায্য করে, কিন্তু তা অনলাইন অ্যাবিউজ কন্ট্রোল প্রতিস্থাপন করে না। রেট-লিমিট, লকআউট, এবং সাবধানাত্মক পাসওয়ার্ড রিসেট ফ্লো বাস্তব বিশ্বে একইভাবে গুরুত্বপূর্ণ।\n\nআপনি যদি AppMaster-এর মতো নো-কোড প্ল্যাটফর্ম দিয়ে ব্যাকএন্ড তৈরি করেন, তখন যাচাই করে দেখুন যে আপনার অথেনটিকেশন মডিউল ডিফল্টভাবে শক্তিশালী পাসওয়ার্ড হ্যাশিং ব্যবহার করে এবং আপনার হ্যাশিং কস্ট ঠিক সেই ধরনের ইনফ্রাসট্রাকচারে টিউন করা আছে যেখানে আপনি ডিপ্লয় করবেন। সামান্য আগাম টেস্টিংই প্রায়শই পার্থক্য সৃষ্টি করে "নিরাপদ ও মসৃণ" এবং "নিরাপদ কিন্তু লোডে ব্যবহারঅযোগ্য" এর মধ্যে।