دو عنصر کی تصدیق
ہر وہ چیز جس میں آپ پڑھتے ہیں۔ اس بنیاد پر متعلقہ شناخت درخواست کرنے والا جانتا ہے. وہ اپنا ای میل پتہ جانتا ہے، وہ جانتا ہے کہ اس تک کیسے رسائی حاصل کرنا ہے (یعنی وہ اپنا ای میل پاس ورڈ جانتا ہے)، اور وہ اپنے حفاظتی سوالات کے جوابات جانتا ہے۔
"علم" کو ایک توثیق کا عنصر سمجھا جاتا ہے۔ دو دیگر عام عوامل ہیں تمہارے پاس کیا ہے، جیسے ایک جسمانی آلہ، اور تم کون ہومثال کے طور پر، فنگر پرنٹس یا ریٹنا۔
زیادہ تر معاملات میں، حیاتیاتی شناخت کو انجام دینا ممکن نہیں ہے، خاص طور پر جب ہم ویب ایپلیکیشن سیکیورٹی کے بارے میں بات کر رہے ہیں، لہذا دو عنصر کی توثیق (2FA) عام طور پر دوسری صفت کا استعمال کرتی ہے - "جو آپ کے پاس ہے"۔ اس دوسرے عنصر کی ایک مقبول تبدیلی ایک جسمانی ٹوکن ہے، جیسے :
جسمانی ٹوکن اکثر کارپوریٹ VPNs اور مالیاتی خدمات میں تصدیق کے لیے استعمال ہوتا ہے۔ سروس کے ساتھ تصدیق کرنے کے لیے، آپ کو PIN کے ساتھ مل کر ٹوکن (جو اکثر تبدیل ہوتا رہتا ہے) پر پاس ورڈ اور کوڈ دونوں استعمال کرنے کی ضرورت ہے۔ نظریاتی طور پر، حملہ آور کی شناخت کے لیے، اسے پاس ورڈ کا علم ہونا چاہیے، اس کے پاس ٹوکن ہونا چاہیے، اور ٹوکن کا PIN بھی جاننا چاہیے۔ پاس ورڈ دوبارہ ترتیب دینے کے منظر نامے میں، پاس ورڈ خود واضح طور پر نامعلوم ہے، لیکن ٹوکن کا قبضہ اکاؤنٹ کی ملکیت ثابت کرنے کے لیے استعمال کیا جا سکتا ہے۔ بلاشبہ، کسی بھی حفاظتی عمل درآمد کے ساتھ، ، لیکن یقینی طور پر داخلے میں رکاوٹ کو بڑھاتا ہے۔
اس نقطہ نظر کے ساتھ اہم مسائل میں سے ایک لاگت اور عمل درآمد کی رسد ہے۔ ہم ہر گاہک کو جسمانی آلات کے حوالے کرنے اور انہیں نیا عمل سکھانے کے بارے میں بات کر رہے ہیں۔ اس کے علاوہ، صارفین کو اپنے ساتھ آلہ رکھنے کی ضرورت ہوتی ہے، جو ہمیشہ جسمانی ٹوکن کے ساتھ نہیں ہوتا ہے۔ دوسرا آپشن یہ ہے کہ ایس ایم ایس کا استعمال کرتے ہوئے تصدیق کے دوسرے عنصر کو لاگو کیا جائے، جو 2FA کی صورت میں اس بات کی تصدیق کے طور پر کام کر سکتا ہے کہ دوبارہ ترتیب دینے کا عمل انجام دینے والے شخص کے پاس اکاؤنٹ کے مالک کا موبائل فون ہے۔ یہاں یہ ہے کہ گوگل اسے کیسے کرتا ہے:
آپ کو بھی فعال کرنے کی ضرورت ہے۔ لیکن اس کا مطلب یہ ہے کہ اگلی بار جب آپ اپنا پاس ورڈ دوبارہ ترتیب دیں گے، تو آپ کا موبائل فون دوسرا تصدیقی عنصر بن سکتا ہے۔ مجھے اپنے آئی فون کا استعمال کرتے ہوئے ان وجوہات کی بنا پر ظاہر کرنے دیں جو جلد ہی واضح ہو جائیں گی۔
اکاؤنٹ کے ای میل ایڈریس کی شناخت کرنے کے بعد، گوگل اس بات کا تعین کرتا ہے کہ 2FA کو فعال کر دیا گیا ہے اور ہم تصدیق کے ذریعے اکاؤنٹ کو دوبارہ ترتیب دے سکتے ہیں، جو اکاؤنٹ کے مالک کے موبائل فون پر SMS کے ذریعے بھیجا جاتا ہے:
اب ہمیں دوبارہ ترتیب دینے کا عمل شروع کرنے کا انتخاب کرنا ہوگا:
یہ عمل رجسٹرڈ ایڈریس پر ای میل بھیجنے کا سبب بنتا ہے:
یہ ای میل ری سیٹ URL پر مشتمل ہے:
جب آپ ری سیٹ URL تک رسائی حاصل کرتے ہیں، تو ایک SMS بھیجا جاتا ہے اور ویب سائٹ آپ سے اسے درج کرنے کو کہتی ہے:
یہ ایس ایم ایس ہے:
اسے براؤزر میں ٹائپ کرنے کے بعد، ہم کلاسک پاس ورڈ دوبارہ ترتیب دینے والے علاقے میں واپس آ گئے ہیں:
یہ شاید تھوڑا سا لمبا لگتا ہے، اور ایسا ہے، لیکن فارم اس بات کی تصدیق کرتا ہے کہ ری سیٹ کرنے والے شخص کو اکاؤنٹ کے مالک کے ای میل ایڈریس اور موبائل فون تک رسائی حاصل ہے۔ لیکن یہ صرف ای میل کے ذریعے اپنا پاس ورڈ دوبارہ ترتیب دینے سے نو گنا زیادہ محفوظ ہو سکتا ہے۔ تاہم، مسائل ہیں ...
مسئلہ اسمارٹ فونز سے متعلق ہے۔ ذیل میں دکھایا گیا آلہ توثیق کے صرف ایک عنصر سے تصدیق کر سکتا ہے - یہ ایس ایم ایس وصول کرنے کے قابل ہے، لیکن ای میل نہیں:
تاہم، یہ آلہ SMS وصول کر سکتا ہے۔ и پاس ورڈ ری سیٹ ای میلز وصول کریں:
مسئلہ یہ ہے کہ ہم ای میل کو توثیق کے پہلے عنصر کے طور پر دیکھتے ہیں اور دوسرے کے طور پر SMS (یا یہاں تک کہ ٹوکن پیدا کرنے والی ایپ)، لیکن آج وہ ایک ڈیوائس میں یکجا ہیں۔ یقیناً، اس کا مطلب یہ ہے کہ اگر کوئی آپ کے اسمارٹ فون پر ہاتھ ڈالتا ہے، تو یہ ساری سہولت اس حقیقت تک کم ہو جائے گی کہ ہم دوبارہ ایک چینل پر واپس آ گئے ہیں۔ یہ دوسرا عنصر "یہ، آپ کے پاس ہے" کا مطلب ہے کہ آپ کے پاس پہلا عنصر بھی ہے۔ اور یہ سب ایک چار ہندسوں والے PIN سے محفوظ ہے... اگر فون میں PIN بھی ہو۔ и وہ بلاک کر دیا گیا تھا.
ہاں، گوگل کی طرف سے لاگو کیا گیا 2FA فیچر یقینی طور پر اضافی تحفظ فراہم کرتا ہے، لیکن یہ فول پروف نہیں ہے، اور یہ یقینی طور پر دو مکمل خود مختار چینلز پر منحصر نہیں ہے۔
صارف نام کے ذریعے دوبارہ ترتیب دیں بمقابلہ ای میل ایڈریس کے ذریعے دوبارہ ترتیب دیں۔
کیا مجھے صرف ای میل ایڈریس کے ذریعے دوبارہ سیٹ کرنے کی اجازت دینی چاہئے؟ یا صارف کو نام سے بھی ری سیٹ کرنے کے قابل ہونا چاہئے؟ صارف نام کے ذریعہ دوبارہ ترتیب دینے میں مسئلہ یہ ہے کہ صارف کو مطلع کرنے کا کوئی طریقہ نہیں ہے کہ صارف نام غلط ہے۔ ظاہر کیے بغیر کہ اس نام سے کسی اور کا اکاؤنٹ ہو سکتا ہے۔ پچھلے حصے میں، ایک ای میل ری سیٹ نے اس بات کو یقینی بنایا کہ اس ای میل کے صحیح مالک کو نظام میں عوامی طور پر اس کے وجود کو ظاہر کیے بغیر ہمیشہ فیڈ بیک ملے گا۔ یہ صرف صارف نام کا استعمال کرتے ہوئے نہیں کیا جا سکتا۔
تو جواب مختصر ہے: صرف ای میل۔ اگر آپ صرف صارف نام کا استعمال کرتے ہوئے دوبارہ ترتیب دینے کی کوشش کرتے ہیں، تو ایسے معاملات ہوں گے جب صارف حیران ہوگا کہ کیا ہوا، یا آپ اکاؤنٹس کے وجود کا انکشاف کریں گے۔ جی ہاں، یہ صرف ایک صارف نام ہے، ای میل پتہ نہیں، اور ہاں، کوئی بھی (دستیاب) صارف نام منتخب کر سکتا ہے، لیکن پھر بھی ایک اچھا موقع ہے کہ آپ صارفین کے نام کو دوبارہ استعمال کرنے کے رجحان کی وجہ سے بالواسطہ طور پر اکاؤنٹ کے مالکان کو ظاہر کر رہے ہوں گے۔
تو کیا ہوتا ہے جب کوئی اپنا صارف نام بھول جاتا ہے؟ یہ فرض کرتے ہوئے کہ صارف نام فوری طور پر کوئی ای میل ایڈریس نہیں ہے (جو اکثر ایسا ہوتا ہے)، یہ عمل اسی طرح کا ہے جیسے پاس ورڈ دوبارہ ترتیب دینا شروع ہوتا ہے- ایک ای میل ایڈریس داخل کرنا، اور پھر اس کے وجود کو ظاہر کیے بغیر اس ایڈریس پر پیغام بھیجنا۔ فرق صرف اتنا ہے کہ اس بار پیغام میں صرف صارف نام ہے نہ کہ پاس ورڈ ری سیٹ URL۔ یا تو وہ، یا ای میل کہے گا کہ اس پتے کا کوئی اکاؤنٹ نہیں ہے۔
شناخت کی تصدیق اور ای میل ایڈریس کی درستگی
پاس ورڈ دوبارہ ترتیب دینے کا ایک اہم پہلو، اور شاید بھی بہت زیادہ کلیدی پہلو ری سیٹ کرنے کی کوشش کرنے والے شخص کی شناخت کی تصدیق کرنا ہے۔ کیا یہ دراصل اکاؤنٹ کا جائز مالک ہے، یا کوئی اسے ہیک کرنے کی کوشش کر رہا ہے یا مالک کو تکلیف پہنچا رہا ہے؟
ظاہر ہے، شناخت کی تصدیق کے لیے ای میل سب سے آسان اور عام چینل ہے۔ یہ فول پروف نہیں ہے، اور ایسے بہت سے معاملات ہیں جہاں صرف اکاؤنٹ کے مالک کے پتے پر ای میلز موصول کرنا ہی کافی نہیں ہے اگر شناخت میں اعلیٰ درجے کے اعتماد کی ضرورت ہو (جس کی وجہ سے 2FA استعمال کیا جاتا ہے)، لیکن یہ تقریباً ہمیشہ ہی ہوتا ہے۔ نقطہ دوبارہ ترتیب دینے کا عمل۔
اگر ای میل اعتماد فراہم کرنے میں کردار ادا کرنے جا رہی ہے، تو پہلا قدم یہ یقینی بنانا ہے کہ ای میل ایڈریس درحقیقت درست ہے۔ اگر کسی نے غلط علامت بنائی ہے تو ظاہر ہے ری سیٹ شروع نہیں ہوگا۔ رجسٹریشن کے وقت ای میل کی تصدیق کا عمل ایڈریس کی درستگی کی تصدیق کرنے کا ایک قابل اعتماد طریقہ ہے۔ ہم سب نے اسے عملی طور پر دیکھا ہے: جب آپ سائن اپ کرتے ہیں، تو آپ کو کلک کرنے کے لیے ایک منفرد URL کے ساتھ ایک ای میل بھیجا جاتا ہے، جو اس بات کی تصدیق کرتا ہے کہ آپ اس ای میل اکاؤنٹ کے حقیقی مالک ہیں۔ اس عمل کے مکمل ہونے تک لاگ ان نہ کرنا اس بات کو یقینی بناتا ہے کہ ایڈریس کی تصدیق کرنے کی تحریک موجود ہے۔
سیکیورٹی کے بہت سے دوسرے پہلوؤں کی طرح، یہ ماڈل صارف کی شناخت پر اعتماد کے لحاظ سے بڑھتی ہوئی سیکیورٹی فراہم کرنے کے بدلے استعمال کی اہلیت سے سمجھوتہ کرتا ہے۔ یہ ایسی سائٹ کے لیے قابل قبول ہو سکتا ہے جہاں صارف رجسٹریشن کو بہت زیادہ اہمیت دیتا ہے اور خوشی سے اس عمل میں ایک اور قدم کا اضافہ کرے گا (معاوضہ خدمات، بینکنگ وغیرہ)، لیکن ایسی چیزیں صارف کو بند کر سکتی ہیں اگر وہ اکاؤنٹ کو "ڈسپوزایبل" سمجھتا ہے۔ ” اور استعمال کرتا ہے، مثال کے طور پر، محض ایک پوسٹ پر تبصرہ کرنے کے ایک ذریعہ کے طور پر۔
شناخت کرنا کہ کس نے دوبارہ ترتیب دینے کا عمل شروع کیا۔
ظاہر ہے، ری سیٹ فنکشن کے بدنیتی پر مبنی استعمال کی وجوہات ہیں، اور حملہ آور اسے بہت سے مختلف طریقوں سے استعمال کر سکتے ہیں۔ ایک سادہ چال جسے ہم درخواست کی اصلیت کی تصدیق کرنے میں مدد کے لیے استعمال کر سکتے ہیں (یہ چال عام طور پر کام کرتا ہے) - یہ درخواست کنندہ کے IP ایڈریس کو دوبارہ ترتیب دینے کی پیشکش کے خط میں شامل کیا جاتا ہے۔ یہ وصول کنندہ کو فراہم کرتا ہے۔ کچھ درخواست کے ماخذ کی شناخت کے لیے معلومات۔
یہاں ری سیٹ فنکشن کی ایک مثال ہے جو میں فی الحال ASafaWeb میں بنا رہا ہوں۔
"مزید تلاش کریں" کا لنک صارف کو سائٹ پر لے جاتا ہے۔ , اطلاع دینے کی معلومات جیسے کہ دوبارہ ترتیب دینے والے کا مقام اور تنظیم:
بلاشبہ، جو کوئی بھی اپنی شناخت چھپانا چاہتا ہے اس کے پاس اپنے حقیقی IP ایڈریس کو مبہم کرنے کے بہت سے طریقے ہیں، لیکن یہ درخواست کنندہ کی جزوی شناخت شامل کرنے کا ایک آسان طریقہ ہے، اور سب سے زیادہ معاملات میں، اس سے آپ کو اچھی طرح اندازہ ہو جائے گا کہ پاس ورڈ دوبارہ ترتیب دینے کی درخواست کون مکمل کرے گا۔
ای میل تبدیلی کی اطلاع
یہ پوسٹ ایک تھیم کے ساتھ پھیلی ہوئی ہے - مواصلات؛ اکاؤنٹ کے مالک کو زیادہ سے زیادہ بتائیں کہ عمل کے ہر مرحلے پر کیا ہو رہا ہے، بغیر کسی ایسی چیز کو ظاہر کیے جو کہ بدنیتی سے استعمال ہو سکتی ہے۔ یہی صورت حال پر لاگو ہوتا ہے جہاں پاس ورڈ حقیقت میں تبدیل ہو گیا ہے - مالک کو اس کی اطلاع دیں!
پاس ورڈ تبدیل کرنے کی دو وجوہات ہو سکتی ہیں:
- لاگ ان کے بعد پاس ورڈ تبدیل کریں کیونکہ صارف نیا پاس ورڈ چاہتا ہے۔
- لاگ ان کیے بغیر پاس ورڈ کو دوبارہ ترتیب دینا کیونکہ صارف اسے بھول گیا ہے۔
اگرچہ یہ پوسٹ بنیادی طور پر دوبارہ ترتیب دینے کے بارے میں ہے، سابقہ کو مطلع کرنے سے کسی کے پاس ورڈ کو صحیح مالک کے علم کے بغیر تبدیل کرنے کا خطرہ کم ہو جاتا ہے۔ یہ کیسے ہو سکتا ہے؟ ایک بہت عام منظر نامہ یہ ہے کہ صحیح مالک کا پاس ورڈ حاصل کیا جاتا ہے (دوبارہ استعمال شدہ پاس ورڈ کسی دوسرے ذریعہ سے لیک کیا گیا ہے، ایک کی لاگ پاس ورڈ، ایک اندازہ لگانے میں آسان پاس ورڈ، وغیرہ) اور پھر حملہ آور اسے تبدیل کرنے کا فیصلہ کرتا ہے، اس طرح مالک کو لاک آؤٹ کر دیتا ہے۔ . ای میل کی اطلاع کے بغیر، حقیقی مالک کو پاس ورڈ کی تبدیلی کے بارے میں علم نہیں ہوگا۔
بلاشبہ، پاس ورڈ دوبارہ ترتیب دینے کی صورت میں، مالک نے پہلے ہی یہ عمل خود شروع کر دیا ہو گا (یا اوپر بیان کردہ شناختی چیکرز کو نظرانداز کر دیں)، لہذا تبدیلی نہیں کرنا چاہئے اس کے لیے حیرت کا باعث ہو سکتا ہے، لیکن ای میل کی تصدیق مثبت رائے اور اضافی تصدیق ہو گی۔ یہ اوپر کے منظر نامے کے ساتھ مستقل مزاجی بھی فراہم کرتا ہے۔
اوہ، اور اگر یہ پہلے سے واضح نہیں تھا - میل کے ذریعے نیا پاس ورڈ نہ بھیجیں! اس سے کچھ لوگ ہنس سکتے ہیں، لیکن :
نوشتہ جات، نوشتہ جات، نوشتہ جات اور کچھ مزید نوشتہ جات
پاس ورڈ دوبارہ ترتیب دینے کا فنکشن حملہ آوروں کے لیے پرکشش ہے: حملہ آور یا تو کسی دوسرے شخص کے اکاؤنٹ تک رسائی حاصل کرنا چاہتا ہے، یا صرف اکاؤنٹ/سسٹم کے مالک کو تکلیف پہنچانا چاہتا ہے۔ اوپر بیان کیے گئے بہت سے طرز عمل بدسلوکی کے امکانات کو کم کرتے ہیں، لیکن اس کی روک تھام نہیں کرتے، اور یہ یقینی طور پر لوگوں کو اس خصوصیت کو غیر ارادی طریقوں سے استعمال کرنے کی کوشش کرنے سے نہیں روکیں گے۔
بدنیتی پر مبنی رویے کو پہچاننے کے لیے، لاگنگ ایک بالکل انمول عمل ہے، اور میرا مطلب ہے۔ بہت تفصیلی لاگنگ. لاگ ان کی ناکام کوششیں، پاس ورڈ ری سیٹ، پاس ورڈ کی تبدیلیاں (یعنی جب صارف پہلے سے لاگ ان ہو) اور تقریباً کوئی بھی ایسی چیز جو آپ کو یہ سمجھنے میں مدد دے سکتی ہے کہ کیا ہو رہا ہے۔ یہ مستقبل میں بہت مفید ہو گا. انفرادی طور پر بھی لاگ ان کریں۔ حصے عمل، مثال کے طور پر، ایک اچھی ری سیٹ کی خصوصیت میں ویب سائٹ کے ذریعے ری سیٹ شروع کرنا شامل ہونا چاہیے (ری سیٹ کی درخواست کو کیپچر کرنا اور غلط صارف نام یا ای میل کے ساتھ لاگ ان کی کوششیں)، ری سیٹ یو آر ایل پر ویب سائٹ کے وزٹ کیپچر کرنا (بشمول ایک غلط ٹوکن استعمال کرنے کی کوششیں)، اور پھر سیکیورٹی سوال کے جواب کی کامیابی یا ناکامی کو لاگ ان کریں۔
جب میں لاگنگ کے بارے میں بات کرتا ہوں تو میرا مطلب ہے کہ نہ صرف اس حقیقت کو ریکارڈ کرنا کہ ایک صفحہ لوڈ ہوا ہے، بلکہ زیادہ سے زیادہ معلومات جمع کرنا بھی، اگر یہ خفیہ نہیں ہے۔. لڑکوں، براہ کرم پاس ورڈ لاگ ان نہ کریں! نوشتہ جات کو مجاز صارف کی شناخت کو ریکارڈ کرنے کی ضرورت ہے (وہ مجاز ہو گا اگر وہ تبدیلیاں موجودہ پاس ورڈ یا دوبارہ ترتیب دینے کی کوشش کر رہا ہے۔ کسی اور کا پاس ورڈ لاگ ان کرنے کے بعد)، کوئی بھی صارف نام یا ای میل ایڈریس جس کی یہ کوشش کرتا ہے اور کوئی بھی ری سیٹ ٹوکن جس کی وہ کوشش کرتا ہے۔ لیکن یہ آئی پی ایڈریس جیسی چیزوں کو لاگ کرنے کے قابل بھی ہے اور اگر ممکن ہو تو ہیڈرز کی بھی درخواست کریں۔ یہ آپ کو نہ صرف دوبارہ تخلیق کرنے کی اجازت دیتا ہے۔ کہ صارف (یا حملہ آور) کرنے کی کوشش کر رہا ہے، بلکہ کون وہ ایسا ہے.
دیگر اداکاروں کو ذمہ داری سونپنا
اگر آپ کو لگتا ہے کہ یہ سب کام کی ایک بڑی مقدار کی نمائندگی کرتا ہے، تو آپ اکیلے نہیں ہیں۔ درحقیقت، ایک قابل اعتماد اکاؤنٹ مینجمنٹ سسٹم بنانا کوئی آسان کام نہیں ہے۔ ایسا نہیں ہے کہ یہ تکنیکی طور پر مشکل ہے، اس میں بہت ساری خصوصیات ہیں۔ یہ صرف ری سیٹ کرنے کے بارے میں نہیں ہے، رجسٹریشن کا ایک پورا عمل ہے، پاس ورڈز کو محفوظ طریقے سے اسٹور کرنا، لاگ ان کی متعدد ناکام کوششوں کو ہینڈل کرنا، وغیرہ۔ اگرچہ اس کے علاوہ اور بھی بہت کچھ کرنے کی ضرورت ہے۔
آج، بہت سے فریق ثالث فراہم کنندگان تمام تکلیفوں کو برداشت کرنے اور ان سب کو ایک منظم سروس میں خلاصہ کرنے میں خوش ہیں۔ ایسی خدمات میں OpenID، OAuth اور یہاں تک کہ فیس بک بھی شامل ہے۔ کچھ لوگ (اوپن آئی ڈی واقعی اسٹیک اوور فلو پر بہت کامیاب رہا ہے)، لیکن دیگر .
اس میں کوئی شک نہیں کہ اوپن آئی ڈی جیسی سروس ڈویلپرز کے لیے بہت سے مسائل کو حل کرتی ہے، لیکن یہ بلاشبہ نئی چیزیں بھی شامل کرتی ہے۔ کیا ان کا کوئی کردار ہے؟ ہاں، لیکن ظاہر ہے کہ ہم تصدیقی خدمات فراہم کرنے والوں کو بڑے پیمانے پر اپناتے ہوئے نہیں دیکھ رہے ہیں۔ بینک، ایئر لائنز، اور یہاں تک کہ سٹور سبھی اپنا توثیقی طریقہ کار نافذ کرتے ہیں، اور ظاہر ہے اس کی بہت اچھی وجوہات ہیں۔
بدنیتی پر مبنی ری سیٹ
اوپر دی گئی ہر ایک مثال کا ایک اہم پہلو یہ ہے کہ پرانے پاس ورڈ کو صرف بیکار سمجھا جاتا ہے۔ اکاؤنٹ کے مالک کی شناخت کی تصدیق کے بعد. یہ اہم ہے کیونکہ اگر اکاؤنٹ کو دوبارہ ترتیب دیا جا سکتا ہے۔ پر شناخت کی توثیق، یہ ہر طرح کی بدنیتی پر مبنی کارروائیوں کا موقع فراہم کرے گا۔
یہاں ایک مثال ہے: کوئی نیلامی کی سائٹ پر بولی لگا رہا ہے، اور بولی لگانے کے عمل کے اختتام کے قریب، وہ دوبارہ ترتیب دینے کا عمل شروع کر کے حریفوں کو بلاک کر دیتے ہیں، اس طرح وہ بولی لگانے سے خارج ہو جاتے ہیں۔ ظاہر ہے، اگر ناقص ڈیزائن کردہ ری سیٹ فنکشن کا غلط استعمال کیا جا سکتا ہے، تو یہ سنگین منفی نتائج کا باعث بن سکتا ہے۔ یہ بات قابل غور ہے کہ لاگ ان کی غلط کوششوں کی وجہ سے اکاؤنٹ کا لاک آؤٹ بھی ایسی ہی صورت حال ہے، لیکن یہ دوسری پوسٹ کے لیے موضوع ہے۔
جیسا کہ میں نے اوپر کہا، اگر آپ گمنام صارفین کو کسی بھی اکاؤنٹ کا پاس ورڈ صرف ان کے ای میل ایڈریس کو جان کر دوبارہ ترتیب دینے کی اہلیت دیتے ہیں، تو یہ سروس اٹیک سے انکار کے لیے ایک مناسب صورتحال ہے۔ یہ ایک نہیں ہو سکتا ، جس کے بارے میں ہم بات کرتے تھے، لیکن کسی اکاؤنٹ تک رسائی کو لاک کرنے کا اس سے زیادہ تیز طریقہ کوئی نہیں ہے کہ ناقص ڈیزائن کردہ پاس ورڈ ری سیٹ فیچر استعمال کریں۔
کمزور ترین لنک
کسی ایک اکاؤنٹ کی حفاظت کے نقطہ نظر سے، اوپر لکھی گئی ہر چیز بہت اچھی ہے، لیکن آپ کو ہمیشہ اس ماحولیاتی نظام کو ذہن میں رکھنے کی ضرورت ہے جو آپ جس اکاؤنٹ کی حفاظت کر رہے ہیں اس کے آس پاس ہے۔ میں آپ کو ایک مثال دیتا ہوں:
ASafaWeb کی میزبانی AppHarbor کی طرف سے فراہم کردہ ایک شاندار سروس پر کی گئی ہے۔ ہوسٹنگ اکاؤنٹ کو دوبارہ ترتیب دینے کا عمل اس طرح ہوتا ہے:
مرحلہ 1:
مرحلہ 2:
مرحلہ 3:
مرحلہ 4:
تمام پچھلی معلومات کو پڑھنے کے بعد، یہ سمجھنا پہلے سے ہی آسان ہے کہ ہم ایک مثالی دنیا میں کن پہلوؤں کو تھوڑا مختلف طریقے سے نافذ کریں گے۔ تاہم، میں یہاں جو کہہ رہا ہوں وہ یہ ہے کہ اگر میں ASafaWeb جیسی سائٹ کو AppHarbor پر شائع کرتا ہوں، اور پھر زبردست حفاظتی سوالات اور جوابات کے ساتھ آتا ہوں، ایک دوسرا تصدیقی عنصر شامل کرتا ہوں اور باقی سب کچھ قواعد کے مطابق کرتا ہوں، تو یہ تبدیل نہیں ہوتا ہے۔ حقیقت یہ ہے کہ اس سارے عمل میں سب سے کمزور کڑی اس سب کو توڑنے کے قابل ہو گی۔ اگر کوئی میری معلومات کا استعمال کرتے ہوئے AppHarbor میں کامیابی سے تصدیق کرتا ہے، تو وہ کسی بھی ASafaWeb اکاؤنٹ کا پاس ورڈ تبدیل کر سکے گا جس کی انہیں ضرورت ہے!
نکتہ یہ ہے کہ سیکیورٹی کے نفاذ کی طاقت کو مجموعی طور پر سمجھا جانا چاہئے: سسٹم میں ہر داخلے کے مقام کے خطرے کو ماڈل کرنے کی ضرورت ہے، چاہے یہ ایک سطحی عمل ہو، جیسے کہ AppHarbor سسٹم میں لاگ ان کرنا۔ اس سے مجھے اچھی طرح اندازہ ہو جائے گا کہ مجھے ASafaWeb پاس ورڈ دوبارہ ترتیب دینے کے عمل میں کتنی محنت کرنے کی ضرورت ہے۔
یہ سب ایک ساتھ ڈالنا
اس پوسٹ میں بہت ساری معلومات ہیں، اس لیے میں اسے ایک سادہ بصری خاکہ میں سمیٹنا چاہتا ہوں:
یاد رکھیں کہ آپ کو ان اشیاء میں سے ہر ایک کی سب سے زیادہ تفصیلی لاگنگ کرنی چاہیے۔ یہ ہے، یہ آسان ہے!
کے نتائج
میری پوسٹ جامع معلوم ہوتی ہے، تاہم اس میں بہت زیادہ اضافی مواد موجود ہے جو میں کر سکتا تھا شامل کریں لیکن اختصار کی خاطر نہ کرنے کا فیصلہ کیا: ریسکیو ای میل ایڈریس کا کردار، وہ صورتحال جس میں آپ اپنے اکاؤنٹ سے وابستہ ای میل تک رسائی کھو دیتے ہیں (مثال کے طور پر، آپ نے اپنا کام چھوڑ دیا)، وغیرہ۔ جیسا کہ میں نے پہلے کہا، ری سیٹ فنکشن اتنا پیچیدہ نہیں ہے، لیکن اسے دیکھنے کے بہت سے طریقے ہیں۔
اگرچہ ری سیٹ اتنا پیچیدہ نہیں ہے، یہ اکثر غلط طریقے سے لاگو ہوتا ہے۔ اوپر ہم نے ایک دو مثالیں دیکھی ہیں جہاں پر عمل درآمد ہوتا ہے۔ کر سکتے ہیں مسائل کا باعث بنتے ہیں، اور بہت سی مزید نظیریں ہیں جہاں ایک غلط ری سیٹ واقعی مسائل کی وجہ سے. حال ہی میں یہ پتہ چلا کہ . یہ ایک سنگین منفی نتیجہ ہے!
لہذا اپنے ری سیٹ افعال کے ساتھ محتاط رہیں، مختلف پوائنٹس پر، اور فنکشن ڈیزائن کرتے وقت، اپنی کالی ٹوپی نہ اتاریں، کیونکہ اس کا اچھا موقع ہے کہ کوئی اور اسے پہنائے!
ایڈورٹائزنگ کے حقوق پر
وی ڈی سینا سستی پیشکش کرتا ہے روزانہ کی ادائیگی کے ساتھ، ہر سرور 500 میگا بٹس کے انٹرنیٹ چینل سے منسلک ہے اور DDoS حملوں سے مفت میں محفوظ ہے!
ماخذ: www.habr.com