اگر پاس ورڈ سے دست بردار ہو سکتے ہیں تو اسے محفوظ کیوں رکھیں؟

وہ مسئلہ جسے ہم معمول سمجھنے کے عادی ہو چکے ہیں

تقریباً ہر ویب ایپلیکیشن میں ایک انتظامی پینل ہوتا ہے۔ اور انتظامی پینل کے ساتھ عموماً لاگ اِن کا پتہ، تصدیق کا فارم، صارف نام اور پاس ورڈ بھی ہوتا ہے۔

ہم اس ترتیب کے اتنے عادی ہو چکے ہیں کہ تقریباً یہ سوال کرنا ہی چھوڑ دیا ہے: کیا واقعی ہر چیز کا اسی طرح کام کرنا ضروری ہے؟

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

لیکن جب منصوبوں کی تعداد دس، بیس یا تیس ہو جائے تو کیا ہوتا ہے؟

میرے معاملے میں بات DigiMeld ایکو سسٹم کی ہے، جس میں تیس سے زیادہ خودمختار سافٹ ویئر منصوبے شامل ہیں۔ ہر ایک کا اپنا آرکیٹیکچر، سرور لاجک اور انتظامی انٹرفیس ہے۔

لہٰذا ہر منصوبے کے لیے انتظامی رسائی کا طریقۂ کار درکار ہوتا ہے۔

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

یہ کام کرتا تھا۔

لیکن ایک وقت ایسا آیا جب میں نے سوچا: مجھے اتنے سارے انتظامی پاس ورڈ محفوظ رکھنے کی ضرورت آخر کیوں ہے؟ مجھے صرف سرورز ہی نہیں بلکہ ان تک رسائی حاصل کرنے کے ذرائع کی بھی حفاظت کیوں کرنی پڑتی ہے؟

اور کیا اس ضرورت سے چھٹکارا حاصل کرنا ممکن نہیں؟

میرے ذہن میں ایک خیال آیا جو بعد میں میرے حل کی بنیاد بنا:

شاید مستقل لاگ اِن کی حفاظت کرنے کے بجائے، عارضی طور پر رسائی حاصل کرنے کے حق کی حفاظت کرنی چاہیے۔

مضبوط پاس ورڈ بنیادی مسئلے کو ختم نہیں کرتا

جدید ٹولز کی مدد سے بہت زیادہ اینٹروپی والے پاس ورڈ بنائے جا سکتے ہیں۔ درست طریقے سے بنایا گیا طویل، بے ترتیب پاس ورڈ براہِ راست آزمائش کے ذریعے تقریباً ناممکن ہے کہ توڑا جا سکے۔

لیکن پاس ورڈ چاہے کتنا ہی مضبوط کیوں نہ ہو، اسے کہیں نہ کہیں محفوظ رکھنا اور پھر استعمال کرنا ضروری ہے۔

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

تاہم بنیادی آرکیٹیکچرل ڈھانچا برقرار رہتا ہے: ایک مخصوص انٹرفیس موجود ہوتا ہے جس کے ذریعے صارف اپنی اسناد پیش کرتا ہے۔

اس پر درخواستیں بھیجی جا سکتی ہیں۔ اسے اسکین کیا جا سکتا ہے۔ یہ خودکار حملوں کا ہدف بن سکتا ہے۔

انتظامی پینل کا پتہ چھپایا جا سکتا ہے، عام راستے کی جگہ حروف کی ایک طویل، بے ترتیب ترتیب رکھی جا سکتی ہے، یا IP کے ذریعے رسائی محدود کی جا سکتی ہے۔

لیکن پھر ایک نیا سوال پیدا ہوتا ہے: اس پتے کو کہاں محفوظ رکھا جائے اور اسے کیسے استعمال کیا جائے؟

اور سب سے اہم بات — جب انتظامی رسائی صرف مخصوص اوقات میں درکار ہوتی ہے تو مستقل نقطۂ ورود برقرار رکھنے کی ضرورت ہی کیا ہے؟

میں اس خیال تک پہنچا جو بعد میں میرے حل کی بنیاد بنا:

