পাসওয়ার্ড ইমেইল প্রমাণ করে প্রত্যাবর্তনযোগ্যতা, কোনো স্টোরেজ স্কিমা নয়

একটি সেবা যা ব্যবহারকারীর বর্তমান পাসওয়ার্ড ইমেইলে পাঠায়, তা একটি বিষয় প্রমাণ করেছে: এটি গোপন তথ্যটি এমন আকারে পেতে পারে যা এটি পাঠাতে সক্ষম। এটি প্রমাণ করেনি কোন কলাম, অ্যালগরিদম বা লাইব্রেরি তা তৈরি করেছে। পার্থক্যটি গুরুত্বপূর্ণ, কারণ অনুসন্ধানটি সত্য এবং মানুষ এ থেকে যে সিদ্ধান্ত নেয় তা সাধারণত বেশি নির্দিষ্ট হয়ে যায়। পথের কোথাও প্রত্যাবর্তনযোগ্যতাই কার্যপ্রণালী; অনুমান করা স্টোরেজ ফরম্যাট নয়।

প্রমাণ এই স্তরেই রাখুন, আর পর্যালোচনার বাকি অংশ নির্ভুল থাকবে।

পুরোনো গোপন তথ্য ফেরত পাঠানো কী প্রমাণ করে

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

মধ্যবর্তী ক্ষেত্রেও খেয়াল রাখুন: অ্যাপ্লিকেশনের হাতে থাকা চাবিসহ সংরক্ষিত এনক্রিপ্টেড ব্লব বাস্তবে প্রত্যাবর্তনযোগ্য, যদিও এনক্রিপ্টেড শব্দটি প্রতিবেদনে স্বস্তিদায়ক শোনায়।

কেন এটি ডিজাইন-সংক্রান্ত অনুসন্ধান, স্টোরেজের মানচিত্র নয়

ইমেইলটি উদ্ধারযোগ্যতা প্রমাণ করে এবং সঠিক স্কিমাটি চিহ্নিত করে না। এটি প্লেইনটেক্সট, নির্ধারক এনক্রিপশন, কোনো সরবরাহকারীর অস্পষ্টকরণ রুটিন, বা কেবল উদ্ধারের জন্য ব্যবহৃত আলাদা ক্রেডেনশিয়াল স্টোর হতে পারে। একটি পণ্যের বিভিন্ন অংশ প্রায়ই ভিন্ন স্টোরেজ ব্যবহার করে। একটি ইমেইলের ভিত্তিতে অ্যালগরিদম নির্ধারণ করা সেই ধরনের দাবি যা পরবর্তী বৈঠকে ভেঙে পড়ে।

আপনি যা বলতে পারেন তা আরও সংকীর্ণ ও উপযোগী: এই পথটি গোপন তথ্য উদ্ধার করতে পারে, তাই পণ্যটি দাবি করতে পারে না যে কোনো উদ্ধারযোগ্য ক্রেডেনশিয়াল নেই। এর বাইরে সবকিছুর জন্য পরিচালকের প্রমাণ দরকার।

অনুমোদনকে কেন্দ্র করে রিসেট গড়ুন

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

ইমেইল চ্যানেল নিরাপত্তা মডেলের অংশ। অ্যাকাউন্টের নামের অধিকার কিছুই প্রমাণ করে না, আর যে রিসেট প্রবাহ প্রকাশ করে অ্যাকাউন্ট আছে কি না, তা আক্রমণকারীকে কাজ করার একটি তালিকা দিয়ে দেয়।

পাসওয়ার্ড যা রক্ষা করত তা বাতিল করুন

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

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

সুনির্দিষ্ট মূল্যায়ন সংক্ষিপ্ত: বার্তাটি কী প্রমাণ করে, কী অজানা থাকে, এবং উদ্ধার কি নিয়ন্ত্রিত প্রক্রিয়ার মাধ্যমে প্রবেশাধিকার প্রতিস্থাপন করে।