میرے پاس حال ہی میں اس بارے میں دوبارہ سوچنے کا وقت تھا کہ ایک محفوظ پاس ورڈ دوبارہ ترتیب دینے والی خصوصیت کو کس طرح کام کرنا چاہئے، پہلے جب میں اس فعالیت کو اس میں بنا رہا تھا۔ ، اور پھر جب اس نے کسی دوسرے شخص کو ایسا ہی کچھ کرنے میں مدد کی۔ دوسری صورت میں، میں اسے ری سیٹ فنکشن کو محفوظ طریقے سے نافذ کرنے کے طریقے کی تمام تفصیلات کے ساتھ ایک کیننیکل وسائل کا لنک دینا چاہتا تھا۔ تاہم، مسئلہ یہ ہے کہ ایسا کوئی وسیلہ موجود نہیں ہے، کم از کم ایسا نہیں جو ہر اس چیز کو بیان کرتا ہو جو میرے لیے اہم معلوم ہوتا ہے۔ لہذا میں نے اسے خود لکھنے کا فیصلہ کیا۔
آپ نے دیکھا، بھولے ہوئے پاس ورڈز کی دنیا دراصل کافی پراسرار ہے۔ بہت سے مختلف، مکمل طور پر قابل قبول نقطہ نظر اور بہت سے خطرناک ہیں۔ امکان یہ ہے کہ آپ نے ان میں سے ہر ایک کا سامنا ایک آخری صارف کے طور پر کئی بار کیا ہو۔ لہذا میں ان مثالوں کو یہ دکھانے کے لیے استعمال کرنے کی کوشش کروں گا کہ کون یہ ٹھیک کر رہا ہے، کون نہیں، اور آپ کو اپنی ایپ میں فیچر حاصل کرنے کے لیے کس چیز پر توجہ مرکوز کرنے کی ضرورت ہے۔
پاس ورڈ اسٹوریج: ہیشنگ، انکرپشن اور (ہانپنا!) سادہ متن
ہم اس بات پر بحث نہیں کر سکتے کہ بھولے ہوئے پاس ورڈز کا کیا کرنا ہے اس سے پہلے کہ ہم ان کو ذخیرہ کرنے کے طریقے پر بحث کریں۔ پاس ورڈز کو ڈیٹا بیس میں تین اہم اقسام میں سے ایک میں محفوظ کیا جاتا ہے:
- سادہ متن۔ ایک پاس ورڈ کالم ہے، جو سادہ متن کی شکل میں محفوظ ہے۔
- خفیہ کردہ۔ عام طور پر ہم آہنگ انکرپشن کا استعمال کرتے ہوئے (ایک کلید انکرپشن اور ڈکرپشن دونوں کے لیے استعمال ہوتی ہے)، اور انکرپٹڈ پاس ورڈ بھی اسی کالم میں محفوظ کیے جاتے ہیں۔
- ہیشڈ یکطرفہ عمل (پاس ورڈ کو ہیش کیا جا سکتا ہے، لیکن ڈی ہیش نہیں کیا جا سکتا)؛ پاس ورڈ میں امید کرنا چاہوں گا۔، ایک نمک کے بعد، اور ہر ایک اپنے اپنے کالم میں ہے۔
آئیے سیدھے سادہ ترین سوال کی طرف آتے ہیں: کبھی بھی سادہ متن میں پاس ورڈ نہ رکھیں! کبھی نہیں۔ کے لیے ایک واحد خطرہ ، ایک لاپرواہ بیک اپ، یا درجنوں دیگر آسان غلطیوں میں سے ایک - اور بس، گیم اوور، آپ کے تمام پاس ورڈز - یعنی معذرت، آپ کے تمام کلائنٹس کے پاس ورڈ عوامی ڈومین بن جائے گا۔ یقینا، اس کا مطلب یہ ہے کہ ایک بہت بڑا امکان ہے دوسرے سسٹمز میں ان کے تمام اکاؤنٹس سے۔ اور یہ آپ کی غلطی ہوگی۔
خفیہ کاری بہتر ہے، لیکن اس کی کمزوریاں ہیں۔ خفیہ کاری کے ساتھ مسئلہ ڈکرپشن ہے؛ ہم ان پاگل نظر آنے والے سائفرز کو لے سکتے ہیں اور انہیں واپس سادہ متن میں تبدیل کر سکتے ہیں، اور جب ایسا ہوتا ہے تو ہم انسانی پڑھنے کے قابل پاس ورڈ کی صورت حال پر واپس آ جاتے ہیں۔ یہ کیسے ہوتا ہے؟ کوڈ میں ایک چھوٹی سی خامی آ جاتی ہے جو پاس ورڈ کو ڈکرپٹ کرتا ہے، اسے عوامی طور پر دستیاب کر دیتا ہے - یہ ایک طریقہ ہے۔ ہیکرز اس مشین تک رسائی حاصل کرتے ہیں جس پر انکرپٹڈ ڈیٹا محفوظ ہوتا ہے - یہ دوسرا طریقہ ہے۔ ایک اور طریقہ، دوبارہ، ڈیٹا بیس کا بیک اپ چوری کرنا ہے اور کسی کو انکرپشن کی بھی مل جاتی ہے، جو اکثر بہت غیر محفوظ طریقے سے محفوظ ہوتی ہے۔
اور یہ ہمیں ہیشنگ کی طرف لاتا ہے۔ ہیشنگ کے پیچھے خیال یہ ہے کہ یہ ایک طرفہ ہے۔ صارف کے داخل کردہ پاس ورڈ کا اس کے ہیشڈ ورژن سے موازنہ کرنے کا واحد طریقہ ان پٹ کو ہیش کرنا اور ان کا موازنہ کرنا ہے۔ رینبو ٹیبل جیسے ٹولز سے حملوں کو روکنے کے لیے، ہم اس عمل کو بے ترتیبی کے ساتھ نمکین کرتے ہیں (میرا پڑھیں کرپٹوگرافک اسٹوریج کے بارے میں)۔ بالآخر، اگر صحیح طریقے سے لاگو کیا جائے تو، ہم یقین رکھ سکتے ہیں کہ ہیشڈ پاس ورڈ دوبارہ کبھی سادہ متن نہیں بنیں گے (میں ایک اور پوسٹ میں مختلف ہیشنگ الگورتھم کے فوائد کے بارے میں بات کروں گا)۔
ہیشنگ بمقابلہ خفیہ کاری کے بارے میں ایک فوری دلیل: آپ کو پاس ورڈ ہیش کرنے کے بجائے انکرپٹ کرنے کی واحد وجہ یہ ہے کہ جب آپ کو سادہ متن میں پاس ورڈ دیکھنے کی ضرورت ہو، اور آپ کو یہ کبھی نہیں کرنا چاہئے، کم از کم ایک معیاری ویب سائٹ کی صورتحال میں۔ اگر آپ کو اس کی ضرورت ہے، تو زیادہ تر امکان ہے کہ آپ کچھ غلط کر رہے ہیں!
ہوشیار!
پوسٹ کے متن کے نیچے فحش ویب سائٹ AlotPorn کے اسکرین شاٹ کا حصہ ہے۔ اسے صاف ستھرا تراشا گیا ہے لہذا ساحل سمندر پر آپ کو کچھ بھی نظر نہیں آتا ہے، لیکن اگر اس سے اب بھی کوئی مسئلہ پیدا ہونے کا امکان ہے تو نیچے اسکرول نہ کریں۔
ہمیشہ اپنا پاس ورڈ ری سیٹ کریں۔ کبھی نہیں اسے یاد نہ کرو
کیا آپ کو کبھی فنکشن بنانے کے لیے کہا گیا ہے؟ یاد دہانیاں پاس ورڈ ایک قدم پیچھے ہٹیں اور اس درخواست کے بارے میں الٹا سوچیں: یہ "یاد دہانی" کیوں ضروری ہے؟ کیونکہ صارف پاس ورڈ بھول گیا تھا۔ ہم واقعی کیا کرنا چاہتے ہیں؟ اسے دوبارہ لاگ ان کرنے میں مدد کریں۔
مجھے احساس ہے کہ "یاد دہانی" کا لفظ (اکثر) بول چال کے معنی میں استعمال ہوتا ہے، لیکن جو ہم واقعی کرنے کی کوشش کر رہے ہیں وہ ہے محفوظ طریقے سے صارف کو دوبارہ آن لائن ہونے میں مدد کریں۔. چونکہ ہمیں سیکورٹی کی ضرورت ہے، اس لیے یاد دہانی (یعنی صارف کو اپنا پاس ورڈ بھیجنا) مناسب نہ ہونے کی دو وجوہات ہیں:
- ای میل ایک غیر محفوظ چینل ہے۔ جس طرح ہم HTTP پر کوئی حساس چیز نہیں بھیجیں گے (ہم HTTPS استعمال کریں گے)، ہمیں ای میل پر کوئی حساس چیز نہیں بھیجنی چاہیے کیونکہ اس کی نقل و حمل کی تہہ غیر محفوظ ہے۔ درحقیقت، یہ محض ایک غیر محفوظ ٹرانسپورٹ پروٹوکول پر معلومات بھیجنے سے کہیں زیادہ بدتر ہے، کیونکہ میل اکثر اسٹوریج ڈیوائس پر اسٹور کیا جاتا ہے، سسٹم ایڈمنسٹریٹرز کے لیے قابل رسائی، فارورڈ اور تقسیم، میلویئر تک رسائی، وغیرہ۔ غیر خفیہ کردہ ای میل ایک انتہائی غیر محفوظ چینل ہے۔
- آپ کو ویسے بھی پاس ورڈ تک رسائی نہیں ہونی چاہیے۔ اسٹوریج پر پچھلے حصے کو دوبارہ پڑھیں - آپ کے پاس پاس ورڈ کا ایک ہیش ہونا چاہئے (ایک اچھے مضبوط نمک کے ساتھ)، یعنی آپ کو کسی بھی طرح سے پاس ورڈ نکالنے اور اسے میل کے ذریعے بھیجنے کے قابل نہیں ہونا چاہئے۔
میں ایک مثال کے ساتھ مسئلہ کو ظاہر کرتا ہوں۔ : یہاں ایک عام لاگ ان صفحہ ہے:
ظاہر ہے، پہلا مسئلہ یہ ہے کہ لاگ ان صفحہ HTTPS پر لوڈ نہیں ہوتا ہے، لیکن سائٹ آپ کو پاس ورڈ ("Send Password") بھیجنے کا بھی اشارہ کرتی ہے۔ یہ اوپر بیان کردہ اصطلاح کے بول چال کے استعمال کی ایک مثال ہو سکتی ہے، تو آئیے اسے ایک قدم آگے بڑھاتے ہیں اور دیکھتے ہیں کہ کیا ہوتا ہے:
بدقسمتی سے یہ زیادہ بہتر نظر نہیں آتا۔ اور ایک ای میل اس بات کی تصدیق کرتی ہے کہ کوئی مسئلہ ہے:
یہ ہمیں usoutdoor.com کے دو اہم پہلو بتاتا ہے:
- سائٹ پاس ورڈ ہیش نہیں کرتی ہے۔ بہترین طور پر، وہ خفیہ کردہ ہیں، لیکن امکان ہے کہ وہ سادہ متن میں محفوظ ہیں؛ ہمیں اس کے برعکس کوئی ثبوت نظر نہیں آتا۔
- سائٹ ایک غیر محفوظ چینل پر ایک طویل مدتی پاس ورڈ بھیجتی ہے (ہم واپس جا سکتے ہیں اور اسے بار بار استعمال کر سکتے ہیں)۔
اس سے باہر ہونے کے ساتھ، ہمیں یہ چیک کرنے کی ضرورت ہے کہ آیا ری سیٹ کا عمل محفوظ طریقے سے کیا گیا ہے۔ ایسا کرنے کا پہلا قدم یہ یقینی بنانا ہے کہ درخواست گزار کو دوبارہ ترتیب دینے کا حق حاصل ہے۔ دوسرے لفظوں میں، اس سے پہلے ہمیں شناخت کی جانچ کی ضرورت ہے۔ آئیے اس پر ایک نظر ڈالتے ہیں کہ جب کسی شناخت کی تصدیق کی جاتی ہے تو پہلے یہ تصدیق کیے بغیر کہ درخواست کنندہ اصل میں اکاؤنٹ کا مالک ہے۔
صارف ناموں کی فہرست اور گمنامی پر اس کا اثر
یہ مسئلہ بصری طور پر بہترین طور پر بیان کیا گیا ہے۔ مسئلہ:
اگر آپ دیکھتے ہیں؟ پیغام پر توجہ دیں "اس ای میل ایڈریس کے ساتھ کوئی صارف رجسٹرڈ نہیں ہے۔" مسئلہ واضح طور پر پیدا ہوتا ہے اگر ایسی سائٹ تصدیق کرتی ہے۔ دستیابی اس طرح کے ای میل ایڈریس کے ساتھ رجسٹرڈ صارف۔ بنگو - آپ نے ابھی اپنے شوہر/باس/پڑوسی کا فحش فیٹش دریافت کیا ہے!
بلاشبہ، پورن رازداری کی اہمیت کی ایک نمایاں مثال ہے، لیکن کسی فرد کو مخصوص ویب سائٹ کے ساتھ منسلک کرنے کے خطرات اوپر بیان کی گئی ممکنہ طور پر عجیب صورتحال سے کہیں زیادہ وسیع ہیں۔ ایک خطرہ سوشل انجینئرنگ ہے۔ اگر حملہ آور کسی شخص کو سروس سے ملا سکتا ہے، تو اس کے پاس ایسی معلومات ہوں گی جسے وہ استعمال کرنا شروع کر سکتا ہے۔ مثال کے طور پر، وہ ویب سائٹ کے نمائندے کے طور پر ظاہر کرنے والے کسی شخص سے رابطہ کر سکتا ہے اور ارتکاب کرنے کی کوشش میں اضافی معلومات کی درخواست کر سکتا ہے۔ .
اس طرح کے طرز عمل سے "صارف نام کی گنتی" کا خطرہ بھی بڑھ جاتا ہے، جس کے تحت کوئی بھی ویب سائٹ پر صارف ناموں یا ای میل پتوں کے پورے مجموعہ کے وجود کی توثیق کر سکتا ہے صرف گروپ سوالات کر کے اور ان کے جوابات کا جائزہ لے کر۔ کیا آپ کے پاس تمام ملازمین کے ای میل پتوں کی فہرست ہے اور اسکرپٹ لکھنے کے لیے چند منٹ ہیں؟ پھر آپ دیکھیں کہ مسئلہ کیا ہے!
متبادل کیا ہے؟ حقیقت میں، یہ بہت آسان ہے، اور حیرت انگیز طور پر لاگو کیا جاتا ہے :
یہاں Entropay اپنے سسٹم میں کسی ای میل ایڈریس کی موجودگی کے بارے میں قطعی طور پر کچھ بھی ظاہر نہیں کرتا ہے۔ کسی ایسے شخص کو جو اس ایڈریس کا مالک نہیں ہے۔... اگر آپ اپنے یہ ایڈریس اور یہ سسٹم میں موجود نہیں ہے، پھر آپ کو اس طرح کی ای میل موصول ہوگی:
بلاشبہ، وہاں قابل قبول حالات ہوسکتے ہیں جس میں کسی کو سوچتا ہےکہ آپ نے ویب سائٹ پر اندراج کرایا ہے۔ لیکن یہ معاملہ نہیں ہے، یا میں نے یہ ایک مختلف ای میل ایڈریس سے کیا ہے۔ اوپر دکھائی گئی مثال دونوں حالات کو اچھی طرح سے ہینڈل کرتی ہے۔ ظاہر ہے، اگر پتہ مماثل ہے، تو آپ کو ایک ای میل موصول ہوگا جس سے آپ کا پاس ورڈ دوبارہ ترتیب دینا آسان ہوجائے گا۔
Entropay کی طرف سے منتخب کردہ حل کی باریکیت یہ ہے کہ شناخت کی تصدیق اس کے مطابق کی جاتی ہے۔ ای میل کسی بھی آن لائن تصدیق سے پہلے۔ کچھ سائٹیں صارفین سے سیکیورٹی سوال کا جواب مانگتی ہیں (ذیل میں اس پر مزید) پر ری سیٹ کیسے شروع ہو سکتا ہے؛ تاہم، اس کے ساتھ مسئلہ یہ ہے کہ آپ کو شناخت کی کچھ شکل (ای میل یا صارف نام) فراہم کرتے ہوئے سوال کا جواب دینا ہوگا، جس کے بعد گمنام صارف کے اکاؤنٹ کی موجودگی کو ظاہر کیے بغیر بدیہی جواب دینا تقریباً ناممکن ہوجاتا ہے۔
اس نقطہ نظر کے ساتھ ہے چھوٹا استعمال میں کمی آئی کیونکہ اگر آپ غیر موجود اکاؤنٹ کو دوبارہ ترتیب دینے کی کوشش کرتے ہیں، تو فوری طور پر کوئی رائے نہیں ملتی۔ بلاشبہ، یہ ای میل بھیجنے کا پورا نقطہ ہے، لیکن حقیقی اختتامی صارف کے نقطہ نظر سے، اگر وہ غلط پتہ درج کرتے ہیں، تو انہیں پہلی بار تب ہی پتہ چلے گا جب وہ ای میل وصول کریں گے۔ یہ اس کی طرف سے کچھ تناؤ کا سبب بن سکتا ہے، لیکن اس طرح کے نادر عمل کی ادائیگی کے لیے یہ ایک چھوٹی سی قیمت ہے۔
ایک اور نوٹ، تھوڑا سا موضوع سے ہٹ کر: لاگ ان امدادی افعال جو یہ ظاہر کرتے ہیں کہ آیا صارف نام یا ای میل ایڈریس درست ہے ان میں بھی یہی مسئلہ ہے۔ واضح طور پر اسناد کی موجودگی کی تصدیق کرنے کے بجائے ہمیشہ صارف کو "آپ کا صارف نام اور پاس ورڈ کا امتزاج غلط ہے" پیغام کے ساتھ جواب دیں (مثال کے طور پر، "صارف کا نام درست ہے، لیکن پاس ورڈ غلط ہے")۔
ری سیٹ پاس ورڈ بھیجنا بمقابلہ ری سیٹ یو آر ایل بھیجنا
اگلا تصور جس پر ہمیں بحث کرنے کی ضرورت ہے وہ یہ ہے کہ اپنا پاس ورڈ کیسے ری سیٹ کریں۔ دو مقبول حل ہیں:
- سرور پر نیا پاس ورڈ بنانا اور اسے ای میل کے ذریعے بھیجنا
- ری سیٹ کے عمل کو آسان بنانے کے لیے ایک منفرد URL کے ساتھ ای میل بھیجیں۔
کے باوجود ، پہلا نقطہ کبھی استعمال نہیں کرنا چاہئے۔ اس کے ساتھ مسئلہ یہ ہے کہ اس کا مطلب ہے کہ وہاں ہے۔ ذخیرہ شدہ پاس ورڈجس پر آپ واپس جا سکتے ہیں اور کسی بھی وقت دوبارہ استعمال کر سکتے ہیں۔ یہ ایک غیر محفوظ چینل پر بھیجا گیا تھا اور آپ کے ان باکس میں رہتا ہے۔ امکانات یہ ہیں کہ ان باکسز موبائل آلات اور ای میل کلائنٹ کے درمیان مطابقت پذیر ہیں، نیز وہ ویب ای میل سروس میں بہت لمبے عرصے تک آن لائن اسٹور کیے جاسکتے ہیں۔ بات یہ ہے کہ میل باکس کو طویل مدتی ذخیرہ کرنے کا ایک قابل اعتماد ذریعہ نہیں سمجھا جا سکتا.
لیکن اس کے علاوہ، پہلا نقطہ ایک اور سنگین مسئلہ ہے - یہ جتنا ممکن ہو آسان بناتا ہے۔ بدنیتی پر مبنی ایک اکاؤنٹ کو بلاک کرنا۔ اگر میں کسی ایسے شخص کا ای میل ایڈریس جانتا ہوں جو کسی ویب سائٹ پر اکاؤنٹ کا مالک ہے، تو میں اسے کسی بھی وقت صرف ان کا پاس ورڈ دوبارہ ترتیب دے کر بلاک کر سکتا ہوں۔ یہ ایک چاندی کے تھال میں خدمت کے حملے سے انکار ہے! یہی وجہ ہے کہ ری سیٹ صرف درخواست دہندہ کے حقوق کی کامیاب تصدیق کے بعد ہی کیا جانا چاہیے۔
جب ہم ری سیٹ یو آر ایل کے بارے میں بات کرتے ہیں تو ہمارا مطلب کسی ویب سائٹ کا پتہ ہوتا ہے۔ ری سیٹ کے عمل کے اس خاص معاملے سے منفرد. بلاشبہ، یہ بے ترتیب ہونا چاہیے، اس کا اندازہ لگانا آسان نہیں ہونا چاہیے، اور اس میں اکاؤنٹ کا کوئی بیرونی لنک نہیں ہونا چاہیے جو اسے دوبارہ ترتیب دینے میں آسانی پیدا کرے۔ مثال کے طور پر، ری سیٹ URL کو "Reset/?username=JohnSmith" جیسا راستہ نہیں ہونا چاہیے۔
ہم ایک منفرد ٹوکن بنانا چاہتے ہیں جسے ری سیٹ یو آر ایل کے طور پر میل کیا جا سکے، اور پھر صارف کے اکاؤنٹ کے سرور ریکارڈ سے مماثل ہو، اس طرح اس بات کی تصدیق ہوتی ہے کہ اکاؤنٹ کا مالک درحقیقت وہی شخص ہے جو پاس ورڈ کو دوبارہ ترتیب دینے کی کوشش کر رہا ہے۔ مثال کے طور پر، ایک ٹوکن "3ce7854015cd38c862cb9e14a1ae552b" ہو سکتا ہے اور ری سیٹ کرنے والے صارف کی ID کے ساتھ ایک ٹیبل میں ذخیرہ کیا جا سکتا ہے اور اس وقت ٹوکن تیار کیا گیا تھا (ذیل میں اس پر مزید)۔ جب ای میل بھیجا جاتا ہے، تو اس میں ایک URL ہوتا ہے جیسا کہ "Reset/?id=3ce7854015cd38c862cb9e14a1ae552b"، اور جب صارف اسے ڈاؤن لوڈ کرتا ہے، تو صفحہ ٹوکن کی موجودگی کا اشارہ کرتا ہے، جس کے بعد یہ صارف کی معلومات کی تصدیق کرتا ہے اور اسے تبدیل کرنے کی اجازت دیتا ہے۔ پاس ورڈ
یقیناً، چونکہ اوپر کا عمل (امید ہے کہ) صارف کو نیا پاس ورڈ بنانے کی اجازت دیتا ہے، ہمیں اس بات کو یقینی بنانا ہوگا کہ URL HTTPS پر لوڈ ہے۔ نہیں، اس ٹوکن یو آر ایل کو ٹرانسپورٹ لیئر سیکیورٹی کا استعمال کرنا چاہیے تاکہ نئے پاس ورڈ فارم پر حملہ نہ کیا جا سکے۔ اور صارف کا بنایا ہوا پاس ورڈ ایک محفوظ کنکشن پر منتقل کیا گیا تھا۔
ری سیٹ یو آر ایل کے لیے بھی آپ کو ایک ٹوکن ٹائم لمٹ شامل کرنے کی ضرورت ہے تاکہ ری سیٹ کا عمل ایک مخصوص وقفہ کے اندر مکمل ہو سکے، کہہ لیں کہ ایک گھنٹے کے اندر۔ یہ یقینی بناتا ہے کہ ری سیٹ ٹائم ونڈو کو کم سے کم رکھا جائے تاکہ ری سیٹ URL کا وصول کنندہ صرف اس چھوٹی سی ونڈو کے اندر ہی کام کر سکے۔ بلاشبہ، حملہ آور دوبارہ ترتیب دینے کا عمل شروع کر سکتا ہے، لیکن انہیں ایک اور منفرد ری سیٹ URL حاصل کرنے کی ضرورت ہوگی۔
آخر میں، ہمیں یہ یقینی بنانا ہوگا کہ یہ عمل ڈسپوزایبل ہے۔ دوبارہ ترتیب دینے کا عمل مکمل ہونے کے بعد، ٹوکن کو ہٹا دینا چاہیے تاکہ ری سیٹ URL مزید فعال نہ رہے۔ پچھلا نقطہ اس بات کو یقینی بنانے کے لیے ضروری ہے کہ حملہ آور کے پاس ایک بہت چھوٹی ونڈو ہے جس کے دوران وہ ری سیٹ یو آر ایل کو جوڑ توڑ کر سکتا ہے۔ اس کے علاوہ، یقینا، ایک بار دوبارہ ترتیب دینے کے بعد، ٹوکن کی مزید ضرورت نہیں رہتی ہے۔
ان میں سے کچھ اقدامات حد سے زیادہ بے کار لگ سکتے ہیں، لیکن وہ استعمال کے ساتھ مداخلت نہیں کرتے ہیں اور حقیقت میں حفاظت کو بہتر بنائیں، حالانکہ ان حالات میں جن کی ہمیں امید ہے کہ شاذ و نادر ہی ہوں گے۔ 99% معاملات میں، صارف بہت کم وقت میں دوبارہ ترتیب دینے کو فعال کر دے گا اور مستقبل قریب میں دوبارہ پاس ورڈ کو دوبارہ ترتیب نہیں دے گا۔
کیپچا کا کردار
اوہ، کیپچا، حفاظتی خصوصیت جس سے ہم سب نفرت کرنا پسند کرتے ہیں! درحقیقت، کیپچا اتنا زیادہ تحفظ کا آلہ نہیں ہے جتنا کہ یہ ایک شناختی آلہ ہے - چاہے آپ ایک شخص ہوں یا روبوٹ (یا خودکار اسکرپٹ)۔ اس کا مقصد خودکار فارم جمع کرانے سے گریز کرنا ہے، جو یقیناً، کر سکتے ہیں سیکورٹی کو توڑنے کی کوشش کے طور پر استعمال کیا جائے۔ پاس ورڈ دوبارہ ترتیب دینے کے تناظر میں، کیپچا کا مطلب ہے کہ ری سیٹ فنکشن کو یا تو صارف کو اسپام کرنے یا اکاؤنٹس کی موجودگی کا تعین کرنے کی کوشش کرنے پر مجبور نہیں کیا جا سکتا (جو یقیناً ممکن نہیں ہو گا اگر آپ نے سیکشن میں دیے گئے مشورے پر عمل کیا۔ شناخت کی تصدیق)۔
یقینا، کیپچا خود کامل نہیں ہے۔ اس کے سافٹ ویئر کی "ہیکنگ" اور کامیابی کی کافی شرح (60-70%) حاصل کرنے کی بہت سی نظیریں موجود ہیں۔ مزید برآں، اس کے بارے میں میری پوسٹ میں ایک حل دکھایا گیا ہے۔ جہاں آپ لوگوں کو ہر ایک کیپچا کو حل کرنے اور 94% کی کامیابی کی شرح حاصل کرنے کے لیے ایک فیصد کا حصہ ادا کر سکتے ہیں۔ یعنی، یہ کمزور ہے، لیکن یہ (تھوڑا سا) داخلے میں رکاوٹ کو بڑھاتا ہے۔
آئیے پے پال کی مثال پر ایک نظر ڈالیں:
اس صورت میں، دوبارہ ترتیب دینے کا عمل اس وقت تک شروع نہیں ہو سکتا جب تک کہ کیپچا حل نہ ہو جائے، لہذا نظریاتی طور پر اس عمل کو خودکار کرنا ناممکن ہے۔ نظریہ میں۔
تاہم، زیادہ تر ویب ایپلیکیشنز کے لیے یہ حد سے زیادہ ہو جائے گا اور بالکل صحیح استعمال میں کمی کی نمائندگی کرتا ہے - لوگ صرف کیپچا کو پسند نہیں کرتے! اس کے علاوہ، کیپچا ایک ایسی چیز ہے جس پر آپ اگر ضرورت ہو تو آسانی سے واپس جا سکتے ہیں۔ اگر سروس حملے کی زد میں آنا شروع ہو جائے (یہ وہ جگہ ہے جہاں لاگنگ کام آتی ہے، لیکن بعد میں اس پر مزید)، پھر کیپچا شامل کرنا آسان نہیں ہو سکتا۔
خفیہ سوالات اور جوابات
ان تمام طریقوں کے ساتھ جن پر ہم نے غور کیا، ہم صرف ای میل اکاؤنٹ تک رسائی حاصل کرکے پاس ورڈ کو دوبارہ ترتیب دینے میں کامیاب ہوگئے۔ میں "صرف" کہتا ہوں، لیکن یقیناً، کسی اور کے ای میل اکاؤنٹ تک رسائی حاصل کرنا غیر قانونی ہے۔ چاہئے ایک پیچیدہ عمل ہو. البتہ .
درحقیقت، سارہ پیلن کے Yahoo! کی ہیکنگ کے بارے میں اوپر کا لنک دو مقاصد کو پورا کرتا ہے؛ سب سے پہلے، یہ بتاتا ہے کہ (کچھ) ای میل اکاؤنٹس کو ہیک کرنا کتنا آسان ہے، اور دوسرا، یہ ظاہر کرتا ہے کہ کس طرح خراب سیکیورٹی سوالات کو بدنیتی پر مبنی ارادے کے ساتھ استعمال کیا جا سکتا ہے۔ لیکن ہم اس پر بعد میں واپس آئیں گے۔
100% ای میل پر مبنی پاس ورڈ دوبارہ ترتیب دینے میں مسئلہ یہ ہے کہ آپ جس سائٹ کو دوبارہ ترتیب دینے کی کوشش کر رہے ہیں اس کے اکاؤنٹ کی سالمیت ای میل اکاؤنٹ کی سالمیت پر 100% منحصر ہو جاتی ہے۔ کوئی بھی جسے آپ کے ای میل تک رسائی حاصل ہے۔ کسی بھی اکاؤنٹ تک رسائی ہے جسے صرف ایک ای میل موصول کرکے دوبارہ ترتیب دیا جاسکتا ہے۔. ایسے اکاؤنٹس کے لیے، ای میل آپ کی آن لائن زندگی کے "تمام دروازوں کی کلید" ہے۔
اس خطرے کو کم کرنے کا ایک طریقہ یہ ہے کہ حفاظتی سوال اور جواب کا نمونہ لاگو کیا جائے۔ اس میں کوئی شک نہیں کہ آپ انہیں پہلے ہی دیکھ چکے ہیں: ایک سوال کا انتخاب کریں جس کا جواب صرف آپ ہی دے سکتے ہیں۔ ہے جواب جانیں، اور پھر جب آپ اپنا پاس ورڈ دوبارہ ترتیب دیں گے تو آپ سے اس کے لیے پوچھا جائے گا۔ اس سے یہ اعتماد بڑھتا ہے کہ ری سیٹ کرنے کی کوشش کرنے والا شخص درحقیقت اکاؤنٹ کا مالک ہے۔
سارہ پیلن پر واپس جائیں: غلطی یہ تھی کہ اس کے حفاظتی سوال/سوالات کے جوابات آسانی سے مل سکتے تھے۔ خاص طور پر جب آپ اتنی اہم عوامی شخصیت ہیں، تو آپ کی والدہ کے پہلے نام، تعلیمی تاریخ، یا ماضی میں کوئی کہاں رہ سکتا ہے کے بارے میں معلومات یہ سب راز نہیں ہے۔ درحقیقت، اس میں سے زیادہ تر تقریباً کسی کو بھی مل سکتا ہے۔ سارہ کے ساتھ ایسا ہی ہوا:
ہیکر ڈیوڈ کرنل نے پیلن کے اکاؤنٹ تک رسائی حاصل کر کے اس کے پس منظر کے بارے میں تفصیلات حاصل کیں، جیسے کہ اس کی یونیورسٹی اور تاریخ پیدائش، اور پھر Yahoo! کی بھولے ہوئے پاس ورڈ کی بازیابی کی خصوصیت کا استعمال کر کے۔
سب سے پہلے، یہ Yahoo! کی طرف سے ڈیزائن کی غلطی ہے! - اس طرح کے آسان سوالات کی وضاحت کر کے، کمپنی نے بنیادی طور پر حفاظتی سوال کی قدر کو سبوتاژ کیا، اور اس لیے اس کے نظام کے تحفظ کو۔ بلاشبہ، ای میل اکاؤنٹ کے لیے پاس ورڈز کو دوبارہ ترتیب دینا ہمیشہ زیادہ مشکل ہوتا ہے کیونکہ آپ مالک کو ای میل بھیج کر ملکیت ثابت نہیں کر سکتے (دوسرے ایڈریس کے بغیر)، لیکن خوش قسمتی سے آج کل ایسا نظام بنانے کے زیادہ استعمال نہیں ہیں۔
آئیے سیکیورٹی سوالات پر واپس آتے ہیں - صارف کو اپنے سوالات بنانے کی اجازت دینے کا ایک آپشن موجود ہے۔ مسئلہ یہ ہے کہ اس کے نتیجے میں خوفناک واضح سوالات پیدا ہوں گے:
آسمان کا رنگ کیا ہے؟
ایسے سوالات جو لوگوں کو بے چین کرتے ہیں جب کسی حفاظتی سوال کو شناخت کرنے کے لیے استعمال کیا جاتا ہے۔ شخص (مثال کے طور پر، کال سینٹر میں):
میں کرسمس پر کس کے ساتھ سوتا تھا؟
یا واضح طور پر احمقانہ سوالات:
آپ "پاس ورڈ" کیسے لکھتے ہیں؟
جب سیکورٹی کے سوالات کی بات آتی ہے، تو صارفین کو اپنے آپ کو بچانے کی ضرورت ہوتی ہے! دوسرے لفظوں میں، سیکورٹی سوال کا تعین خود سائٹ کے ذریعہ کیا جانا چاہئے، یا اس سے بھی بہتر، پوچھا جانا چاہئے۔ سیریز حفاظتی سوالات جن میں سے صارف منتخب کر سکتا ہے۔ اور اس کا انتخاب کرنا آسان نہیں ہے۔ ایک; مثالی طور پر صارف کو دو یا زیادہ حفاظتی سوالات کا انتخاب کرنا چاہیے۔ اکاؤنٹ رجسٹریشن کے وقت، جسے پھر دوسرے شناختی چینل کے طور پر استعمال کیا جائے گا۔ متعدد سوالات کا ہونا توثیق کے عمل میں اعتماد کو بڑھاتا ہے، اور بے ترتیب پن کو شامل کرنے کی صلاحیت بھی فراہم کرتا ہے (ہمیشہ ایک ہی سوال کو ظاہر نہیں کرتا)، نیز اصل صارف کے پاس ورڈ بھول جانے کی صورت میں تھوڑا سا فالتو پن فراہم کرتا ہے۔
ایک اچھا سیکورٹی سوال کیا ہے؟ یہ کئی عوامل سے متاثر ہوتا ہے:
- وہ ہونا چاہیے۔ مختصر - سوال واضح اور غیر مبہم ہونا چاہیے۔
- جواب ضرور ہوگا۔ مخصوص ہمیں ایسے سوال کی ضرورت نہیں ہے جس کا جواب ایک شخص مختلف طریقے سے دے سکے۔
- ممکنہ جوابات ہونے چاہئیں متنوع - کسی کا پسندیدہ رنگ پوچھنے سے ممکنہ جوابات کا ایک بہت چھوٹا ذیلی سیٹ ملتا ہے۔
- تلاش جواب پیچیدہ ہونا چاہیے - اگر جواب آسانی سے مل سکتا ہے۔ کوئی بھی (اعلیٰ عہدوں پر لوگوں کو یاد کرو) تو وہ برا ہے۔
- جواب ضرور ہوگا۔ مستقل وقت میں - اگر آپ کسی کی پسندیدہ فلم سے پوچھیں، تو ایک سال بعد جواب مختلف ہو سکتا ہے۔
جیسا کہ ایسا ہوتا ہے، وہاں ایک ویب سائٹ ہے جو اچھے سوالات پوچھنے کے لیے وقف ہے۔ . کچھ سوالات کافی اچھے لگتے ہیں، دوسرے اوپر بیان کیے گئے کچھ ٹیسٹ پاس نہیں کرتے، خاص طور پر "تلاش میں آسانی" ٹیسٹ۔
مجھے یہ ظاہر کرنے دو کہ PayPal کس طرح حفاظتی سوالات کو لاگو کرتا ہے اور خاص طور پر، سائٹ کی توثیق میں کی جانے والی کوشش۔ اوپر ہم نے عمل شروع کرنے کے لیے صفحہ دیکھا (کیپچا کے ساتھ)، اور یہاں ہم دکھائیں گے کہ آپ کے ای میل ایڈریس درج کرنے اور کیپچا حل کرنے کے بعد کیا ہوتا ہے:
نتیجے کے طور پر، صارف کو درج ذیل خط موصول ہوتا ہے:
اب تک سب کچھ بالکل نارمل ہے، لیکن اس ری سیٹ یو آر ایل کے پیچھے جو کچھ پوشیدہ ہے وہ یہ ہے:
لہذا، سیکورٹی کے سوالات کھیل میں آتے ہیں. درحقیقت، پے پال آپ کو اپنے کریڈٹ کارڈ نمبر کی تصدیق کرکے اپنا پاس ورڈ دوبارہ ترتیب دینے کی بھی اجازت دیتا ہے، اس لیے ایک اضافی چینل ہے جس تک بہت سی سائٹوں تک رسائی نہیں ہے۔ میں جواب دئیے بغیر اپنا پاس ورڈ تبدیل نہیں کر سکتا دونوں حفاظتی سوال (یا کارڈ نمبر نہیں جانتا)۔ یہاں تک کہ اگر کسی نے میرا ای میل ہائی جیک کر لیا، تب بھی وہ میرے PayPal اکاؤنٹ کا پاس ورڈ دوبارہ ترتیب نہیں دے پائیں گے جب تک کہ وہ میرے بارے میں کچھ اور ذاتی معلومات نہ جانتے ہوں۔ کیا معلومات؟ پے پال کے پیش کردہ حفاظتی سوال کے اختیارات یہ ہیں:
تلاش میں آسانی کے لحاظ سے اسکول اور ہسپتال کا سوال تھوڑا سا مشکل ہو سکتا ہے، لیکن دوسرے بہت خراب نہیں ہیں۔ تاہم، سیکورٹی کو بڑھانے کے لیے، پے پال کو اضافی شناخت کی ضرورت ہے۔ تبدیلیاں سیکورٹی سوالات کے جوابات:
پے پال محفوظ پاس ورڈ دوبارہ ترتیب دینے کی ایک خوبصورت مثال ہے: یہ وحشیانہ حملوں کے خطرے کو کم کرنے کے لیے کیپچا کو لاگو کرتا ہے، دو حفاظتی سوالات کی ضرورت ہوتی ہے، اور پھر صرف جوابات کو تبدیل کرنے کے لیے ایک اور طرح کی بالکل مختلف شناخت کی ضرورت ہوتی ہے—اور یہ صارف کے بعد۔ پہلے ہی سائن ان ہو چکا ہے۔ بالکل، یہ بالکل وہی ہے جو ہم ہیں متوقع پے پال سے؛ ایک مالیاتی ادارہ ہے جو بڑی رقم سے نمٹتا ہے۔ اس کا مطلب یہ نہیں ہے کہ ہر پاس ورڈ کو دوبارہ ترتیب دینے کے لیے ان مراحل پر عمل کرنا پڑتا ہے — زیادہ تر وقت یہ حد سے زیادہ ہوتا ہے — لیکن یہ ان معاملات کے لیے ایک اچھی مثال ہے جہاں سیکیورٹی سنگین کاروبار ہے۔
حفاظتی سوال کے نظام کی سہولت یہ ہے کہ اگر آپ نے اسے ابھی نافذ نہیں کیا ہے، تو آپ اسے بعد میں شامل کر سکتے ہیں اگر وسائل کے تحفظ کی سطح کی ضرورت ہو۔ اس کی ایک اچھی مثال ایپل ہے، جس نے حال ہی میں اس طریقہ کار کو نافذ کیا ہے۔ [مضمون 2012 میں لکھا گیا]. ایک بار جب میں نے اپنے آئی پیڈ پر ایپلیکیشن کو اپ ڈیٹ کرنا شروع کیا تو مجھے درج ذیل درخواست نظر آئی:
پھر میں نے ایک اسکرین دیکھی جہاں میں حفاظتی سوالات اور جوابات کے کئی جوڑے منتخب کر سکتا ہوں، نیز ایک ریسکیو ای میل ایڈریس:
جہاں تک پے پال کا تعلق ہے، سوالات پہلے سے منتخب کیے گئے ہیں اور ان میں سے کچھ دراصل بہت اچھے ہیں:
تینوں سوال/جواب کے جوڑے میں سے ہر ایک ممکنہ سوالات کے مختلف سیٹ کی نمائندگی کرتا ہے، لہذا اکاؤنٹ کو ترتیب دینے کے بہت سارے طریقے ہیں۔
آپ کے حفاظتی سوال کا جواب دینے کے حوالے سے غور کرنے کا ایک اور پہلو اسٹوریج ہے۔ ڈیٹا بیس میں سادہ ٹیکسٹ ڈیٹا بیس ہونے سے پاس ورڈ جیسے ہی خطرات لاحق ہوتے ہیں، یعنی ڈیٹا بیس کو فوری طور پر بے نقاب کرنے سے قیمت کا پتہ چلتا ہے اور نہ صرف ایپلیکیشن خطرے میں پڑتی ہے، بلکہ ممکنہ طور پر بالکل مختلف ایپلی کیشنز ایک جیسے سیکیورٹی سوالات کا استعمال کرتے ہوئے (وہاں دوبارہ) )۔ ایک آپشن محفوظ ہیشنگ ہے (ایک مضبوط الگورتھم اور ایک خفیہ طور پر بے ترتیب نمک)، لیکن پاس ورڈ ذخیرہ کرنے کے زیادہ تر معاملات کے برعکس، جواب کے سادہ متن کے طور پر نظر آنے کی ایک اچھی وجہ ہوسکتی ہے۔ ایک عام منظر نامہ ایک لائیو ٹیلی فون آپریٹر کے ذریعے شناخت کی تصدیق ہے۔ بلاشبہ، اس معاملے میں ہیشنگ بھی لاگو ہوتی ہے (آپریٹر آسانی سے کلائنٹ کے نام سے جواب داخل کر سکتا ہے)، لیکن بدترین صورت میں، خفیہ جواب کو کسی نہ کسی سطح پر کرپٹوگرافک سٹوریج پر موجود ہونا چاہیے، چاہے یہ صرف ہم آہنگی کی خفیہ کاری ہی کیوں نہ ہو۔ . خلاصہ: رازوں کو راز کی طرح سمجھو!
سیکیورٹی سوالات اور جوابات کا ایک حتمی پہلو یہ ہے کہ وہ سوشل انجینئرنگ کے لیے زیادہ خطرے سے دوچار ہیں۔ کسی اور کے اکاؤنٹ میں پاس ورڈ کو براہ راست نکالنے کی کوشش کرنا ایک چیز ہے، لیکن اس کی تشکیل (ایک مقبول سیکیورٹی سوال) کے بارے میں بات چیت شروع کرنا بالکل مختلف ہے۔ درحقیقت، آپ کسی کے ساتھ ان کی زندگی کے بہت سے پہلوؤں کے بارے میں بہت اچھی طرح سے بات کر سکتے ہیں جو شک پیدا کیے بغیر خفیہ سوال کر سکتے ہیں۔ بلاشبہ، حفاظتی سوال کا اصل نکتہ یہ ہے کہ اس کا تعلق کسی کی زندگی کے تجربے سے ہے، اس لیے یہ یادگار ہے، اور یہیں پر مسئلہ ہے۔ لوگ اپنی زندگی کے تجربات کے بارے میں بات کرنا پسند کرتے ہیں! اس کے بارے میں آپ بہت کم کر سکتے ہیں، صرف اس صورت میں جب آپ حفاظتی سوالات کے ایسے اختیارات کا انتخاب کریں تاکہ وہ ہوں۔ کم شاید سوشل انجینئرنگ کی طرف سے نکالا جا سکتا ہے.
[جاری ہے.]ایڈورٹائزنگ کے حقوق پر
وی ڈی سینا قابل اعتماد پیش کرتا ہے ، ہر سرور 500 میگا بٹس کے انٹرنیٹ چینل سے منسلک ہے اور DDoS حملوں سے مفت میں محفوظ ہے!
ماخذ: www.habr.com