ممکن ہے مستقل لاگ اِن کی حفاظت کرنے کے بجائے، عارضی طور پر رسائی حاصل کرنے کے حق کی حفاظت کرنی چاہیے۔

اگر لاگ اِن کا مانوس صفحہ سرے سے موجود ہی نہ ہو تو؟

میں نے اپنے منصوبوں میں انتظامی تصدیق کے روایتی طریقے سے دست بردار ہونے کا فیصلہ کیا۔

صرف لاگ اِن فارم چھپانے کا نہیں۔

پتے کا نام بدلنے کا نہیں۔

پاس ورڈ کی جگہ اس سے بھی زیادہ پیچیدہ پاس ورڈ رکھنے کا نہیں۔

بلکہ مستقل طور پر موجود پاس ورڈ والے لاگ اِن کی ضرورت ہی ختم کرنے کا۔

یقیناً، انتظامی انٹرفیس غائب نہیں ہوئے۔ ایپلیکیشنز کے انتظام کے لیے ان کی اب بھی ضرورت ہے۔

ان تک رسائی حاصل کرنے کا طریقہ بدل گیا ہے۔

اب منسلک منصوبوں کے انتظامی پینلز میں داخل ہونے کے لیے محفوظ شدہ صارف نام اور پاس ورڈ درج کرنے کی ضرورت نہیں ہوتی۔

اس کے بجائے، میں شناخت اور رسائی کے انتظام کے لیے اپنا نظام MeldID استعمال کرتا ہوں۔

بنیادی خیال سادہ ہے: انتظامی رسائی صرف اسی وقت، مخصوص صارف کو اور مخصوص منصوبے کے لیے دی جاتی ہے جب واقعی اس کی ضرورت ہو۔

مزید یہ کہ صرف اکاؤنٹ کا موجود ہونا انتظامی پینل کھولنے کا حق نہیں دیتا۔

یہ حق الگ سے دیا جانا چاہیے۔

ایسی رسائی جو ایک منٹ پہلے موجود نہیں تھی

شاید یہی اس پورے تصور کا سب سے دلچسپ حصہ ہے۔

روایتی طریقے میں منتظم کے پاس لاگ اِن کے ذرائع مستقل طور پر موجود ہوتے ہیں۔ جب تک یہ ذرائع کارآمد رہیں، وہ انہیں آج، کل یا ایک مہینے بعد استعمال کر سکتا ہے۔

میں نے یہ اصول بدلنے کا فیصلہ کیا۔

انتظامی اسناد کو مستقل رکھنے کے بجائے، لاگ اِن شروع کرنے کا ایک عارضی امکان استعمال کیا جاتا ہے۔

یہ امکان ایک قابلِ اعتماد موبائل ڈیوائس کے ذریعے درخواست پر بنایا جاتا ہے، اس میں خفیہ نگاری کے لحاظ سے مضبوط بے ترتیب جزو ہوتا ہے اور اس کی میعاد محدود ہوتی ہے۔

لیکن صرف اس عارضی لنک کا ہونا بھی بذاتِ خود رسائی حاصل کرنے کے برابر نہیں ہے۔

یہ ایک بنیادی نکتہ ہے۔

فرض کریں کسی کو کسی طرح یہ لنک مل گیا۔ صرف پتے کو خفیہ رکھنے پر مبنی عام نظام میں ایسا افشا ہونا ایک سنگین مسئلہ بن سکتا ہے۔

میرے طریقۂ کار میں یہ لنک صرف تصدیق کا عمل شروع کرنے کی اجازت دیتا ہے۔

آگے بڑھنے کے لیے MeldID کی قابلِ اعتماد موبائل ڈیوائس کے ذریعے الگ سے اجازت درکار ہوتی ہے۔

مناسب تصدیق کے بغیر انتظامی سیشن قائم نہیں ہوتا۔

اسی لیے میں عارضی لنک کو پاس ورڈ کا متبادل نہیں بلکہ رسائی دینے کے طریقۂ کار کا ایک جزو سمجھتا ہوں۔

یہ جاننا کہ کہاں رجوع کرنا ہے اور داخل ہونے کا حق ہونا — دو بالکل مختلف باتیں ہیں۔

