IPsec প্রি-শেয়ার্ড কী: আপনি যে স্ট্রিং টাইপ করেছেন তার পেছনের বাইট

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

গেটওয়ে স্ট্রিংটি নিয়ে কী করে

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

তাই কাজের প্রশ্ন কখনোই «এগুলো কি একই রকম দেখায়» নয়, বরং «প্রতিটি বাস্তবায়ন কোন নির্দিষ্ট বাইট ক্রমটি হ্যাশ করে»।

অতিরিক্ত বাইট কোথা থেকে আসে

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

গ্লিফ নয়, বাইট দেখায় এমন টুল দিয়ে তুলনা করুন। printf '%s' "$PSK" | xxd | tail -2 মানটির শেষাংশ হেক্সে ছাপে, যেখানে একটি অনর্থক 0a বা 20 স্পষ্ট দেখা যায়। এটি দুই প্রান্তেই করুন এবং দুটি ডাম্প পাশাপাশি মিলিয়ে দেখুন। এটি উৎপন্ন পরীক্ষার উপাদানে করুন, কোনো প্রোডাকশন সিক্রেটে নয় যা পরে শেল ইতিহাসে পড়ে থাকবে।

এনকোড করা মানে এনক্রিপ্ট করা নয়

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

Apple-এর IPSec অভিধান টাইপের গুরুত্বের একটি ভালো উদাহরণ: এটি SharedSecret-কে L2TP ও Cisco IPsec পেলোডে শেয়ার্ড-সিক্রেট প্রমাণীকরণ পদ্ধতির জন্য ডেটা হিসেবে নথিভুক্ত করে। এটি নির্দিষ্ট পেলোডের নির্দিষ্ট বৈশিষ্ট্য, কোনো সাধারণ টেক্সট ফিল্ড নয় যা আপনি অন্য কোনো প্রোটোকলের জন্য পুনরায় ব্যবহার করতে পারেন যা ঘুরেফিরে সিক্রেট চায়।

দাবিকৃত সীমা একটি নির্দিষ্ট সমন্বয়ের

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

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

শক্তি নয়, উপস্থাপনা ঠিক করুন

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

প্রয়োজনীয় ক্রেডেনশিয়াল সংস্থার মান পূরণ করতে না পারলে, নকশাটি এমন একটিতে বদলান যা পারবে। যথেষ্ট এনট্রপিসহ একটি শেয়ার্ড সিক্রেট, একবার উৎপন্ন, একটি ব্যবস্থাপিত ফিল্ডে সংরক্ষিত এবং কখনো প্রকাশ না করা, সম্পূর্ণ ভালো উত্তর; তার একটি ছোট সংস্করণ নয়।