क्या होगा अगर JWT चोरी हो जाए?

201

मैं अपने RESTful API के लिए JWT के साथ स्टेटलेस प्रमाणीकरण को लागू करने की कोशिश कर रहा हूं।

AFAIK, JWT मूल रूप से एक एन्क्रिप्टेड स्ट्रिंग है जो REST कॉल के दौरान HTTP हेडर के रूप में पास की जाती है।

लेकिन क्या होगा अगर कोई एग्ज़ॉडर हो जो अनुरोध देखता है और टोकन चुराता है ? फिर वह मेरी पहचान के साथ नकली अनुरोध करने में सक्षम होगा?

दरअसल, यह चिंता सभी टोकन-आधारित प्रमाणीकरण पर लागू होती है ।

इसे कैसे रोका जाए? HTTPS जैसा सुरक्षित चैनल?

authentication access-token jwt

— smwikipedia
स्रोत

1

यही कारण है कि टोकन अक्सर थोड़े समय के लिए ही मान्य होते हैं। और हां, आपको अपने डेटा की गोपनीयता के बारे में चिंतित होने पर HTTPS का उपयोग करना चाहिए।

— जोनाथन रीनहार्ट

4

@JonathonReinhart लेकिन अगर एक टोकन जल्द ही समाप्त हो जाता है, तो मेरे ग्राहक को समय-समय पर खुद को फिर से प्रमाणित करके एक नया टोकन प्राप्त करना होगा। क्या यह थकाऊ नहीं है?

— smwikipedia

@JonathonReinhart मुझे लगता है कि मुझे इस बात की जानकारी है कि टोकन अल्पकालिक क्यों है। क्योंकि इस तरह, सर्वर को टोकन की समाप्ति का ट्रैक रखने की आवश्यकता नहीं होती है और इस प्रकार स्केलेबिलिटी के लिए रास्ता बनाते हैं। यह एक तरह का trade-offके बीच having finer control of token expirationऔर having better scalability।

— smwikipedia

2

क्या यह भी मदद कर सकता है? - "टोकन चोरी का पता लगाने के लिए एक सामान्य सुरक्षा तंत्र अनुरोध आईपी पते की उत्पत्ति पर नज़र रखना है।" - यहाँ अंतिम खंड में विस्तार से वर्णन किया गया है - firebase.google.com/docs/auth/admin/manage-session

— Ula

3

सैद्धांतिक रूप से, टोकन चोरी को रोकना असंभव है। सबसे अच्छा हम यह पता लगा सकते हैं कि ऐसा हुआ है और फिर ASAP सत्र को रद्द कर दें। पता लगाने के लिए सबसे अच्छी विधि घूर्णन ताज़ा टोकन का उपयोग करना है (जैसा कि आरएफसी 6819 द्वारा सुझाया गया है)। यहाँ एक ब्लॉग है जो इसे विस्तार से बताता है: supertokens.io/blog/…

— ऋषभ पोद्दार

284

मैं एक नोड लाइब्रेरी का लेखक हूं, जो काफी गहराई, एक्सप्रेस-स्टापपैथ में प्रमाणीकरण को संभालता है , इसलिए मैं यहां कुछ जानकारी के साथ झंकार करूंगा।

सबसे पहले, JWTs को आम तौर पर एन्क्रिप्ट नहीं किया जाता है। जबकि JWTs को एन्क्रिप्ट करने का एक तरीका है (देखें: JWEs ), यह कई कारणों से बहुत आम नहीं है।

अगला, प्रमाणीकरण का कोई भी रूप (JWTs या नहीं का उपयोग करके), MitM हमलों (मानव-मध्य-मध्य हमलों) के अधीन है। जब आप इंटरनेट पर अनुरोध करते हैं तो ये हमले तब होते हैं जब कोई हमलावर आपका नेटवर्क देख सकता है। यह वही है जो आपका आईएसपी देख सकता है, एनएसए, आदि।

यह वही है जो SSL को रोकने में मदद करता है: अपने कंप्यूटर से अपने नेटवर्क ट्रैफ़िक को एन्क्रिप्ट करके -> प्रमाणीकरण करते समय कुछ सर्वर, आपके नेटवर्क ट्रैफ़िक की निगरानी करने वाला एक तृतीय पक्ष आपके टोकन, पासवर्ड या ऐसा कुछ भी नहीं देख सकता जब तक कि वे किसी तरह सक्षम न हों। सर्वर की निजी एसएसएल कुंजी (अप्रभावित) की एक प्रति प्राप्त करने के लिए। यही कारण है कि SSL प्रमाणीकरण के सभी रूपों के लिए MANDATORY है।