فون رسائی کے انتظام کا ذریعہ بن جاتا ہے

اس طریقۂ کار میں موبائل ڈیوائس کا کردار عام یک وقتی کوڈ بنانے والے آلے سے کہیں زیادہ اہم ہے۔

اسے انتظامی رسائی سے متعلق اقدامات کی تصدیق کے لیے استعمال کیا جاتا ہے۔

جب میں انتظامی پینل کھولنا چاہتا ہوں تو نظام MeldID کے ذریعے تصدیق کی درخواست کرتا ہے۔

مجھے قابلِ اعتماد ڈیوائس پر متعلقہ درخواست دکھائی دیتی ہے اور میں اس کی تصدیق کرتا ہوں۔

اور صرف کامیاب جانچ کے بعد ہی نظام لاگ اِن کے عمل کو آگے بڑھانے کی اجازت دیتا ہے۔

اس دوران تصدیق کا تعلق کسی مخصوص اقدام سے ہوتا ہے، نہ کہ محض اس بات سے کہ فون اَن لاک کیا گیا ہے۔

موبائل بایومیٹرکس صارف کی ڈیوائس پر مقامی طور پر تصدیق کرتے ہیں، جبکہ سرور کی جانب سے رجسٹرڈ ڈیوائس کی خفیہ نگاری پر مبنی توثیق کی جانچ کی جاتی ہے۔

اس طریقے سے صرف پاس ورڈ یا اس اطلاع پر انحصار نہیں کرنا پڑتا کہ صارف نے مبینہ طور پر لاگ اِن کی تصدیق کر دی ہے۔

یہاں ایک اور فائدہ بھی سامنے آتا ہے: قابلِ اعتماد ڈیوائسز کا انتظام کیا جا سکتا ہے۔

اگر کسی ڈیوائس کو اب رسائی کی تصدیق کے لیے استعمال نہیں کرنا چاہیے تو اس کی قابلِ اعتماد حیثیت منسوخ کی جا سکتی ہے۔

اس کے بعد وہ متعلقہ کارروائیوں کی تصدیق کا فعال ذریعہ نہیں رہتی۔

ایک نظام — بہت سے خودمختار منصوبے

جب میں نے یہ طریقۂ کار تیار کرنا شروع کیا تو اہم کاموں میں سے ایک ہر منصوبے کی خودمختاری برقرار رکھنا تھا۔

میں تمام انتظامی پینلز کو ایک بہت بڑی ایپلیکیشن میں ضم نہیں کرنا چاہتا تھا۔

DigiMeld کی ہر سروس کو اپنی لاجک، ترتیبات، صارفین اور ڈیٹا کا انتظام بدستور خود کرنا چاہیے۔

اسی لیے میں نے دونوں کام الگ کر دیے۔

MeldID شناخت اور انتظامی رسائی کی اجازت دینے کا ذمہ دار ہے۔

جبکہ ہر منصوبہ اپنے انتظامی افعال اور موجودہ اختیارات کی جانچ خود کرتا ہے۔

یوں ایپلیکیشنز کو مرکزی بنائے بغیر رسائی کے انتظام کا مرکزی طریقۂ کار تشکیل پایا۔

اس کے علاوہ، اجازتیں الگ الگ دی جاتی ہیں۔

کسی ایک منصوبے کا منتظم صرف MeldID اکاؤنٹ رکھنے کی وجہ سے خودبخود دیگر منصوبوں تک رسائی حاصل نہیں کر لیتا۔

ہر انتظامی شعبے کے لیے اجازت یافتہ صارفین کا الگ حلقہ مقرر کیا جا سکتا ہے۔

اس کے ساتھ عام صارفین کے حقوق اور انتظامی اختیارات الگ الگ رہتے ہیں۔

درجنوں سروسز پر مشتمل ایکو سسٹم کے لیے یہ خاص طور پر سہل ثابت ہوا۔

مجھے مستقل کے مقابلے میں عارضی رسائی کیوں زیادہ پسند ہے

ایک اور اصول بھی ہے جسے میں نے جان بوجھ کر نظام میں شامل کیا۔

