ডিভাইসের ঘড়ি সরে গেলে TOTP কোড কেন ব্যর্থ হয়

একবার ব্যবহারের কোড আপনার ফোনে সম্পূর্ণ সঠিক থাকতে পারে, আবার একই সেকেন্ডে সার্ভার তা প্রত্যাখ্যান করতে পারে। দুই পক্ষই একটি ভাগ করা গোপনীয়তা ও বর্তমান সময়-ধাপ থেকে একই ফাংশন গণনা করে, তাই সময় নিয়ে মতভেদ কোড নিয়ে মতভেদ তৈরি করে। এতে ঘড়ির সরণ নিরাপত্তার দৃষ্টিতে গুরুত্বপূর্ণ ত্রুটি হয়ে ওঠে, শুধু বিরক্তি নয়।

এখানে দুইটি ঘড়ি গুরুত্বপূর্ণ, আর দৃশ্যমান ঘড়িটি ঠিক করা মানুষ প্রথমে যা করে। যে ঘড়িটির সাধারণত মনোযোগ দরকার সেটি অন্যটি।

কোড সময়ের ফাংশন, পাসওয়ার্ড নয়

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

এজন্যই একটি কোড কাজ করে আর পরেরটি কিছুক্ষণ পরেই ব্যর্থ হয়। এটি আরও ব্যাখ্যা করে কেন চ্যাট বার্তা থেকে কোড কপি করা এত অবিশ্বস্ত অভ্যাস।

দুইটি ঘড়িকে মিলতে হবে, একটিকে নয়

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

যাচাইকারীর ঘড়িও ডিভাইসের ঘড়ির মতোই সমান পরীক্ষার দাবিদার। যে সার্ভারের সময়ের উৎস নষ্ট, সে একসঙ্গে সব ব্যবহারকারীর সঠিক কোড প্রত্যাখ্যান করে, আর প্রতিবেদনে সরণের বদলে আকস্মিক বিভ্রাটের কথা থাকবে। এই ধরনটি চেনা দরকার, কারণ এর সমাধান সার্ভারে, একশো ফোনে নয়।

উইন্ডো প্রশস্ত করার মূল্য

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

ঘড়ি সংশোধন করা হলো মেরামত, আর উইন্ডো প্রশস্ত করা হলো প্রশমক। প্রথমটি কারণ দূর করে, দ্বিতীয়টি তা লুকায়।

আবার চেষ্টা করার আগে দুই ঘড়িই যাচাই করুন

ডিভাইসে ও সার্ভারে সময় পড়ুন এবং প্রদর্শিত স্থানীয় সময় নয়, অফসেট তুলনা করুন। নিচের কমান্ডগুলো লিনাক্স হোস্ট বা সার্ভারে সিঙ্ক্রোনাইজেশন অবস্থা ও কাঁচা UTC মুহূর্ত দেখায়। যেকোনো প্রমাণীকরণ সেটিং বদলানোর আগে দুই প্রান্তেই এগুলো চালান।

timedatectl
date -u +'%Y-%m-%dT%H:%M:%SZ'
chronyc tracking
timedatectl timesync-status

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

প্রত্যাখ্যানের সময়, অফসেট ও ত্রুটির লেখা নথিভুক্ত করুন, আর ভাগ করা গোপনীয়তা এর বাইরে রাখুন। সহায়তা প্রথম তিনটি নিয়ে কাজ করতে পারে এবং চতুর্থটি কখনো দেখা উচিত নয়।