हालांकि, मान लें कि कोई व्यक्ति आपके एसएसएल का शोषण करने में सक्षम है और आपके टोकन को देखने में सक्षम है: आपके प्रश्न का उत्तर यह है कि हां , हमलावर उस टोकन का उपयोग करने में सक्षम होगा जो आपको लागू करने के लिए और आपके सर्वर से अनुरोध करने के लिए।

अब, यह वह जगह है जहां प्रोटोकॉल आते हैं।

JWTs एक प्रमाणीकरण टोकन के लिए सिर्फ एक मानक हैं। वे बहुत ज्यादा कुछ के लिए इस्तेमाल किया जा सकता है। JWTs शांत होने का कारण यह है कि आप उनमें अतिरिक्त जानकारी एम्बेड कर सकते हैं, और आप यह सत्यापित कर सकते हैं कि किसी ने इसके साथ कोई गड़बड़ नहीं की है (हस्ताक्षर)।

फिर भी, JWTs का 'सुरक्षा' से कोई लेना-देना नहीं है। सभी इरादों और उद्देश्यों के लिए, JWTs कमोबेश एक ही चीज हैं API कुंजियाँ: बस रैंडम स्ट्रिंग्स जो आप कुछ सर्वर के खिलाफ प्रमाणित करने के लिए उपयोग करते हैं।

आपके प्रश्न को और अधिक रोचक बनाता है प्रोटोकॉल का उपयोग किया जा रहा है (सबसे अधिक संभावना OAuth2)।

OAuth2 के काम करने का तरीका यह है कि यह ग्राहकों को केवल समय के एक छोटे पैमाने के लिए प्रमाणीकरण के लिए (JWTs की तरह!) टोकन देने के लिए डिज़ाइन किया गया था।

विचार यह है कि यदि आपका टोकन चोरी हो जाता है, तो हमलावर केवल थोड़े समय के लिए इसका उपयोग कर सकता है।

OAuth2 के साथ, आपको अपने उपयोगकर्ता नाम / पासवर्ड या एपीआई क्रेडेंशियल्स की आपूर्ति करके और फिर बदले में एक टोकन प्राप्त करके सर्वर के साथ हर बार खुद को फिर से प्रमाणित करना होगा।

क्योंकि यह प्रक्रिया हर अब और तब होती है, आपके टोकन अक्सर बदलते रहेंगे, जिससे हमलावरों के लिए आपको लगातार परेशानी से गुजरना मुश्किल हो सकता है।

उम्मीद है कि यह ^ ^ मदद करता है

— rdegges
स्रोत

3

निम्नलिखित लेख के लेखक का तर्क है कि JWT का एक नुकसान यह है कि चुराए गए JWT से उबरने का एकमात्र तरीका एक नया की-पेयर बनाना है और सभी उपयोगकर्ताओं को प्रभावी रूप से लॉग आउट करना है। जबकि एक DB में संग्रहीत सत्र-आईडी के साथ वेबसाइट केवल प्रभावित उपयोगकर्ता के सत्र को हटा सकती है और उसे सभी उपकरणों से लॉग आउट कर सकती है। मुझे यकीन नहीं है कि OAuth2 यहां तस्वीर में कैसे फिट बैठता है या क्या यह प्रस्तुत नुकसान को कम करने में मदद करता है। medium.com/@rahulgolwalkar/…

— मार्सेल

5

लेखक गलत है। अलग-अलग डिज़ाइन पैटर्न हैं जिनका उपयोग आप टोकन अमान्य करने के लिए कर सकते हैं। लेकिन सामान्य तौर पर: किसी भी प्रकार के प्रमाणीकरण उद्देश्य के लिए JWT का उपयोग करना एक बुरा विचार है। क्रिप्टोग्राफिक रूप से हस्ताक्षरित अंदर सत्र सत्र विचार के साथ सत्र कुकी का उपयोग करना कहीं अधिक कुशल है।

— १

1

@rdegges कृपया बताएं कि प्रमाणीकरण के लिए JWT कैसे बुरा विचार है? और कैसे मैं सत्र कुकी का उपयोग कर सकता हूं जो आपने ऊपर टिप्पणी में उल्लिखित किया है?

— नोमान तुफैल

6

यह एकल प्रतिक्रिया में टाइप करने के लिए बहुत लंबा है। यदि आप अधिक सीखना चाहते हैं, तो मैंने इस विषय पर एक विस्तृत बात की है। आप मेरी स्लाइड ऑनलाइन देख सकते हैं: स्पीकरडेक.com

— rdegges

2

सैद्धांतिक रूप से, टोकन चोरी को रोकना असंभव है। सबसे अच्छा हम यह पता लगा सकते हैं कि ऐसा हुआ है और फिर ASAP सत्र को रद्द कर दें। पता लगाने के लिए सबसे अच्छी विधि घूर्णन ताज़ा टोकन का उपयोग करना है (जैसा कि आरएफसी 6819 द्वारा सुझाया गया है)। यहाँ एक ब्लॉग है जो इसे विस्तार से बताता है: supertokens.io/blog/…