انتظامی رسائی غیر معینہ مدت تک برقرار نہیں رہنی چاہیے۔

اجازت محدود مدت کے لیے مؤثر ہوتی ہے اور اس بات سے قطع نظر ختم ہو جاتی ہے کہ صارف براؤزر میں کام کر رہا ہے یا نہیں۔

میعاد ختم ہونے کے بعد کام جاری رکھنے کے لیے تصدیق کا نیا عمل درکار ہوتا ہے۔

اس طرح ایک بار مکمل ہونے والی تصدیق مستقل طور پر مؤثر حق نہیں بن جاتی۔

لیکن صرف میعاد محدود کرنا کافی نہیں۔

پہلے سے دی گئی رسائی کو وقت سے پہلے ختم کرنے کی صلاحیت بھی اہم ہے۔

اسی لیے MeldID میں انتظامی اجازتیں مرکزی طور پر منسوخ کرنے کی سہولت موجود ہے۔

جب کوئی اجازت منسوخ کی جاتی ہے تو منسلک منصوبوں کو اس سے متعلقہ واقعے کی اطلاع ملتی ہے اور وہ اس سے وابستہ انتظامی سیشنز منسوخ کر دیتے ہیں۔

یوں صارف کے کامیابی سے لاگ اِن ہونے پر رسائی کا انتظام ختم نہیں ہو جاتا۔

میرے لیے اختیارات منسوخ کرنے کی صلاحیت اتنی ہی اہم ہے جتنی انہیں دینے کی۔

اس کے ساتھ، ایک تقسیم شدہ نظام کو واقعات کی ترسیل میں تاخیر، بعض اجزا کی عارضی عدم دستیابی اور عملی کام کے دیگر حالات کو مدِنظر رکھنا چاہیے۔ سیشن کی میعاد محدود رکھنا ایک اضافی حفاظتی حد فراہم کرتا ہے۔

روزمرہ کے کام میں کیا بدلا؟

سب سے پہلے، محفوظ شدہ انتظامی پاس ورڈز تک بار بار رسائی حاصل کرنے کی ضرورت ختم ہو گئی۔

اب مجھے ہر منسلک انتظامی پینل میں داخل ہونے کے لیے اسناد کا ایک مجموعہ براؤزر میں رکھنے کی ضرورت نہیں ہے۔

اس کے بجائے، میں ایک ہی طریقۂ کار کے ذریعے اجازتوں کا انتظام کرتا ہوں۔

مطلوبہ منصوبہ منتخب کرتا ہوں، رسائی کی تصدیق کرتا ہوں اور کام شروع کر دیتا ہوں۔

جب انتظامی رسائی کی مزید ضرورت نہ ہو تو اسے منسوخ کیا جا سکتا ہے۔

یہ خاص طور پر سہل ہے کہ نیا منصوبہ شامل ہونے پر انتظامی تصدیق کا پورا نظام ازسرِنو تیار نہیں کرنا پڑتا۔

اسے موجودہ طریقۂ کار سے منسلک کرنا اور مطلوبہ اجازتیں مقرر کرنا کافی ہے۔

یقیناً، اس کا مطلب یہ نہیں کہ سکیورٹی کے تمام خطرات ختم ہو گئے ہیں۔

عارضی اجازتوں، قابلِ اعتماد ڈیوائسز، سرور سیشنز اور مرکزی انفراسٹرکچر کو بھی تحفظ درکار ہے۔

لیکن اب مجھے ہر ایپلیکیشن کے لیے انتظامی پاس ورڈز کا انتظام الگ سے کرنے کا ایک ہی مسئلہ بار بار حل کرنے کی ضرورت نہیں۔

اور یہی میرے ابتدائی مقاصد میں سے ایک تھا۔

کیا ایسی ٹیکنالوجیز پہلے سے موجود نہیں ہیں؟

یقیناً موجود ہیں۔

بغیر پاس ورڈ تصدیق، خصوصی اختیارات تک رسائی کا انتظام، عارضی اجازتیں اور قابلِ اعتماد ڈیوائسز کے ذریعے تصدیق — یہ سب معلوماتی سکیورٹی کی صنعت میں کافی عرصے سے معروف ہیں۔

