پہلے 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اکاؤنٹ کی تصدیق اجازت کو بھی طے نہیں کرتی۔ گروپ رکنیت، آلے کی حالت اور نیٹ ورک اجازت کو صارف کے مطلوبہ شناخت ثابت کرنے کے بعد بھی واضح نقشہ بندی چاہیے۔ جو رابطہ مکمل طور پر تصدیق ہوتا ہے اور کچھ اجازت نہیں دیتا، وہ پالیسی کا نتیجہ ہے، طریقے کی خرابی نہیں۔