آپ کا VPN پاس ورڈ صرف اس کے تصدیق کنندہ جتنا نجی ہے

کسی بھی VPN لاگ ان کے بارے میں چار سوالات پر غور کریں: سفر کے دوران پاس ورڈ کی حفاظت کیا کرتا ہے، کون سا جزو اسے وصول کرتا ہے، وہ جزو اس کے ساتھ کیا کرتا ہے، اور بعد میں کیا محفوظ ہوتا ہے۔ ہر جواب ایک الگ کنٹرول ہے، اور ایک پر مضبوط جواب باقی کے بارے میں کچھ نہیں کہتا۔ غلطی یہ ہے کہ ٹنل انکرپشن کو ایسے سمجھا جائے جیسے وہ چاروں کو ڈھکتا ہو۔ یہ صرف پہلے کو ڈھکتا ہے۔

پوچھیں کہ سیشن کون ختم کرتا ہے، نہ کہ سیشن انکرپٹ ہے یا نہیں۔

بالکل کس کے لیے انکرپٹ کیا گیا ہے؟

TLS کلائنٹ اور کنکشن ختم کرنے والے کے درمیان پاس ورڈ کی حفاظت کرتا ہے۔ اگر وہ آخری نقطہ VPN گیٹ وے ہو، تو گیٹ وے کا توثیق کوڈ سادہ متن میں پاس ورڈ دیکھتا ہے، اس کی توثیق کرتا ہے، اور اسے یا اس سے ماخوذ قدر آگے بھیجتا ہے۔ یہی مطلوبہ ڈیزائن ہے، رساؤ نہیں۔ راستے میں نیٹ ورک کا مبصر کوئی مفید چیز نہیں سیکھتا، اور تصدیق کرنے والا جزو وہ سب سیکھتا ہے جس کی اسے ضرورت ہے۔

OpenVPN کمیونٹی اسے واضح طور پر دستاویز کرتی ہے: auth-user-pass-verify جمع کرائے گئے اسناد کو تصدیق اسکرپٹ یا پلگ ان کے حوالے کرتا ہے۔ یہ اجزاء کے درمیان جان بوجھ کر حوالگی ہے، اور یہ نامزد فریق کے طور پر اعتماد کے ماڈل میں شامل ہے۔

تصدیق کنندہ پاس ورڈ دیکھتا ہے

ایک بار جب کوئی جزو تصدیق کے لیے پاس ورڈ وصول کر لیتا ہے، تو راز اندر رہتا ہے یا نہیں یہ اس جزو کے رسائی کنٹرول، لاگنگ اور کوڈ کے معیار سے طے ہوتا ہے۔ اسناد کو لاگ میں لکھنے والی اسکرپٹ، یا انہیں کیش کرنے والا پلگ ان، پروٹوکول سے کہیں زیادہ بڑا انکشاف پیدا کرتا ہے۔ رسائی ٹنل پر نہیں بلکہ آرکیٹیکچر اور کرداروں پر منحصر ہے، اسی لیے تصدیق کنندہ کو کنٹرول کرنے والا سروس مالک تشخیص میں شامل ہوتا ہے۔

مختلف طریقے مختلف مواد آشکار کرتے ہیں۔ سرٹیفکیٹ کے ذریعے توثیق نجی کلید کو بھیجے بغیر ثابت کرتی ہے، اور فیڈریشن کا بہاؤ VPN کو محدود دعویٰ جاری کرتے ہوئے پاس ورڈ شناخت فراہم کنندہ کے پاس رکھ سکتا ہے۔ وہ ڈیزائن دائرہ تنگ کرتے ہیں؛ ان میں سے کوئی بھی ہر قابل اعتماد فریق کو ختم نہیں کرتا۔

محفوظ شدہ ہیش مختلف مرحلے کی حفاظت کرتے ہیں

NIST کی رہنمائی محفوظ ترسیل کو مضبوط تصدیق کنندہ ذخیرے سے الگ کرتی ہے۔ نمک اور مہنگی ہیشنگ اسکیم محفوظ شدہ تصدیق کنندہ کے خطرے کو حل کرتی ہے، یعنی اگر ڈیٹا بیس لیک ہو جائے تو بعد میں کیا ہوتا ہے۔ وہ رن ٹائم جزو کے لیے کچھ نہیں کرتیں جسے موازنے کے لیے ان پٹ لینا ہی پڑتا ہے۔ رہنمائی کو اس طرح پڑھنا کہ گویا یہ رن ٹائم رازداری کا وعدہ کرتی ہے، زمرے کی غلطی ہے۔

لہٰذا اچھی طرح ہیش شدہ پاس ورڈ ذخیرہ اور بے نقاب تصدیق اسکرپٹ بغیر تضاد کے ایک ہی مصنوع میں ساتھ رہ سکتے ہیں۔

ایسا طریقہ منتخب کرنا جو دائرہ تنگ کرے

اگر تقاضا یہ ہے کہ گیٹ وے کو کبھی دوبارہ استعمال ہونے والا پاس ورڈ نہ ملے، تو ایسا طریقہ چنیں جو واقعی اس کی ضمانت دے؛ ڈیٹا سائفر بدلنے سے یہ خصوصیت پیدا نہیں ہوتی۔ VPN سرور کا سرٹیفکیٹ تصدیق کرنا بتاتا ہے کہ آپ کس ہم منصب تک پہنچے؛ یہ نہیں بتاتا کہ وہ ہم منصب بعد میں اسناد کے ساتھ کیسے برتاؤ کرتا ہے۔ سرور کی تصدیق برقرار رکھیں، ہر سروس کے لیے الگ اسناد استعمال کریں، اور تنظیم کے معاون شناختی بہاؤ کی پیروی کریں۔

پاس ورڈ وصول کرنے والا فریق، اسے درست کرنے والا فریق اور جس شکل میں اسے رکھا جاتا ہے وہ درج کریں۔ وہ تین جوابات کنکشن پروفائل کے ساتھ ہیں، کیونکہ وہ کسی بھی مخصوص ٹنل سے زیادہ عرصہ رہتے ہیں۔

مفید سوال یہ نہیں کہ پاس ورڈ انکرپٹ ہے یا نہیں، بلکہ یہ ہے کہ اسے کس سے چھپایا گیا ہے، کون سا جزو اسے وصول کرتا ہے اور بعد میں کون سی شکل باقی رہتی ہے۔