پاس ورڈ ای میل الٹ پلٹ کی صلاحیت ثابت کرتی ہے، کوئی اسکیما نہیں

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

ثبوت کو اسی سطح پر رکھیں، اور جائزے کا باقی حصہ درست رہے گا۔

پرانا راز واپس بھیجنا کیا ثابت کرتا ہے

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

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

یہ ڈیزائن کی دریافت کیوں ہے، اسٹوریج کا نقشہ نہیں

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

آپ جو کہہ سکتے ہیں وہ زیادہ محدود اور زیادہ مفید ہے: یہ راستہ راز بحال کر سکتا ہے، اس لیے پروڈکٹ یہ دعویٰ نہیں کر سکتا کہ کوئی بحال ہونے والی اسناد موجود نہیں۔ اس سے آگے ہر چیز کے لیے آپریٹر کا ثبوت درکار ہے۔

ری سیٹ کو اجازت کے گرد بنائیں

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

ای میل چینل سکیورٹی ماڈل کا حصہ ہے۔ اکاؤنٹ کا نام رکھنا کچھ ثابت نہیں کرتا، اور ایسا ری سیٹ بہاؤ جو ظاہر کرے کہ اکاؤنٹ موجود ہے یا نہیں، حملہ آور کو کام کرنے کے لیے فہرست دے دیتا ہے۔

جو پاس ورڈ محفوظ کرتا تھا اسے کالعدم کریں

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

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

درست جانچ مختصر ہے: پیغام کیا ثابت کرتا ہے، کیا نامعلوم رہتا ہے، اور کیا بحالی کنٹرول شدہ عمل کے ذریعے رسائی کی جگہ لیتی ہے۔