یونکس ٹائم سٹیمپس سیکیورٹی اور تصدیق میں — ٹوکن میعاد، سیشن، اور ریٹ لمیٹنگ

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

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

مخصوص ٹائم سٹیمپ کی اقدار دیکھنے اور انہیں انسانی پڑھنے کی شکل میں تبدیل کرنے کے لیے یونکس ٹائم سٹیمپ کنورٹر استعمال کریں۔

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

یونکس ٹائم سٹیمپ ایک عدد صحیح ہے جو 1 جنوری 1970 UTC کے بعد سے گزرے ہوئے سیکنڈز کی نمائندگی کرتا ہے۔ اس سادہ نمائندگی کی کئی سیکیورٹی سے متعلقہ خصوصیات ہیں:

ٹائم زون سے آزاد۔ 1720000000 کا ٹائم سٹیمپ زمین پر ہر جگہ ایک ہی لمحے کو ظاہر کرتا ہے، چاہے مقامی ٹائم زون کوئی بھی ہو۔ "2024-07-03 14:00:00" جیسی ترتیب شدہ تاریخ و وقت کی سطر مبہم ہے — 14:00 کس ٹائم زون میں؟ یونکس ٹائم سٹیمپس یہ ابہام مکمل طور پر ختم کر دیتے ہیں۔ سیکیورٹی چیکیں جو مختلف ٹائم زونز میں سسٹمز کے پار ٹائم سٹیمپس کا موازنہ کرتی ہیں ٹائم زون کی تشریح میں فرق کی وجہ سے نہیں ہٹ سکتیں۔

آسان حساب۔ یہ چیک کرنا کہ وہ ٹوکن جو وقت iat پر جاری ہوا ہے 1 گھنٹے کی کھڑکی میں ختم ہو گیا ہے: current_timestamp > iat + 3600۔ کوئی کیلنڈر کی ریاضی نہیں، کوئی تاریخ و وقت کی تجزیہ نہیں، کوئی گرمی کی بچت کی تبدیلی نہیں۔ حساب بالکل درست اور تیز ہے۔

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

JWT ٹوکن میعاد: iat، exp، اور nbf دعویٰ

JSON Web Tokens (JWT) وقت سے متعلقہ دعویوں کے لیے یونکس ٹائم سٹیمپس استعمال کرتے ہیں:

• iat (جاری کرنے کا وقت): وہ یونکس ٹائم سٹیمپ جب ٹوکن بنایا گیا۔ ٹوکن کی عمر کو ناپنے اور بہت ماضی میں بنائے گئے ٹوکنز کو شناخت دینے میں استعمال ہوتا ہے۔
• exp (میعاد پوری ہونے کا وقت): وہ یونکس ٹائم سٹیمپ جس کے بعد ٹوکن کو قبول نہیں کیا جانا چاہیے۔ تصدیق دینے والا سرور current_time > exp چیک کرتا ہے — اگر سچ ہے تو ٹوکن ختم ہو گیا ہے اور مسترد کر دیا جاتا ہے۔
• nbf (پہلے نہیں): وہ یونکس ٹائم سٹیمپ جس سے پہلے ٹوکن کو قبول نہیں کیا جانا چاہیے۔ کم عام استعمال ہے، لیکن ان ٹوکنز کے لیے مفید ہے جو پہلے سے بنائے جاتے ہیں اور صرف مخصوص مستقبل کے وقت میں درست ہو جاتے ہیں۔

ایک معمول کا JWT پے لوڈ اس طرح لگتا ہے:

{
  "sub": "user_12345",
  "iat": 1720000000,
  "exp": 1720086400,
  "nbf": 1720000000
}

اس مثال میں، exp - iat = 86400، یعنی ٹوکن بالکل 24 گھنٹوں کے لیے درست ہے (86,400 سیکنڈز)۔

عام غلطی: میعاد کو ملی سیکنڈز میں سیٹ کرنا۔ کیونکہ جاوا اسکرپٹ کا Date.now() ملی سیکنڈز واپس کرتا ہے، ڈویلپرز کبھی کبھی exp کو Date.now() + 86400000 کے طور پر شمار کرتے ہیں (ملی سیکنڈ کو ملی سیکنڈ ٹائم سٹیمپ میں شامل کرتے ہیں)۔ اگر JWT لائبریری سیکنڈز کی توقع کرتی ہے، تو یہ 24 گھنٹے کی بجائے 1,000 سالوں میں میعاد ختم ہونے والا ٹوکن بناتا ہے۔ جاوا اسکرپٹ میں کام کرتے وقت ہمیشہ 1,000 سے تقسیم کریں: Math.floor(Date.now() / 1000) + 86400۔