— ऋषभ पोद्दार

31

मुझे पता है कि यह एक पुराना सवाल है, लेकिन मुझे लगता है कि मैं अपना $ 0.50 यहां छोड़ सकता हूं, शायद कोई सुधार कर सकता है या अपने दृष्टिकोण को पूरी तरह से अस्वीकार करने के लिए एक तर्क प्रदान कर सकता है। मैं JWTs का HTTPS (inc) पर एक RESTful API में उपयोग कर रहा हूं।

इस काम के लिए, आपको हमेशा अल्पकालिक टोकन जारी करना चाहिए (ज्यादातर मामलों पर निर्भर करता है, मेरे ऐप में मैं वास्तव में exp30 मिनट और ttl3 दिनों के लिए दावा सेट कर रहा हूं , इसलिए आप इस टोकन को तब तक ताज़ा कर सकते हैं जब तक कि ttlयह अभी भी है मान्य और टोकन को ब्लैकलिस्ट नहीं किया गया है )

के लिए authentication service, रद्द टोकन करने के लिए, मैं एक में मेमोरी कैश परत (का उपयोग करना चाहते redis एक के रूप में मेरे मामले में) JWT blacklist/ ban-list(मैं यह RESTful दर्शन टूट जाता है पता है, लेकिन संग्रहीत दस्तावेज़ों हैं: सामने, कुछ criterias पर निर्भर करता है वास्तव में अल्पकालिक, जैसा कि मैंने उनके शेष समय के लिए ttlब्लैक लिस्ट किया - दावा-)

नोट: ब्लैकलिस्ट किए गए टोकन को स्वचालित रूप से ताज़ा नहीं किया जा सकता है

तो user.passwordया user.email(पासवर्ड पुष्टि की आवश्यकता है), प्रमाणन सेवा एक ताजा टोकन और अमान्य कर देता है (ब्लैकलिस्ट) पिछले एक (रों) रिटर्न अद्यतन किया गया है, तो अपने ग्राहक पता लगाता है कि उपयोगकर्ता की पहचान किसी भी तरह समझौता किया गया है, आप उस उपयोगकर्ता अपने पासवर्ड बदलने के लिए पूछ सकते हैं, तो । यदि आप इसके लिए ब्लैकलिस्ट का उपयोग नहीं करना चाहते हैं, तो आप फ़ील्ड के iatविरुद्ध दावे user.updated_at(यदि जारी किए गए हैं jwt.iat < user.updated_atतो JWT मान्य नहीं हैं ) को मान्य करने के लिए (पर मैं आपको प्रोत्साहित नहीं करता ) कर सकते हैं।
उपयोगकर्ता ने जानबूझकर लॉग आउट किया है।

अंत में आप टोकन को सामान्य रूप से सत्यापित करते हैं जैसा कि हर कोई करता है।

नोट 2: कैश की कुंजी के रूप में स्वयं टोकन (जो वास्तव में लंबा है) का उपयोग करने के बजाय, मैं jtiदावे के लिए यूयूआईडी टोकन का उत्पादन और उपयोग करने का सुझाव देता हूं । जो अच्छा है और मुझे लगता है (यह निश्चित नहीं है क्योंकि यह मेरे दिमाग में आया था) आप इसी यूआरआईडी का उपयोग सीएसआरएफ टोकन के रूप में कर सकते हैं, इसके साथ secure/ non-http-onlyकुकी वापस X-XSRF-TOKENकरके और जेएस का उपयोग करके हेडर को ठीक से लागू कर सकते हैं। इस तरह आप CSRF जाँच के लिए एक और टोकन बनाने के कंप्यूटिंग कार्य से बचते हैं।

— Frondor
स्रोत

9

अपने विचार को योगदान देने में कभी देर नहीं होती। आपके जवाब के लिए धन्यवाद।

— smwikipedia

2

यदि आप सर्वर पर एक ब्लैकलिस्ट संग्रहीत करते हैं जिसे हर अनुरोध के लिए जांचना आवश्यक है, तो बस सादे पुराने सत्र का उपयोग क्यों न करें?

— फ्रेंकलिन यू

@FranklinYu एक ब्लैक लिस्ट एक पूर्ण सत्र स्टोर की तुलना में "सस्ता" है। चूंकि आप अल्पकालिक की-वैल्यू ऑब्जेक्ट्स को स्टोर कर रहे हैं (उनके बचे हुए समय-समय पर निर्भर करता है, जो बहुत कम होना चाहिए), और यह केवल साइन आउट कार्यों और ऐसे कार्यों के लिए होता है जो टोकन को अमान्य करते हैं, इसलिए प्रत्येक टोकन नहीं है संग्रहीत।

