TrendVidStream ने अपने पूरे ऑथेंटिकेशन स्टैक (authentication stack) को एक रोटेटिंग-रिफ्रेश-टोकन (rotating-refresh-token) सिस्टम पर स्थानांतरित कर दिया है, जो चोरी किए गए टोकन का दोबारा उपयोग होते ही उसे तुरंत पकड़ लेता है। इस बदलाव ने 30-दिन के JWT को, जो कभी हमलावर को स्वतंत्र रूप से घूमने की अनुमति देता था, एक अल्पकालिक क्रेडेंशियल (short-lived credential) में बदल दिया है जो तुरंत लॉक-आउट ट्रिगर कर देता है।
एक एकल सुरक्षा उल्लंघन (breach) ने इस बदलाव को मजबूर किया: एक पार्टनर SDK ने 30-दिन के JWT को प्लेन टेक्स्ट में कैश (cache) कर लिया था, एक हमलावर ने इसे निकाला और दूसरे देश से इसे दोबारा इस्तेमाल (replay) किया, और एकमात्र उपाय साइनिंग की (signing key) को रोटेट करना था—एक ऐसा ऑपरेशन जिसने हर यूजर को लॉग आउट कर दिया। इस घटना ने कंपनी की टोकन सुरक्षा को नया रूप दिया और अब यही वीडियो-स्ट्रीमिंग सेवा को शक्ति प्रदान करता है।
पुराना मॉडल क्यों विफल रहा
JWTs (JSON Web Tokens) सेल्फ-कंटेन्ड (self-contained), साइन किए हुए ब्लॉब्स (signed blobs) होते हैं जो सर्वर को डेटाबेस लुकअप के बिना अनुरोध को सत्यापित करने की अनुमति देते हैं। यह सुविधा एक कीमत छिपाती है: यदि कोई टोकन हफ्तों तक वैध रहता है, तो उसे चुराने से हमलावर को हफ्तों तक एक्सेस मिल जाता है। उल्लंघन के दौरान, चोरी किया गया टोकन अपनी 30-दिन की समाप्ति तक वैध रहा क्योंकि उसे समय से पहले अमान्य (invalidate) करने का कोई तरीका नहीं था।
साइनिंग की (signing key) को रोटेट करना सभी टोकन को अमान्य करने का एकमात्र वैश्विक तरीका है, लेकिन यह हर यूजर को फिर से लॉग इन करने के लिए मजबूर करता है, जिससे सेवा बाधित होती है और विश्वास कम होता है। खामी JWT में नहीं थी, बल्कि एक एकल, लंबे समय तक चलने वाले क्रेडेंशियल पर निर्भर रहने में थी।
नए डिज़ाइन का संक्षिप्त विवरण
TrendVidStream अब दो प्रकार के टोकन जारी करता है:
- Access tokens – 15 मिनट के लिए वैध; वे प्रत्येक API कॉल के लिए आवश्यक अनुमतियाँ (permissions) ले जाते हैं।
- Refresh tokens – सिंगल-यूज़ टोकन जो एक अल्पकालिक एक्सेस टोकन के बदले नए जोड़े (pair) का आदान-प्रदान करते हैं।
जब कोई क्लाइंट रिफ्रेश टोकन प्रस्तुत करता है, तो सर्वर:
- टोकन के सिग्नेचर और क्लेम्स (claims) को सत्यापित करता है।
- जाँचता है कि क्या टोकन का पहले ही उपयोग किया जा चुका है।
- यदि जाँच सफल होती है, तो एक बिल्कुल नया रिफ्रेश टोकन और एक नया 15-मिनट का एक्सेस टोकन जारी करता है।
- पुराने रिफ्रेश टोकन को 'इस्तेमाल किया गया' (used) के रूप में चिह्नित करता है।
यदि चरण 2 विफल हो जाता है—यानी वही टोकन दूसरी बार दिखाई देता है—तो सर्वर इसे चोरी के संकेत के रूप में मानता है और उस लॉगिन सत्र से जुड़े टोकन के पूरे "परिवार" (family) को रद्द (revoke) कर देता है। पीड़ित और हमलावर दोनों को फिर से लॉग इन करने के लिए मजबूर किया जाता है, जिससे उल्लंघन का समय कम हो जाता है।
टोकन परिवारों (token families) को ट्रैक करना
प्रत्येक टोकन को एक अलग रिकॉर्ड मानने के बजाय, सिस्टम उन्हें परिवारों में समूहित करता है जो यूजर के लॉग इन करने पर शुरू होते हैं। प्रत्येक रोटेशन उस परिवार का एक नया सदस्य बनाता है। प्रोडक्शन में उपयोग किया जाने वाला SQLite स्कीमा इन्हें स्टोर करता है:
- family_id – पूरे सत्र के लिए एक स्थिर पहचानकर्ता (stable identifier)।
- token_id – प्रत्येक रिफ्रेश टोकन के लिए एक अद्वितीय पहचानकर्ता (unique identifier)।
- generation – डिबगिंग के लिए उपयोगी एक काउंटर।
- used_at – टोकन को रिडीम (redeem) किए जाने का टाइमस्टैम्प।
- revoked – एक फ्लैग जो सेट होने पर पूरे परिवार को अक्षम (disable) कर देता है।
जब दोबारा उपयोग (reuse) की घटना का पता चलता है, तो उस family_id के लिए revoked फ्लैग सेट कर दिया जाता है, जिससे समझौता किए गए सत्र (compromised session) से संबंधित प्रत्येक टोकन तुरंत अमान्य हो जाता है। यह एक शांत हैकिंग (silent hijack) को एक हाई-सिग्नल अलर्ट में बदल देता है जो लॉग्स में दिखाई देता है।
सिस्टम को विश्वसनीय बनाए रखने के लिए कार्यान्वयन के तीन नियम
पहले सिग्नेचर को सत्यापित करें यदि सर्वर सिग्नेचर सत्यापित करने से पहले "क्या पहले उपयोग किया गया?" (used-before?) की जाँच करता है, तो एक हमलावर टोकन आईडी का अनुमान लगा सकता है और बड़े पैमाने पर रद्दीकरण (mass revocations) शुरू कर सकता है। पहले प्रामाणिकता की पुष्टि करने से अनावश्यक डिनायल-ऑफ-सर्विस (denial-of-service) हमलों को रोका जा सकता है।
ग्रेस विंडो (grace window) की अनुमति दें जब टोकन समाप्त होता है, तो मोबाइल ऐप्स अक्सर बहुत कम समय के अंतराल में दो रिफ्रेश अनुरोध भेजते हैं। यदि सर्वर बहुत सख्त है, तो दूसरे अनुरोध को दोबारा उपयोग के रूप में चिह्नित किया जाएगा, जिससे एक वैध यूजर लॉग आउट हो जाएगा। कुछ सेकंड का बफर "इस्तेमाल किए गए" टोकन को भी एक नया जोड़ा वापस करने की अनुमति देता है, जिससे रेस कंडीशंस (race conditions) सुचारू हो जाती हैं।
पूरे फ्लो को रो-लॉकिंग (row locking) के साथ एक ट्रांजेक्शन में लपेटें एटॉमिकिटी (atomicity) के बिना, दो समवर्ती (concurrent) अनुरोध दोनों यह सोच सकते हैं कि वे टोकन का उपयोग करने वाले पहले व्यक्ति हैं, जिससे डुप्लिकेट रिफ्रेश टोकन जारी हो सकते हैं और सिंगल-यूज़ गारंटी टूट सकती है। एक डेटाबेस ट्रांजेक्शन जो टोकन रो (row) को लॉक करता है, यह गारंटी देता है कि केवल एक ही अनुरोध सफल हो।
निष्कर्ष (Takeaway): रिफ्रेश टोकन को सिंगल-यूज़ बनाकर और दोबारा उपयोग पर नज़र रखकर, एक सिस्टम हर चोरी किए गए क्रेडेंशियल को एक अलार्म में बदल सकता है, जिससे पूरे प्लेटफॉर्म पर लॉगआउट किए बिना उपयोगकर्ताओं की सुरक्षा की जा सकती है।