JWT کی میعاد کا ٹائم سٹیمپ دیکھنے کے لیے: base64 پے لوڈ کو ڈی کوڈ کریں اور exp دیکھیں۔ ٹائم سٹیمپ کو یونکس ٹائم سٹیمپ کنورٹر میں ڈالیں انسانی پڑھنے کی شکل میں میعاد کا وقت دیکھنے کے لیے۔

سیشن ٹائم آؤٹ اور سلائیڈنگ کھڑکیاں

ویب ایپلیکیشن سیشنز دو قسم کے ٹائم آؤٹ لاگو کرنے کے لیے ٹائم سٹیمپس استعمال کرتے ہیں:

مطلق ٹائم آؤٹ: سیشن بنانے کے بعد ایک طے شدہ وقت میں ختم ہو جاتا ہے، سرگرمی سے قطع نظر۔ نافذ کرنا: سیشن بناتے وقت created_at یونکس ٹائم سٹیمپ محفوظ کریں۔ ہر درخواست پر، current_time - created_at > max_session_seconds چیک کریں۔ اگر سچ ہے، سیشن کو غلط قرار دیں اور دوبارہ لاگ ان کا مطالبہ کریں۔

سلائیڈنگ ٹائم آؤٹ (غیر فعال ٹائم آؤٹ): سیشن غیر فعالیت کے ایک دور کے بعد ختم ہو جاتا ہے۔ ہر درخواست کھڑکی کو بڑھاتی ہے۔ نافذ کرنا: last_active یونکس ٹائم سٹیمپ محفوظ کریں، ہر درخواست پر اپ ڈیٹ کیا جاتا ہے۔ current_time - last_active > idle_timeout_seconds چیک کریں۔ اگر سچ ہے، سیشن بہت لمبے عرصے سے غیر فعال ہے اور ختم ہو گیا ہے۔

زیادہ تر ایپلیکیشنز کو دونوں کی ضرورت ہے: سہولت کے لیے سلائیڈنگ کھڑکی (فعال استعمال کے دوران لاگ آؤٹ نہیں) اور ایک مطلق زیادہ سے زیادہ (کوئی سیشن مسلسل سرگرمی کے ساتھ بھی ہمیشہ درست نہیں رہتا)۔ ایک معمول کا امتزاج: 30 منٹ غیر فعال ٹائم آؤٹ، 8 گھنٹے مطلق زیادہ سے زیادہ۔

نافذ کرنا: `python if current_time - session["last_active"] > 1800: # 30 منٹ غیر فعال invalidate_session() if current_time - session["created_at"] > 28800: # 8 گھنٹے مطلق invalidate_session() session["last_active"] = current_time `

ریٹ لمیٹنگ کھڑکیاں

ریٹ لمیٹنگ عام طور پر سیکنڈ میں ناپی جانے والی مقررہ وقت کی کھڑکیوں میں کام کرتی ہے۔ عام نفاذ:

مقررہ کھڑکی: ہر کھڑکی میں N درخواستوں کی اجازت دیں۔ ایک کھڑکی ایک دور ہے جیسے "فی منٹ" یا "فی گھنٹہ"، ایک یونکس ٹائم سٹیمپ رینج کے طور پر بیان کی گئی۔ موجودہ منٹ کے لیے کھڑکی floor(current_time / 60) * 60 سے وہ قدر جمع 60 ہے۔ جب درخواست آتی ہے، موجودہ کھڑکی ٹائم سٹیمپ پر کلیدی شمار کو بڑھائیں۔ اگر شمار > N، مسترد کریں۔

سلائیڈنگ کھڑکی: مقررہ کھڑکی سے زیادہ درست۔ آخری N سیکنڈز میں ہر درخواست کے ٹائم سٹیمپ کو ٹریک کریں۔ ہر نئی درخواست پر، current_time - window_seconds سے current_time تک کتنے محفوظ ٹائم سٹیمپز آتے ہیں شمار کریں۔ اگر شمار >= حد، مسترد کریں؛ ورنہ نیا ٹائم سٹیمپ ریکارڈ کریں۔