ایسے طریقے Identity and Access Management، Privileged Access Management کے نظاموں اور Zero Trust کے تصورات میں دیکھے جا سکتے ہیں۔

میں ان اصولوں کو ایجاد کرنے کا دعویٰ نہیں کرتا۔

میرا کام کچھ اور تھا۔

مجھے ایک ایسا مربوط نظام بنانا تھا جو DigiMeld کے انفراسٹرکچر کے مخصوص مسائل حل کرے اور بہت سے خودمختار منصوبوں تک انتظامی رسائی کا انتظام ممکن بنائے۔

نتیجتاً، میں نے کئی معروف طریقوں کو ایک ایسے آرکیٹیکچر میں یکجا کیا جو میری ضروریات کے مطابق ہے۔

اور میرا خیال ہے کہ انجینئرنگ کے کام کی قدر لازماً کوئی بالکل نئی ٹیکنالوجی ایجاد کرنے میں نہیں ہوتی۔

کبھی کبھی یہ قدر مسئلے کو درست طور پر بیان کرنے اور اس کے لیے موزوں حل تلاش کرنے میں ہوتی ہے۔

MeldID صرف انتظامی پینلز کے لیے نہیں

یہاں ایک بات الگ سے واضح کرنا ضروری ہے۔

MeldID کو صرف میرے اپنے انتظامی رسائی کے آلے کے طور پر نہیں بنایا گیا تھا۔

یہ ڈویلپرز کو اپنی ایپلیکیشنز میں شناخت اور لاگ اِن کی تصدیق کے طریقے شامل کرنے کے لیے SDK بھی فراہم کرتا ہے۔

اور یہ SDK مفت دستیاب ہے۔

مثال کے طور پر، کوئی بیرونی ڈویلپر صارف کی توثیق کے لیے اضافی سطح کے طور پر MeldID استعمال کر سکتا ہے۔

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

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

اس سے اسناد افشا ہونے کی صورت میں غیر مجاز رسائی کا خطرہ کم کیا جا سکتا ہے۔

MeldID کی اس عام طور پر دستیاب سہولت اور DigiMeld کے منصوبوں کے لیے میرے تیار کردہ انتظامی رسائی کے طریقۂ کار میں فرق کرنا اہم ہے۔

دونوں اعتماد اور اقدامات کی تصدیق کے مشترکہ اصول استعمال کرتے ہیں، لیکن ان کے مقاصد مختلف ہیں۔

سکیورٹی صرف موجودہ چیزوں کی حفاظت کا نام نہیں

اس نظام پر کام کرنے سے مجھے تصدیق کے مانوس طریقوں کو نئے انداز سے دیکھنے کا موقع ملا۔

ہم اکثر ان چیزوں کی حفاظت کرنے کی کوشش کرتے ہیں جو صرف تاریخی وجوہات کی بنا پر موجود ہیں۔

ہم نئی جانچ، پابندیاں، اضافی پاس ورڈز اور تحفظ کی مزید تہیں شامل کرتے ہیں۔

کبھی کبھی ایسا کرنا واقعی ضروری ہوتا ہے۔

لیکن کبھی کبھی ایک مختلف سوال پوچھنا زیادہ مفید ہوتا ہے:

کیا جس طریقۂ کار کی حفاظت کی جا رہی ہے، اس کا پہلے والی شکل میں موجود رہنا لازمی ہے؟

میرے معاملے میں جواب نفی میں تھا۔

مجھے مستقل طور پر دستیاب انتظامی لاگ اِن فارم کی ضرورت نہیں تھی۔

مجھے ضرورت اس بات کی تھی کہ جب انتظامی اختیارات درکار ہوں، تب انہیں محفوظ طریقے سے حاصل کیا جا سکے۔

یہ دو مختلف کام ہیں۔

اور پہلے کام سے دوسرے کی طرف منتقلی نے نہ صرف تکنیکی آرکیٹیکچر بلکہ منصوبوں کے ساتھ روزمرہ کے کام کو بھی بدل دیا۔

یہ آخری پڑاؤ نہیں، بلکہ منتخب کردہ سمت ہے

