নিরাপদে পাসওয়ার্ড সংরক্ষণ: hashing, salt, bcrypt ও Argon2
আপনার database ফাঁস হলে পাসওয়ার্ড কীভাবে রেখেছিলেন তাই ঠিক করে ক্ষতি কত হবে। নিরাপদ উপায় ও সাধারণ ভুল শিখুন।
পাসওয়ার্ড আপনার অ্যাপের সবচেয়ে সংবেদনশীল data-র মধ্যে। Bug, backup, ভুল configuration ও ভেতরের ভুলে database ফাঁস হয়। পাসওয়ার্ড কীভাবে সংরক্ষণ করেন তাই ঠিক করে ফাঁস বিপর্যয় হবে নাকি সীমিত ঘটনা। এই লেখা developer-দের জন্য প্রতিরক্ষামূলক নির্দেশিকা।
কখনো সাধারণ লেখা নয়, এবং এনক্রিপ্টও নয়
- সাধারণ লেখায় database পড়তে পারা যে-কেউ প্রতিটি পাসওয়ার্ড দেখে।
- ব্যবহারকারীর পাসওয়ার্ডের জন্য উল্টানো যায় এমন এনক্রিপশন-ও ভুল। Key চুরি হলে বা অ্যাপ decrypt করতে পারলে আক্রমণকারীও পারে। ব্যবহারকারীর পাসওয়ার্ড আপনার জানার দরকার নেই, শুধু যাচাই করতে হবে সে যা লিখেছে তা মেলে কি না।
সঠিক টুল হলো একমুখী password hash: এমন function যা পাসওয়ার্ডকে নির্দিষ্ট মানে বদলায় যেখান থেকে পাসওয়ার্ড ফেরত পাওয়া যায় না। Login-এ লেখা পাসওয়ার্ড hash করে তুলনা করেন।
সাধারণ দ্রুত hash কেন যথেষ্ট নয়
MD5, SHA-1 ও সাধারণ SHA-256-এর মতো সাধারণ hash দ্রুত হওয়ার জন্য বানানো। পাসওয়ার্ডের জন্য এটি দুর্বলতা, কারণ চুরি যাওয়া hash database-সহ আক্রমণকারী আধুনিক hardware-এ প্রতি সেকেন্ডে শত কোটি অনুমান চেষ্টা করতে পারে, আর মানুষ অনুমানযোগ্য পাসওয়ার্ড বাছে। দ্রুত hash আক্রমণকারীকে আগে-হিসাব করা table (rainbow table) ব্যবহার করতে এবং একই পাসওয়ার্ড ভাগ করা ব্যবহারকারী শনাক্ত করতে দেয়।
Salt
Salt হলো প্রতিটি পাসওয়ার্ডের জন্য তৈরি এলোমেলো মান, যা hash-এর পাশে সংরক্ষিত। Hash হিসাব হয় পাসওয়ার্ড ও salt মিলিয়ে।
- একই পাসওয়ার্ডের দুজন ব্যবহারকারী ভিন্ন hash পায়।
- আগে-হিসাব করা table অকেজো হয়।
- আক্রমণকারীকে প্রতিটি hash আলাদাভাবে আক্রমণ করতে হয়।
Salt গোপন নয়। শুধু অনন্য ও এলোমেলো হতে হবে। আধুনিক password hashing library আউটপুট string-এর ভেতরেই salt বানিয়ে সংরক্ষণ করে।
ধীর, উদ্দেশ্য-নির্মিত password hash ব্যবহার করুন
Password hashing algorithm ইচ্ছে করে ধীর ও memory-ভারী, সমন্বয়যোগ্য খরচসহ, ফলে আক্রমণকারীর অনুমান ব্যয়বহুল হয় অথচ আপনার একটি login দ্রুত থাকে।
- Argon2id: আধুনিক, ব্যাপক সুপারিশ করা পছন্দ, কনফিগারযোগ্য memory ব্যবহার করায় GPU আক্রমণ প্রতিরোধী। Password Hashing Competition-এর বিজয়ী।
- scrypt: এটিও memory-hard, শক্ত বিকল্প।
- bcrypt: পুরোনো কিন্তু পরীক্ষিত ও ব্যাপক উপলব্ধ। Work factor (cost) সমন্বয়যোগ্য। লক্ষ্য করুন সাধারণ বাস্তবায়নে ৭২-বাইট ইনপুট সীমা আছে, তাই খুব লম্বা পাসওয়ার্ড ছেঁটে যায়।
- PBKDF2: মান বা compliance চাইলে গ্রহণযোগ্য, উচ্চ iteration সংখ্যা সহ। এটি memory-hard নয়।
আপনার platform যে algorithm ভালোভাবে সমর্থন করে তা বাছুন, এবং parameter-এর জন্য OWASP Password Storage Cheat Sheet-এর মতো বিশ্বস্ত উৎসের বর্তমান নির্দেশনা অনুসরণ করুন, কারণ hardware উন্নত হলে সুপারিশ বদলায়। খরচ এমনভাবে টিউন করুন যাতে আপনার server-এ hashing লক্ষণীয় কিন্তু গ্রহণযোগ্য সময় নেয় (যেমন প্রতি login-এ সেকেন্ডের ভগ্নাংশ), এবং load-এ পরীক্ষা করুন।
উদাহরণ (Node.js ধাঁচ, শুধু ধারণা)
// রক্ষণাবেক্ষিত library ব্যবহার করুন যা salt ও parameter সামলায়
const hash = await argon2.hash(password); // এই পুরো string সংরক্ষণ করুন
const ok = await argon2.verify(hash, attempt); // login-এ true বা false
ভালোভাবে রক্ষণাবেক্ষিত library ব্যবহার করুন। নিজের পদ্ধতি বানাবেন না, এবং hash চালাকি করে জোড়া দেবেন না।
Pepper (ঐচ্ছিক বাড়তি স্তর)
Pepper হলো মেশানো গোপন মান যা database-এ নয়, অ্যাপ configuration বা hardware security module-এ সংরক্ষিত। শুধু database ফাঁস হলে pepper অজানা থাকে। এটি সুরক্ষা বাড়ায় কিন্তু জটিলতাও (বদলানো কঠিন), তাই এটিকে বাড়তি ধরুন, ভালো password hash-এর বিকল্প নয়।
সময়ের সাথে hash হালনাগাদ
প্রতিটি hash-এর সাথে algorithm ও parameter সংরক্ষণ করুন (বেশিরভাগ library করে)। ব্যবহারকারী সফল login করলে এবং তার hash পুরোনো সেটিংসে হলে নতুন সেটিংসে আবার hash করে সংরক্ষণ করুন। এতে reset না চেয়ে ধীরে ধীরে ব্যবহারকারীদের স্থানান্তর হয়।
পাসওয়ার্ড নীতি
- লম্বা পাসওয়ার্ড ও passphrase এবং space ও Unicode-সহ সব অক্ষর অনুমতি দিন। বিশাল ইনপুট থেকে denial-of-service ঠেকাতে যুক্তিসঙ্গত সর্বোচ্চ (যেমন ৬৪ থেকে ১২৮ অক্ষর) রাখুন।
- যুক্তিসঙ্গত ন্যূনতম দৈর্ঘ্য চান (বর্তমান নির্দেশনা অদ্ভুত জটিলতার নিয়মের চেয়ে দৈর্ঘ্যে জোর দেয়)।
- নতুন পাসওয়ার্ড জানা ফাঁস হওয়া বা সাধারণ পাসওয়ার্ডের তালিকার বিরুদ্ধে যাচাই করুন।
- কারণ ছাড়া ঘন ঘন পর্যায়ক্রমিক বদল বাধ্য করবেন না। আপসের প্রমাণ থাকলে বদল চান।
- Password manager সমর্থন করুন (paste অনুমতি, সঠিক input type)।
- Multi-factor authentication দিন (authenticator অ্যাপ, security key বা passkey)। পাসওয়ার্ড চুরি গেলেও এটি অ্যাকাউন্ট রক্ষা করে।
- পাসওয়ার্ডহীন বিকল্প হিসেবে passkey (WebAuthn) ভাবুন।
Login ও reset প্রবাহ
- সাধারণ error বার্তা দিন ("email বা পাসওয়ার্ড ভুল") যাতে আক্রমণকারী কোন email আছে জানতে না পারে।
- Login চেষ্টায় rate limiting ও lockout বা বিলম্ব প্রয়োগ করুন এবং credential stuffing নজরে রাখুন।
- পাসওয়ার্ড reset: যাচাই করা email-এ HTTPS-এ একবার-ব্যবহারযোগ্য, এলোমেলো, স্বল্পস্থায়ী token পাঠান (শুধু তার hash সংরক্ষণ করুন)। ব্যবহারের পরে অকার্যকর করুন এবং বদল সম্পর্কে ব্যবহারকারীকে জানান। পাসওয়ার্ড কখনো email করবেন না, এবং বিদ্যমান পাসওয়ার্ড একেবারেই পাঠাবেন না (সঠিকভাবে hash করলে পারেনও না)।
- পাসওয়ার্ড log, URL, analytics বা error রিপোর্টে রাখবেন না।
- সর্বত্র HTTPS ব্যবহার করুন।
Breach সন্দেহ হলে
১. ঠেকান ও কারণ তদন্ত করুন। ২. প্রভাবিত অ্যাকাউন্টে পাসওয়ার্ড reset বাধ্য করুন এবং session ও token অকার্যকর করুন। ৩. ব্যবহারকারীদের জানান এবং আপনার প্রযোজ্য আইনি নিয়ম মানুন। যেখানে পাসওয়ার্ড পুনর্ব্যবহার করেছেন সেখানে বদলাতে বলুন। ৪. মূল কারণ ঠিক করুন এবং hashing সেটিং পর্যালোচনা করুন।
সাধারণ ভুল
- পাসওয়ার্ডের জন্য MD5, SHA-1 বা salt ছাড়া SHA-256।
- উল্টানো যায় এমন এনক্রিপশন, বা ফেরত পাওয়া যায় এমন রূপে সংরক্ষণ।
- সব ব্যবহারকারীর জন্য একটি global salt।
- পুরোনো tutorial থেকে কপি করা cost সেটিং।
- পাসওয়ার্ডসহ request log করা।
- "email পাওয়া যায়নি" ও "ভুল পাসওয়ার্ড" আলাদা দেখানো।
- নিজস্ব hashing পদ্ধতি বানানো।
দ্রুত checklist
- রক্ষণাবেক্ষিত library ও বর্তমান parameter সহ Argon2id (বা scrypt/bcrypt)।
- library-র সামলানো অনন্য এলোমেলো salt।
- Parameter বদলালে login-এ আবার hash।
- ফাঁস হওয়া পাসওয়ার্ড যাচাই, লম্বা পাসওয়ার্ডের অনুমতি, MFA প্রস্তাব।
- নিরাপদ reset token, সাধারণ error, rate limiting।
- Log, URL বা backup-এ সাধারণ রূপে পাসওয়ার্ড নেই।
মূল কথা: কখনো পাসওয়ার্ড উল্টানো যায় এমনভাবে রাখবেন বা এনক্রিপ্ট করবেন না। রক্ষণাবেক্ষিত library-সহ Argon2id-এর মতো ধীর, salt-যুক্ত password hash ব্যবহার করুন, MFA ও breach যাচাই যোগ করুন এবং reset ও login প্রবাহ সুরক্ষিত করুন।
ওয়েব নিরাপত্তা সিরিজ, পর্ব ৩ (অ্যাকাউন্ট ও প্রতিরক্ষা): 1 নম্বর (মোট 5)।