سلائیڈنگ کھڑکی مقررہ کھڑکیوں کے ساتھ حد کے مسئلے کو روکتی ہے (ایک صارف 11:59 میں N درخواستیں اور 12:00 میں N درخواستیں بنا سکتا تھا، دو متتالی منٹوں میں 2N درخواستیں حاصل کرتا تھا)۔

متعدد سرورز والے تقسیم شدہ سسٹمز کے لیے، ریٹ لمیٹنگ کو مشترک ذخیرے کی ضرورت ہے (Redis عام ہے)۔ شمار یا ٹائم سٹیمپ کی فہرست کو TTL کے ساتھ محفوظ کیا جاتا ہے جو کھڑکی سے ملتا ہے، تو یہ خود ختم ہو جاتا ہے۔ کلید عام طور پر ratelimit:{user_id}:{window_start_timestamp} ہے۔

ری پلے حملوں سے بچاؤ ٹائم سٹیمپس کے ساتھ

ری پلے حملہ یہ ہے جب حملہ آور ایک درست درخواست کو روکتا ہے اور اسے دوبارہ بھیجتا ہے اسی کام کو دوبارہ واقع کرانے کے لیے۔ ٹائم سٹیمپس اسے مشکل بنانے کے لیے استعمال ہوتے ہیں۔

ٹائم سٹیمپ پر مبنی nonce: درخواست میں موجودہ یونکس ٹائم سٹیمپ شامل کریں۔ وصول کنندہ سرور چیک کرتا ہے کہ ٹائم سٹیمپ قابل قبول کھڑکی میں ہے (مثال کے طور پر، سرور کے موجودہ وقت سے ±5 منٹ)۔ اس کھڑکی کے باہر ٹائم سٹیمپ والی درخواستیں مسترد کی جاتی ہیں، یہاں تک کہ اگر دستخط درست ہو۔ یہ ری پلے کھڑکی کو 5 منٹ تک محدود کرتا ہے — بالکل نہیں، لیکن یہ لامحدود ری پلے حملوں کو روکتا ہے۔

حد یہ ہے: 5 منٹ کی کھڑکی کچھ ری پلے کی اجازت دیتی ہے۔ ری پلے کو بالکل ختم کرنے کے لیے، آپ کو یہ بھی محفوظ کرنا اور چیک کرنا چاہیے کہ مخصوص ٹائم سٹیمپ + nonce کا امتزاج پہلے استعمال نہیں ہوا ہے (عام طور پر ایک مختصر مدتی کیش میں TTL کے برابر ری پلے کھڑکی)۔

TOTP (وقت پر مبنی ایک بار کے پاس ورڈ): Google Authenticator جیسی ایپلیکیشنز وقت پر مبنی کوڈز بنانے کے لیے یونکس ٹائم سٹیمپس استعمال کرتی ہیں۔ موجودہ 30 سیکنڈ کی کھڑکی (floor(current_time / 30)) ایک مشترکہ خفیہ کے ساتھ HMAC فنکشن میں داخل کے طور پر استعمال ہوتی ہے۔ کوڈ ہر 30 سیکنڈ میں بدلتا ہے، اس کھڑکی کے باہر ری پلے حملوں کو ناممکن بناتا ہے۔

کلاک Skew اور وقت کی ہم آہنگی

یونکس ٹائم سٹیمپ پر مبنی سیکیورٹی صرف اس صورت میں کام کرتی ہے اگر کلاکس ہم آہنگ ہوں۔ اگر کلائنٹ کلاک سرور سے 10 منٹ آگے ہے، کلائنٹ ایک JWT exp بناتا ہے جو سرور سوچتا ہے کہ پہلے سے ہی مستقبل میں ہے — یا nbf والا ٹوکن جو کلائنٹ پر ابھی درست نہیں ہوا۔

عملی طور پر:

• سرورز کو NTP (Network Time Protocol) استعمال کرنا چاہیے کلاکس کو ملی سیکنڈ میں ہم آہنگ رکھنے کے لیے
• JWT تصدیق دینے والوں کو exp اور nbf چیک کرتے وقت چھوٹی کلاک skew رواداری کی اجازت دینی چاہیے (1–5 منٹ)
• سیکیورٹی فیصلوں کے لیے کلائنٹ سے بھیجے گئے ٹائم سٹیمپس پر بھروسہ نہ کریں — iat، exp، اور آڈٹ ریکارڈز کے لیے ہمیشہ سرور کے ٹائم سٹیمپس استعمال کریں