آج یہ آرکیٹیکچر DigiMeld ایکو سسٹم کے ایک بڑے حصے میں پہلے ہی کام کر رہا ہے۔

باقی منصوبوں کو بتدریج انتظامی رسائی کے نئے طریقے پر منتقل کیا جا رہا ہے۔

میں ایک ایک کرکے منتقلی کر رہا ہوں، ہر ایپلیکیشن کے کام کی جانچ کرتا ہوں، اور منتقلی مکمل ہونے کے بعد پورے نظام کا اضافی آڈٹ کرنے کا ارادہ رکھتا ہوں۔

انٹرفیس کے بعض اجزا اور سیشن مینجمنٹ کے قواعد اب بھی تبدیل ہو سکتے ہیں۔

لیکن بنیادی خیال طے ہو چکا ہے۔

میں اس طریقے پر واپس نہیں جانا چاہتا جس میں اپنے درجنوں منصوبوں کا انتظام کرنے کے لیے مجھے درجنوں انتظامی پاس ورڈ مسلسل محفوظ رکھنے اور استعمال کرنے پڑیں۔

اس کے ساتھ، میں اپنی تشکیل کردہ صورت کو سب کے لیے ایک عالمگیر حل نہیں سمجھتا۔

مختلف اداروں کی ضروریات، انفراسٹرکچر، خطرات کے ماڈل اور انتظام کے طریقے مختلف ہوتے ہیں۔

DigiMeld ایکو سسٹم کے لیے جو چیز سہل اور موزوں ہے، ضروری نہیں کہ وہ کسی دوسرے ڈویلپر کے لیے بھی بہترین ہو۔

تاہم، عارضی طور پر اختیارات دینے کا اصول توجہ کے لائق ہے۔

اختتامیہ

میں نے یہ تجربہ اس لیے شیئر کرنے کا فیصلہ نہیں کیا کہ میں خود کو تصدیق کے کسی نئے طریقے کا موجد سمجھتا ہوں۔

اور نہ ہی اس لیے کہ میں ایک اور نظام کو مکمل طور پر محفوظ قرار دینا چاہتا ہوں۔

مکمل سکیورٹی کا کوئی وجود نہیں۔

مجھے بس اس سوال کا انداز دلچسپ لگتا ہے۔

مستقل انتظامی لاگ اِن کی حفاظت لامتناہی طور پر جاری رکھنے کے بجائے، یہ سوچا جا سکتا ہے کہ اس کا موجود ہونا ضروری بھی ہے یا نہیں۔

بہت سے پاس ورڈ محفوظ رکھنے کے بجائے — عارضی اجازتیں استعمال کی جا سکتی ہیں۔

پہلی تصدیق کے بعد خودکار طور پر اعتماد کرنے کے بجائے — مخصوص اختیارات دیے جانے کی تصدیق کی جا سکتی ہے۔

سیشن ختم ہونے کا انتظار کرنے کے بجائے — مرکزی طور پر رسائی منسوخ کرنے کا امکان رکھا جا سکتا ہے۔

اور آخر میں، ہر منصوبے کے لیے لاگ اِن کا الگ طریقۂ کار بنانے کے بجائے — ایپلیکیشنز کی خودمختاری برقرار رکھتے ہوئے انتظامی رسائی کے انتظام کا ایک مشترکہ نظام بنایا جا سکتا ہے۔

میں یہ دعویٰ نہیں کرتا کہ اس طریقے سے نظام کے متاثر ہونے کا امکان ختم ہو جاتا ہے۔

یہ صرف توجہ کا مرکز مستقل طور پر موجود اسناد کی حفاظت سے ہٹا کر اختیارات کو قابو کے ساتھ دینے اور ختم کرنے پر لے آتا ہے۔

ممکن ہے، حملے کی سطح کم کرنے کا سب سے مؤثر طریقہ کبھی کبھی تحفظ کا ایک اور طریقہ شامل کرنا نہیں بلکہ ایسی چیز سے دست بردار ہونا ہو جس کے بغیر نظام بخوبی کام کر سکتا ہے۔

MeldID Admin Gateway کی کہانی میرے لیے اسی خیال سے شروع ہوئی۔