ڈیوائس کی گھڑی ہٹنے پر TOTP کوڈ کیوں ناکام ہوتے ہیں

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

یہاں دو گھڑیوں کا معاملہ اہم ہے، اور نظر آنے والی گھڑی درست کرنا وہ حصہ ہے جو لوگ پہلے کرتے ہیں۔ جو گھڑی عموماً توجہ مانگتی ہے وہ دوسری ہے۔

کوڈ وقت کا فعل ہے، پاس ورڈ نہیں

TOTP مشترکہ راز اور موجودہ وقت سے اخذ کردہ کاؤنٹر لیتا ہے، دونوں کو کلید والے ہیش سے گزارتا ہے اور نتیجے کو مختصر اعشاریہ تار میں کاٹ دیتا ہے، جیسا کہ RFC 6238 میں متعین ہے۔ کاؤنٹر ہر وقت کے مرحلے پر آگے بڑھتا ہے، عموماً تیس سیکنڈ، اس لیے مرحلہ بدلنے پر وہی راز نیا قدر پیدا کرتا ہے۔ تصدیق کرنے والا موجودہ مرحلے کی متوقع قدر دوبارہ شمار کر کے موازنہ کرتا ہے، جس کے لیے وہی راز اور ابھی کے بارے میں وہی تصور درکار ہے۔ پاس ورڈ تبدیل ہونے تک دوبارہ استعمال کے قابل رہتا ہے، جبکہ یہ قدر ایک ایسی حد پر ختم ہوتی ہے جو کلائنٹ نہیں دیکھ سکتا۔

اسی لیے ایک کوڈ چلتا ہے اور اگلا چند لمحوں بعد ناکام ہو جاتا ہے۔ یہ یہ بھی واضح کرتا ہے کہ چیٹ پیغام سے کوڈ نقل کرنا کیوں اتنی ناقابلِ اعتماد عادت ہے۔

دو گھڑیوں کو متفق ہونا چاہیے، ایک کو نہیں

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

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

ونڈو وسیع کرنے کی قیمت

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

گھڑی درست کرنا مرمت ہے، جبکہ ونڈو وسیع کرنا تسکین ہے۔ پہلا سبب ہٹاتا ہے اور دوسرا اسے چھپاتا ہے۔

دوبارہ کوشش سے پہلے دونوں گھڑیاں جانچیں

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

timedatectl
date -u +'%Y-%m-%dT%H:%M:%SZ'
chronyc tracking
timedatectl timesync-status

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

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