یونکس ٹائم سٹیمپ کنورٹر موجودہ ٹائم سٹیمپ دکھاتا ہے جیسا کہ آپ کے براؤزر کے لحاظ سے ہے۔ اگر آپ مطابقت میں خرابی کو ٹھیک کر رہے ہیں، اسے date +%s سے موازنہ کریں سرور پر کلاک drift کی جانچ کے لیے۔

HMAC دستخطات اور ٹائم سٹیمپ کے ساتھ کلیدی درخواستیں

بہت سے webhook سسٹمز اور API تصدیق کی اسکیمز (AWS Signature Version 4، Stripe webhook تصدیق، Shopify webhooks) موجودہ ٹائم سٹیمپ کو دستخط شدہ مواد میں شامل کرتے ہیں۔ دستخط پے لوڈ اور ٹائم سٹیمپ دونوں کو احاطہ کرتا ہے، اور وصول کنندہ تصدیق دیتا ہے کہ:

1. دستخط ملتا ہے (پے لوڈ + ٹائم سٹیمپ میں کوئی تبدیلی نہیں ہوئی) 2. ٹائم سٹیمپ قابل قبول کھڑکی میں ہے (درخواست نہ تو پرانی ہے نہ ری پلے)

AWS SigV4 یونکس ٹائم سٹیمپ کی بجائے تاریخ کی شکل استعمال کرتا ہے (YYYYMMDDTHHMMSSZ)، لیکن بنیادی منطق ایک جیسی ہے — وقت وہ ہے جو دستخط شدہ ہے، اور وصول کنندہ ٹائم سٹیمپ والی درخواستوں کو مسترد کرتا ہے جو 15 منٹ کی کھڑکی سے باہر ہیں۔

webhook دستخط کی خرابیوں میں خرابی تلاش کرتے وقت، ایک عام وجہ پرانا ٹائم سٹیمپ ہے — webhook بھیجنے والے کلاک کی غلطی ہے، یا ڈیلیوری میں اہم تاخیر ہے (پیغام کے قوائم، دوبارہ کوشش) جو ٹائم سٹیمپ کو قابل قبول کھڑکی سے باہر دھکیلتی ہے۔

ٹائم سٹیمپ سے متعلقہ Auth خرابیوں میں خرابی تلاش

ٹائم سٹیمپس سے متعلقہ سب سے عام auth خرابیاں:

1. ٹوکن ختم ہو گیا: JWT کو ڈی کوڈ کرکے exp چیک کریں اور exp کو تاریخ میں تبدیل کریں۔ یونکس ٹائم سٹیمپ کنورٹر یہ ایک مرتبہ میں کرتا ہے۔ 2. ٹوکن ابھی درست نہیں ہوا: nbf مستقبل میں ہے۔ چیک کریں کہ ٹوکن کیا مستقبل کے شروعات کے وقت کے ساتھ بنایا گیا تھا۔ 3. کلاک skew: سرور اور کلائنٹ کلاکز رواداری کی کھڑکی سے زیادہ غیر ہم آہنگ ہیں۔ دونوں کلاکز کو حوالہ کے خلاف چیک کریں۔ 4. ملی سیکنڈز بمقابلہ سیکنڈز: 10 ہندسوں والے ٹائم سٹیمپ کی توقع والی جگہ 13 ہندسوں والا ٹائم سٹیمپ، یا اس کے برعکس۔ exp: 1720086400000 (ملی سیکنڈز) والا ٹوکن کبھی ختم نہیں ہوگا — یہ 56,000 سالوں میں ایک تاریخ کی نمائندگی کرتا ہے۔ 5. لاگنگ میں ٹائم زون کی الجھن: لاگ اندراجات ایک ٹائم سٹیمپ دکھاتے ہیں جو غلط لگتا ہے کیونکہ لاگز مقامی وقت استعمال کرتے ہیں لیکن ٹائم سٹیمپ کا موازنہ UTC استعمال کرتا ہے۔ یونکس ٹائم سٹیمپس ہمیشہ UTC ہیں؛ جب دکھاتے ہیں تو انہیں صراحت سے فارمیٹ کریں۔