প্রথমে EAP পদ্ধতি: VPN কোন পাসওয়ার্ড হ্যাশ ব্যবহার করতে পারে
VPN গোপন তথ্যটি যাচাই করে, ওয়েব হ্যাশ নয়। পদ্ধতিটি পড়ুন, তারপর একই পাসওয়ার্ড চলতে থাকবে বলে প্রতিশ্রুতি দেওয়ার আগে দেখুন ভান্ডারে কী আছে।
অনেক দলের একটি ওয়েব লগইন কাজ করে, কিন্তু একই টেবিলের প্রতিটি পাসওয়ার্ড VPN প্রত্যাখ্যান করে। ওয়েব অ্যাপ্লিকেশন নিজে গণনা করা একটি হ্যাশের সঙ্গে তুলনা করে, অন্যদিকে টানেল ক্লায়েন্টকে এমনভাবে একটি গোপন তথ্যের অধিকার প্রমাণ করতে বলে যা সার্ভার যাচাই করতে পারে। এগুলো সংরক্ষিত উপাদানের প্রতি ভিন্ন দাবি। এই দুইয়ের মধ্যে ফাঁকেই বেশিরভাগ প্রকল্প আটকে যায়।
আগে পদ্ধতি, তারপর স্কিমা
যে কোনো স্কিমা দেখার আগে নির্বাচিত পদ্ধতি কোন প্রমাণ চায় তা লিখে রাখুন। চ্যালেঞ্জ-রেসপন্স পদ্ধতির এমন উপাদান দরকার যা থেকে সার্ভার প্রত্যাশিত উত্তর গণনা করতে পারে, যার অর্থ বাস্তবে পাসওয়ার্ড বা একটি সামঞ্জস্যপূর্ণ আহরিত রূপ। যে পদ্ধতি সুরক্ষিত টানেলের ভেতরে পাসওয়ার্ড বহন করে তার যাচাইকারীর কাছে পাসওয়ার্ডটিই দরকার। ক্লায়েন্ট কনফিগারেশনের জন্য নয়, যাচাইকারীর দাবির জন্য পদ্ধতির নথি পড়ুন, কারণ ক্লায়েন্টের দাবিগুলো সাধারণত সহজ অংশ।
আধুনিক ওয়েব ফ্রেমওয়ার্কের তৈরি লবণযুক্ত হ্যাশ এগুলোর কোনোটিই দেয় না। এটি একটি নির্দিষ্ট তুলনা যাচাই করে এবং যে গোপন তথ্য থেকে এসেছে তাতে ফিরিয়ে নেওয়া যায় না।
চ্যালেঞ্জ-রেসপন্স লবণযুক্ত হ্যাশ ব্যবহার করতে পারে না
MSCHAPv2 একটি চ্যালেঞ্জ-রেসপন্স বিনিময়, তাই সার্ভার কখনো পাসওয়ার্ড পায় না এবং সংরক্ষিত স্ট্রিং তুলনা করতে পারে না। তাকে নিজের কাছে থাকা উপাদান থেকেই প্রত্যাশিত উত্তর বের করতে হয়, তাই সামঞ্জস্যপূর্ণ সংরক্ষিত রূপগুলো এত সংকীর্ণ। প্রতি ব্যবহারকারীর জন্য আলাদা লবণযুক্ত bcrypt বা Argon2 মান এমন একমুখী যে তা বিনিময়টিকে সম্পূর্ণ বাদ দেয়। নিচের টেবিলটি পদ্ধতির নাম নয়, সংরক্ষণের রূপ থেকেই শুরু, কারণ সংরক্ষণের রূপই উত্তর নির্ধারণ করে।
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
strongSwan-এর SQL প্লাগইন ডকুমেন্টেশন নিজস্ব একটি স্কিমা নির্ধারণ করে কনফিগারেশন ও প্রমাণপত্রের জন্য, এবং প্রকল্পটি এখনো প্লাগইনটিকে পরীক্ষামূলক হিসেবে চিহ্নিত করে। এতে কিছুই কোনো অ্যাপ্লিকেশনের ব্যবহারকারী টেবিলের সঙ্গে খাপ খায় না বা কোন হ্যাশিং স্কিমা একটি সংরক্ষিত মান তৈরি করেছে তা অনুমান করে না। তাই বাস্তবসম্মত বিকল্প হলো গেটওয়ে ব্যবহার করতে পারে এমন ভান্ডারে স্থানান্তর, অথবা বিদ্যমান ভান্ডারের সামনে একটি প্রমাণীকরণ সেবা যা বিনিময়টি করতে পারে। এর বাইরে যা কিছু তা ভেতরে লুকানো অনুমান বহনকারী একটি সংযোগকারী।
RADIUS কাজটি সরায়, দাবিটি নয়
EAP একটি RADIUS সার্ভারে অর্পণ করলে যাচাই কোথায় হয় তা বদলায় এবং সাধারণত অডিট চিহ্ন উন্নত করে। এটি একমুখী হ্যাশ থেকে পাসওয়ার্ড উদ্ধার করে না, তাই প্রমাণীকরণ সেবার এখনো যে পদ্ধতি এটি সমাপ্ত করে তার সঙ্গে সামঞ্জস্যপূর্ণ উপাদান দরকার। দলগুলো RADIUS পথ তৈরি করে অন্য প্রান্তে একই দেয়ালে পৌঁছানোর পর এটি জানতে পারে।
যেখানে RADIUS সার্ভার সামঞ্জস্যপূর্ণ প্রমাণপত্র রাখা একটি ডিরেক্টরি পড়তে পারে, সেখানে নকশা কাজ করে এবং VPN গেটওয়ে সরল থাকে। যেখানে পারে না, সেখানে সৎ উত্তর আরেকটি সংযোগকারী নয়, নথিভুক্তি পরিবর্তন। প্রস্তুত ও প্রত্যাহার সেই ব্যক্তির, যার মালিকানায় পরিচয়টি আছে, তাই সমর্থিত সিঙ্ক্রোনাইজেশন প্রক্রিয়া ছাড়া নকল করা টেবিল একক সাইন-অন নয়, বরং দ্বিতীয় প্রমাণপত্র জীবনচক্র। কেউ কেবল এক জায়গায় পাসওয়ার্ড রিসেট করলেই এটি প্রথমবার সরে যায়, আর সেই সরণ নীরব থাকে যতক্ষণ না দুই সিস্টেমেই থাকা একটি অ্যাকাউন্ট প্রতিটিতে আলাদা আচরণ করে।
ডিরেক্টরি পড়ে এমন অ্যাকাউন্টকে সেই পড়ার মধ্যেই সীমিত রাখুন এবং গেটওয়ে নিজের কনফিগারেশনের জন্য যে অ্যাকাউন্ট ব্যবহার করে তার থেকে আলাদা রাখুন। ভাগ করা প্রশাসনিক অ্যাকাউন্ট কেবল-পড়ার নকশাকে অনেক বিস্তৃত ক্ষতির পরিসরে পরিণত করে।
অ্যাকাউন্টটি কোথায় থাকা উচিত
উপাদানের প্রশ্নটি মিটে গেলে দুটি স্থাপত্য বাকি থাকে। গেটওয়ে নিজের জন্য ছোট একটি প্রমাণপত্র ভান্ডার রাখতে পারে যা কেবল সে-ই পড়ে, অথবা কর্পোরেট ডিরেক্টরির সামনে থাকা একটি প্রমাণীকরণ সেবাকে দায়িত্ব দিতে পারে।
প্রথমটি বোঝা সহজ এবং ব্যবহারকারীর জন্য খারাপ, কারণ তাকে আরেকটি পাসওয়ার্ড রক্ষণাবেক্ষণ করতে হয়। দ্বিতীয়টি একটি পরিচয় ধরে রাখে এবং এমন একটি সেবার উপর নির্ভরতা যোগ করে যা এখন কেউ সংযুক্ত হওয়ার আগে চালু থাকতে হবে। কোনোটিই ভুল নয়, তবে সিদ্ধান্তটি গেটওয়ে কনফিগারেশনের পাশে লিখে রাখা উচিত, নইলে পরবর্তী প্রকৌশলী ধরে নেবেন অন্যটি বেছে নেওয়া হয়েছে। যা-ই বাছুন, নিচের দুটি কমান্ডই পরিবর্তনের আগে বর্তমান অবস্থা দেখায়।
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsঅ্যাকাউন্ট প্রমাণীকরণ অনুমোদনও মেটায় না। ব্যবহারকারী প্রয়োজনীয় পরিচয় প্রমাণ করার পরেও দলভুক্তি, ডিভাইসের অবস্থা এবং নেটওয়ার্ক অনুমতির স্পষ্ট ম্যাপিং দরকার। যে সংযোগ নিখুঁতভাবে প্রমাণীকরণ করে কিন্তু কিছুই অনুমোদন করে না, তা নীতির ফল, পদ্ধতির ত্রুটি নয়।