— Frondor

2

यह कितना सस्ता हो सकता है? सबसे पहले, यदि आप अभी भी सर्वर साइड पर कुछ भी स्टोर कर रहे हैं, तो आप JWT द्वारा दावा किए गए "स्केलेबिलिटी" लाभ का आनंद नहीं लेते हैं क्योंकि अभी भी एक केंद्रीय ब्लैकलिस्ट सर्वर है जो सभी एप्लिकेशन सर्वर को कुछ भी करने से पहले बात करने की आवश्यकता है। यदि आपको त्वरित समाप्ति के कारण केवल 1k ब्लैकलिस्ट को संग्रहीत करने की आवश्यकता है, तो आप सत्रों के लिए भी ऐसा कर सकते हैं और इसलिए केवल 1k सत्रों को संग्रहीत करने की आवश्यकता है।

— फ्रैंकलिन यू

3

मुझे यह तरीका पसंद है। आपको वास्तव में प्रत्येक अनुरोध पर ब्लैकलिस्ट की जांच नहीं करनी है, केवल एक अनुरोध पर जो कि JWT की समय सीमा समाप्त होने के बाद होता है (जिसे आप टोकन से पढ़ सकते हैं) और उसके बाद TTL की अवधि तक। एक "मानक" उपयोग के मामले में, जो कि, एक दिए गए टोकन के जीवनकाल में, एक बार में होना चाहिए। एक बार ताज़ा होने के बाद, आप भविष्य के ताज़ा अनुरोधों को अस्वीकार कर सकते हैं। धन्यवाद @ फ्रॉनडोर

— जॉन एकरमैन

7

क्षमा करें इस पर थोड़ी देर हो रही है, लेकिन समान चिंताएं थीं और अब उसी पर कुछ योगदान करना चाहते हैं।

1) rdegges ने एक उत्कृष्ट बिंदु जोड़ा, कि JWT का "सुरक्षा" से कोई लेना-देना नहीं है और बस मान्य है, अगर किसी ने पेलोड के साथ गड़बड़ की है या नहीं (हस्ताक्षर); ssl उल्लंघनों के खिलाफ रोकने में मदद करता है।

2) अब, अगर ssl का किसी तरह से समझौता कर लिया जाता है, तो कोई भी ईवेस्ट्रोपर हमारे बियरर टोकन (JWT) को चुरा सकता है और वास्तविक उपयोगकर्ता को प्रतिरूपित कर सकता है, एक अगला स्तर कदम क्या हो सकता है, की तलाश करना है वह क्लाइंट से JWT के "कब्जे का प्रमाण" प्राप्त करना है। ।

3) अब, इस दृष्टिकोण के साथ, JWT के प्रस्तोता के पास एक विशेष प्रूफ-टू-पोज़िशन (POP) कुंजी है, जिसे प्राप्तकर्ता प्राप्त कर सकता है क्रिप्टोग्राफिक रूप से पुष्टि कि अनुरोध उसी प्रामाणिक उपयोगकर्ता से है या नहीं।

मैंने इसके लिए प्रूफ ऑफ पॉजिशन आर्टिकल को संदर्भित किया और एपोरच के साथ आश्वस्त हूं।

मुझे खुशी होगी, अगर मैं कुछ भी योगदान करने में सक्षम हूं।

चीयर्स (y)

— yanky_cranky
स्रोत

0

क्या हम अभी उस प्रारंभिक होस्ट का आईपी नहीं जोड़ सकते हैं जिसने इस JWT टोकन को दावे के हिस्से के रूप में उत्पन्न करने का अनुरोध किया है? अब जब JWT चोरी हो गया है और एक अलग मशीन से उपयोग किया जाता है, जब सर्वर इस टोकन को सत्यापित करता है, तो हम यह सत्यापित कर सकते हैं कि क्या अनुरोधित मशीन आईपी दावे के हिस्से के रूप में एक सेट के साथ मेल खाती है। यह मेल नहीं खाता और इसलिए टोकन को अस्वीकार किया जा सकता है। इसके अलावा अगर उपयोगकर्ता टोकन के लिए अपना खुद का आईपी सेट करके टोकन में हेरफेर करने की कोशिश करता है, तो टोकन को बदल दिया जाएगा।

— वेंकटेश बनाम
स्रोत

यह एक संभव समाधान है, लेकिन एक आईपी पते के लिए फ़ायरवॉल के पीछे ग्राहकों के लिए पते के एक पूल से उठाया जा सकता है और यह किसी भी समय बदल सकता है।

— स्पीडऑफस्पिन