প্রচলিত অনেক পাসওয়ার্ড নিয়ম আধুনিক আক্রমণ ঠেকায় না, বরং ব্যবহারকারীর জন্য ঝামেলা তৈরি করে। NIST, NCSC ও Microsoft-এর বর্তমান নির্দেশনা কোন সুরক্ষাব্যবস্থা সমর্থন করে, তা জানুন।
পাসওয়ার্ড নীতিকে প্রায়ই কিছু শর্তের তালিকা হিসেবে দেখা হয়: একটি বড় হাতের অক্ষর, একটি সংখ্যা, একটি প্রতীক রাখতে হবে এবং প্রতি 60 বা 90 দিন পর পাসওয়ার্ড বদলাতে হবে। এসব নিয়ম চোখে পড়ে এবং সহজেই নিরীক্ষা করা যায়। কিন্তু কোনো নিয়ম দৃশ্যমান হলেই তা কার্যকর হয় না। আক্রমণকারীরা মানুষের অনুমানযোগ্য পছন্দ, পুনর্ব্যবহৃত লগইন তথ্য, দুর্বল অ্যাকাউন্ট পুনরুদ্ধার প্রক্রিয়া এবং যথাযথ সুরক্ষা না থাকা পাসওয়ার্ড ডেটাবেসকে কাজে লাগায়।
একটি কার্যকর নীতির কাজ হলো এই নির্দিষ্ট ঝুঁকিগুলো কমানো। একই সঙ্গে নীতিটি মেনে চলা যথেষ্ট সহজ হতে হবে, যাতে মানুষ তা এড়িয়ে যাওয়ার পথ না খোঁজে।
ন্যূনতম দৈর্ঘ্য
পাসওয়ার্ডের দৈর্ঘ্য বাড়লে সম্ভাব্য অক্ষরবিন্যাসের সংখ্যা বাড়ে, তবে কেবল তখনই, যখন সেটি কোনো প্রচলিত বাক্যাংশ বা অনুমানযোগ্য বিন্যাস নয়। NIST-এর বর্তমান নির্দেশনা অনুযায়ী, পাসওয়ার্ডই পরিচয় যাচাইয়ের একমাত্র উপাদান হলে এতে অন্তত 15টি অক্ষর থাকতে হবে। একাধিক উপাদানের মাধ্যমে পরিচয় যাচাইয়ের অংশ হিসেবে পাসওয়ার্ড ব্যবহার করা হলে ন্যূনতম দৈর্ঘ্য আটটি অক্ষর রাখার অনুমতি রয়েছে। পাসওয়ার্ড ম্যানেজার ও পাসফ্রেজ যেন ঠিকমতো ব্যবহার করা যায়, সে জন্য সিস্টেমকে অন্তত 64টি অক্ষর গ্রহণ করতে হবে।
দৈর্ঘ্য একটি প্রাথমিক শর্ত, শক্তিশালী পাসওয়ার্ডের প্রমাণ নয়। বেহাত হওয়া পাসওয়ার্ডের একটি নিষিদ্ধ তালিকা প্রয়োজন, কারণ দীর্ঘ পাসওয়ার্ডও অনিরাপদ থাকে যদি আক্রমণকারীরা সেটি আগে থেকেই জানে।
নিয়মিত বিরতিতে পাসওয়ার্ডের মেয়াদ শেষ হওয়া
নির্দিষ্ট সময় পরপর পাসওয়ার্ড বদলাতে বাধ্য করলে ব্যবহারকারীরা সাধারণত ছোট, অনুমানযোগ্য পরিবর্তন করেন। এতে প্রত্যেক ব্যবহারকারীর ওপর বাড়তি চাপও পড়ে, অথচ প্রত্যেকের পাসওয়ার্ড উন্মুক্ত হয়েছে—এমন প্রমাণ থাকে না। NIST, যুক্তরাজ্যের NCSC এবং Microsoft নিয়মিত বিরতিতে পাসওয়ার্ডের মেয়াদ শেষ করার বিপক্ষে পরামর্শ দেয়। এর বদলে পাসওয়ার্ড বদলানো উচিত যখন সেটি বেহাত হওয়ার প্রমাণ বা যুক্তিসংগত সন্দেহ থাকে, ঝুঁকিপূর্ণ সংরক্ষণপদ্ধতি শনাক্ত হয়, অথবা অ্যাকাউন্ট পুনরুদ্ধারের কোনো ঘটনার কারণে তা প্রয়োজন হয়।
প্রতিষ্ঠানগুলোর তখনও দ্রুত সমস্যা শনাক্ত করার এবং পাসওয়ার্ড রিসেট করার সক্ষমতা থাকতে হবে। নির্দিষ্ট সময় পরপর পাসওয়ার্ড পরিবর্তনের নিয়ম তুলে দেওয়ার অর্থ এই নয় যে বেহাত হয়েছে বলে জানা পাসওয়ার্ড রেখে দিতে হবে।
পাসওয়ার্ড তৈরির নিয়ম
বড় হাতের অক্ষর, ছোট হাতের অক্ষর, সংখ্যা ও প্রতীক বাধ্যতামূলক করার নিয়ম এমন বিন্যাসে উৎসাহ দেয়, যেখানে প্রথম অক্ষরটি বড় হাতের হয় এবং শেষে একটি অঙ্ক বা প্রতীক থাকে। আক্রমণের সরঞ্জামগুলো ইতিমধ্যেই এ ধরনের বদল হিসাবের মধ্যে রাখে। সেবাগুলোতে স্পেস ও বিস্তৃত ধরনের অক্ষর ব্যবহারের সুযোগ থাকা উচিত। ইচ্ছেমতো অক্ষরবিন্যাসের শর্ত না দিয়ে প্রস্তাবিত পাসওয়ার্ডের পুরোটা প্রচলিত ও বেহাত হওয়া পাসওয়ার্ডের সঙ্গে মিলিয়ে যাচাই করা উচিত।
SQL ইনজেকশন বা ক্রস-সাইট স্ক্রিপ্টিংয়ে ব্যবহার হতে পারে বলে যতিচিহ্ন নিষিদ্ধ করা একটি সতর্কসংকেত। অ্যাপ্লিকেশনের কোডে অবশ্যই প্যারামিটারযুক্ত ডেটাবেস কুয়েরি ব্যবহার করতে হবে এবং আউটপুট নিরাপদভাবে সামলাতে হবে। ব্যবহারকারীর পাসওয়ার্ডে সীমাবদ্ধতা আরোপ করা ইনজেকশনজনিত দুর্বলতা ঠিক করার বিকল্প নয়।
পাসওয়ার্ড পুনর্ব্যবহার ও ফাঁস হওয়া লগইন তথ্য
একই পাসওয়ার্ড পুনর্ব্যবহার সবচেয়ে গুরুতর ঝুঁকিগুলোর একটি, কারণ এক সেবাদাতার কাছে তথ্য ফাঁস হলে তা দিয়ে অন্য সেবাদাতার অ্যাকাউন্টে প্রবেশ করা সম্ভব হতে পারে। নীতিতে সেবাটির জন্য আলাদা পাসওয়ার্ড ব্যবহারের শর্ত থাকা উচিত, পাসওয়ার্ড ম্যানেজার ব্যবহারের সুযোগ থাকা উচিত এবং গোপনীয়তা সুরক্ষিত রাখে এমন পদ্ধতিতে প্রস্তাবিত পাসওয়ার্ডকে বেহাত হয়েছে বলে জানা পাসওয়ার্ডের সঙ্গে মিলিয়ে যাচাই করা উচিত। প্রতিষ্ঠানগুলোর ক্রেডেনশিয়াল স্টাফিংয়ের ধরন ও অস্বাভাবিক লগইন আচরণও পর্যবেক্ষণ করা উচিত।
আগে ব্যবহৃত পাসওয়ার্ডের ইতিহাস রাখলে একই সেবায় হুবহু একই পাসওয়ার্ড আবার ব্যবহার করা ঠেকানো যায়। তবে ইতিহাসের তালিকা খুব দীর্ঘ হলে ব্যবহারকারীরা নামমাত্র পরিবর্তন করতে উৎসাহিত হতে পারেন। এই ইতিহাস দিয়ে অন্য সেবাদাতার কাছে একই পাসওয়ার্ড ব্যবহার শনাক্ত করা যায় না, তাই একে প্রধান সুরক্ষাব্যবস্থা হিসেবে ধরা উচিত নয়।
পাসওয়ার্ডের নিরাপদ সংরক্ষণ
পাসওয়ার্ড কেবল সুরক্ষিত TLS সংযোগের মাধ্যমে সেবায় পাঠানো উচিত এবং কখনোই লগে লেখা উচিত নয়। সার্ভারে প্রতিটি পাসওয়ার্ডকে একটি স্বতন্ত্র, দৈবভাবে তৈরি সল্ট এবং এই কাজের জন্য তৈরি ধীরগতির পাসওয়ার্ড হ্যাশিং ফাংশন দিয়ে প্রক্রিয়া করতে হবে। OWASP সাধারণত Argon2id ব্যবহারের পরামর্শ দেয়; উল্লেখিত সীমাবদ্ধতার মধ্যে scrypt, bcrypt বা PBKDF2 উপযুক্ত হতে পারে। হার্ডওয়্যার উন্নত হওয়ার সঙ্গে সঙ্গে হ্যাশিংয়ের গণনা-ব্যয়ের মাত্রা নিয়মিত পর্যালোচনা করা প্রয়োজন।
পাসওয়ার্ড ডেটাবেসের বাইরে রাখা একটি পেপার সুরক্ষার আরেকটি স্তর যোগ করতে পারে, তবে এর সঙ্গে ক্রিপ্টোগ্রাফিক কী ব্যবস্থাপনা ও পরিবর্তনের দায়িত্বও আসে। এটি সল্ট বা শক্তিশালী পাসওয়ার্ড হ্যাশিং ফাংশনের বিকল্প নয়। MD5 ও সাধারণ SHA-1/SHA-2-এর মতো দ্রুতগতির সাধারণ কাজের হ্যাশগুলো এককভাবে পাসওয়ার্ড সংরক্ষণের জন্য উপযুক্ত নয়।
একটি কার্যকর নীতিতে যা থাকে
ঝুঁকির সঙ্গে সামঞ্জস্যপূর্ণ ন্যূনতম দৈর্ঘ্য এবং দীর্ঘ পাসওয়ার্ড ব্যবহারের সুযোগ।
প্রচলিত, অনুমান করা যায় এমন এবং বেহাত হয়েছে বলে জানা পাসওয়ার্ড নিষিদ্ধ করা।
পাসওয়ার্ড ম্যানেজার, পেস্ট ও স্বয়ংক্রিয়ভাবে পূরণের সুবিধা।
স্বতন্ত্র সল্ট দিয়ে ধীরগতির পাসওয়ার্ড হ্যাশিং এবং এর গণনা-ব্যয়ের মাত্রা পর্যালোচনা।
বিভিন্ন স্তরে প্রচেষ্টার হার সীমিত করা এবং পাসওয়ার্ড অনুমান, পাসওয়ার্ড স্প্রে ও ক্রেডেনশিয়াল স্টাফিং শনাক্ত করা।
ফিশিং-প্রতিরোধী MFA বা পাসকি, বিশেষ করে বিশেষ অধিকারসম্পন্ন ও সংবেদনশীল অ্যাকাউন্টের জন্য।
নিরাপদ অ্যাকাউন্ট পুনরুদ্ধার, পরিচয় যাচাইয়ের মাধ্যম প্রতিস্থাপন, সেশন বাতিল এবং পাসওয়ার্ড বেহাত হলে রিসেট।
