JWT टोकन के सर्वर-साइड हैंडलिंग के लिए सर्वोत्तम अभ्यास [बंद]

Question

( यह इस धागे से उत्पन्न हुआ क्योंकि यह वास्तव में स्वयं का प्रश्न है और नोड्सज आदि के लिए विशिष्ट नहीं है)

मैं एक REST API सर्वर को प्रमाणीकरण के साथ कार्यान्वित कर रहा हूं, और मैंने JWT टोकन हैंडलिंग को सफलतापूर्वक कार्यान्वित किया है ताकि उपयोगकर्ता उपयोगकर्ता नाम / पासवर्ड के साथ लॉगिन लॉगिन के माध्यम से लॉगिन कर सके, जिस पर एक JWT टोकन एक सर्वर गुप्त से उत्पन्न होता है और वापस आ जाता है ग्राहक। टोकन को क्लाइंट से सर्वर से प्रत्येक प्रमाणित एपीआई अनुरोध में पारित किया जाता है, जिस पर टोकन को सत्यापित करने के लिए सर्वर रहस्य का उपयोग किया जाता है।

हालांकि, मैं वास्तव में कैसे और किस हद तक टोकन को मान्य किया जाना चाहिए, वास्तव में सुरक्षित प्रणाली बनाने के लिए सर्वोत्तम प्रथाओं को समझने की कोशिश कर रहा हूं। बिल्कुल "टोकन को मान्य" करने में क्या शामिल होना चाहिए? क्या यह पर्याप्त है कि हस्ताक्षर को सर्वर-गुप्त का उपयोग करके सत्यापित किया जा सकता है, या क्या मुझे सर्वर में संग्रहीत कुछ डेटा के खिलाफ टोकन और / या टोकन पेलोड को भी क्रॉस-चेक करना चाहिए?

एक टोकन आधारित प्रमाणीकरण प्रणाली केवल प्रत्येक अनुरोध में उपयोगकर्ता नाम / पासवर्ड पारित करने के रूप में सुरक्षित होगी, बशर्ते कि उपयोगकर्ता का पासवर्ड प्राप्त करने की तुलना में टोकन प्राप्त करना समान रूप से या अधिक कठिन हो। हालाँकि, मैंने जो उदाहरण देखे हैं, उनमें टोकन बनाने के लिए आवश्यक जानकारी केवल उपयोगकर्ता नाम और सर्वर-साइड गुप्त है। क्या इसका मतलब यह नहीं है कि एक मिनट के लिए यह मान लेना कि दुर्भावनापूर्ण उपयोगकर्ता को सर्वर के रहस्य का ज्ञान है, वह अब किसी भी उपयोगकर्ता की ओर से टोकन का उत्पादन कर सकता है , जिससे न केवल एक दिए गए उपयोगकर्ता तक पहुंच हो सकती है, बल्कि यह भी होगा कि यदि पासवर्ड था प्राप्त, लेकिन वास्तव में सभी उपयोगकर्ता खातों के लिए?

यह मुझे सवालों के घेरे में लाता है:

1) क्या जेडब्ल्यूटी टोकन सत्यापन केवल टोकन के हस्ताक्षर को सत्यापित करने तक सीमित होना चाहिए, जो अकेले सर्वर की अखंडता पर निर्भर है, या एक अलग सत्यापन तंत्र के साथ है?

• कुछ मामलों में मैंने टोकन और सर्वर सत्रों के संयुक्त उपयोग को देखा है, जहां एक सत्र / लॉगिन समापन बिंदु के माध्यम से सफल लॉगिन स्थापित किया गया है। एपीआई अनुरोध टोकन को मान्य करते हैं, और सत्र में संग्रहीत कुछ डेटा के साथ टोकन में पाए गए डिकोड किए गए डेटा की तुलना भी करते हैं। हालांकि, सत्र का उपयोग करना कुकीज़ का उपयोग करने का अर्थ है, और कुछ अर्थों में यह टोकन आधारित दृष्टिकोण का उपयोग करने के उद्देश्य को पराजित करता है। यह कुछ ग्राहकों के लिए भी समस्या पैदा कर सकता है।

• कोई भी वर्तमान में एक मेमकेच या इसी तरह के उपयोग में आने वाले सर्वर की कल्पना कर सकता है, यह सुनिश्चित करने के लिए कि भले ही सर्वर रहस्य से समझौता किया गया हो, ताकि एक हमलावर "वैध" टोकन का उत्पादन कर सके, केवल वही सटीक टोकन जो / लॉगिन एंडपॉइंट के माध्यम से उत्पन्न हुए थे स्वीकार किया जाएगा। क्या यह उचित है या सिर्फ अतिरेक / अतिरेक?

2) यदि JWT हस्ताक्षर सत्यापन टोकन को मान्य करने का एकमात्र साधन है, जिसका अर्थ है कि सर्वर गुप्त की अखंडता ब्रेकिंग पॉइंट है, सर्वर रहस्यों को कैसे प्रबंधित किया जाना चाहिए? एक पर्यावरण चर से पढ़ें और बनाया (यादृच्छिक?) एक बार तैनात स्टैक के अनुसार? समय-समय पर पुन: नया या घुमाया जाता है (और यदि हां, तो मौजूदा वैध टोकन को कैसे संभालना है जो रोटेशन से पहले बनाए गए थे लेकिन रोटेशन के बाद मान्य करने की आवश्यकता है, शायद यह पर्याप्त है अगर सर्वर किसी भी समय वर्तमान और पिछले रहस्य पर पकड़ रखता है) ? कुछ और?

हो सकता है कि जब सर्वर से समझौता होने का खतरा होता है, तो मैं सामान्य रूप से पागल हो जाता हूं, जो निश्चित रूप से एक अधिक सामान्य समस्या है जिसे सभी क्रिप्टोग्राफिक स्थितियों में संबोधित करने की आवश्यकता है ...

Comments

बड़े अच्छे सवाल हैं। पुन: प्रश्न 2. मैं सर्वर साइड रखा किसी भी गुप्त कुंजी के साथ एक ही मुद्दा है। यदि आप किसी भी प्रकार का हैश मैच या असममित डिक्रिप्शन कर रहे हैं, - चाहे यह db में संग्रहीत jwt या डिक्रिप्टिंग cc जानकारी पर हस्ताक्षर कर रहा हो, तो आपको सर्वर पर कोड द्वारा एक गुप्त कुंजी सुलभ होगी। तो आप इसे कहाँ रखेंगे ?? यहाँ मैंने पाया सबसे अच्छा जवाब है: pcinetwork.org/forum/index.php?threads/… - शायद उतना ही सुरक्षित है जितना कि यह jwt कुंजी के लिए भी मिलता है।

— jbd

Jwt टोकन में गुप्त कुंजी क्या है? मैं सोच रहा हूँ jwt टोकन अपने आप में एक रहस्य है। या गुप्त कुंजी हो सकती है RSAPrivateKey privateKey??

— किट्टू

यह कुछ समय पहले पूछा गया था, लेकिन शायद कोई इसे उपयोगी पाएगा। मेरे मामले में, मेरे पास प्रति उपयोगकर्ता एक "गुप्त कुंजी" है। इसलिए जब भी कोई उपयोगकर्ता लॉगिन करता है, मैं उस रहस्य को जेनरेट करता हूं और DB में उपयोगकर्ता रिकॉर्ड के साथ स्टोर करता हूं। मैं उस रहस्य का उपयोग करते हुए टोकन को मान्य करता हूं। लॉगआउट करने पर, मैं उस मूल्य को साफ करता हूं। यह स्वचालित रूप से पहले निर्मित अन्य टोकन को अमान्य कर देता है (यह वही है जिसकी मुझे आवश्यकता है)।

— नेल्सन रोड्रिगेज

Answer 1

मैं अपने आवेदन के लिए टोकन के साथ भी खेल रहा हूं। जबकि मैं किसी भी तरह से एक विशेषज्ञ नहीं हूं, मैं अपने कुछ अनुभवों और विचारों को मामले पर साझा कर सकता हूं।

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

पेलोड के रूप में, हस्ताक्षर केवल आपको बताएगा कि आपको प्रदान किया गया टोकन बिल्कुल वैसा ही था जैसा कि आपके सर्वर ने इसे भेजा था। यह पुष्टि करते हुए कि आपके आवेदन के लिए पेलोड की सामग्री वैध है या उचित है, स्पष्ट रूप से आप पर निर्भर है।

आपके सवालों के लिए:

1.) मेरे सीमित अनुभव में, निश्चित रूप से अपने टोकन को दूसरी प्रणाली के साथ सत्यापित करना बेहतर है। बस हस्ताक्षर को मान्य करने का मतलब है कि टोकन आपके रहस्य के साथ उत्पन्न हुआ था। किसी भी प्रकार के बनाए गए टोकन को किसी प्रकार के डीबी (रेडिस, मेमकेच / एसक्यूएल / मोंगो, या कुछ अन्य भंडारण) में संग्रहीत करना यह आश्वस्त करने का एक शानदार तरीका है कि आप केवल उस टोकन को स्वीकार करें जिसे आपके सर्वर ने बनाया है। इस परिदृश्य में, भले ही आपका रहस्य लीक हो गया हो, यह बहुत ज्यादा मायने नहीं रखेगा क्योंकि किसी भी उत्पन्न टोकन वैसे भी मान्य नहीं होंगे। यह वह दृष्टिकोण है जो मैं अपने सिस्टम के साथ ले रहा हूं - सभी उत्पन्न टोकन एक डीबी (रेडिस) में संग्रहीत किए जाते हैं और प्रत्येक अनुरोध पर, मैं सत्यापित करता हूं कि टोकन स्वीकार करने से पहले मेरे डीबी में है। इस तरह से टोकन को किसी भी कारण से रद्द किया जा सकता है, जैसे कि टोकन किसी भी तरह से जंगली में जारी किए गए, उपयोगकर्ता लॉगआउट, पासवर्ड परिवर्तन, गुप्त परिवर्तन आदि।

2.) यह कुछ ऐसा है जिसमें मुझे बहुत अनुभव नहीं है और कुछ ऐसा है जो मैं अभी भी सक्रिय रूप से शोध कर रहा हूं क्योंकि मैं एक सुरक्षा पेशेवर नहीं हूं। यदि आपको कोई संसाधन मिलते हैं, तो उन्हें यहां पोस्ट करने के लिए स्वतंत्र महसूस करें! वर्तमान में, मैं बस एक निजी कुंजी का उपयोग कर रहा हूं जिसे मैं डिस्क से लोड करता हूं, लेकिन जाहिर है कि यह सबसे अच्छा या सबसे सुरक्षित समाधान से दूर है।

Comments

दूसरी बात यहाँ के लिए एक अच्छा जवाब है: security.stackexchange.com/questions/87130/...

— Bossliaw

जैसे ही हेडर में टोकन उपलब्ध होते हैं, अगर टोकन चोरी हो जाता है और दुर्भावनापूर्ण उस टोकन के साथ लॉगिन करने की कोशिश करता है (उपयोगकर्ता के ईमेल पते के बारे में पता होना)?

— किट्टू

यदि आप हर JWT को स्टोर करते हैं, तो JWT का कोई लाभ नहीं है और आप रैंडम सेशन आईडी के साथ भी चिपक सकते हैं।

— कॉलिनएम

Answer 2

आपके आवेदन में JWT को लागू करते समय कुछ बातों पर ध्यान दिया गया है:

• अपने JWT जीवनकाल को अपेक्षाकृत कम रखें, और क्या यह सर्वर पर आजीवन प्रबंधित है। यदि आप नहीं करते हैं, और बाद में आपके JWTs में अधिक जानकारी की आवश्यकता होती है, तो आपको या तो 2 संस्करणों का समर्थन करना होगा, या जब तक आपके पुराने JWTs आपके परिवर्तन को लागू करने से पहले समाप्त नहीं हो जाते, तब तक प्रतीक्षा करें। यदि आप केवल iatjwt में फ़ील्ड को देखते हैं, और फ़ील्ड को अनदेखा करते हैं, तो आप इसे सर्वर पर आसानी से प्रबंधित कर सकते हैं exp।

• अपने JWT में अनुरोध के url सहित विचार करें। उदाहरण के लिए, यदि आप चाहते हैं कि आपका JWT अंतिम बिंदु पर उपयोग किया जाए, तो अपने JWT /my/test/pathमें एक फ़ील्ड की तरह 'url':'/my/test/path'शामिल करें, यह सुनिश्चित करने के लिए कि यह केवल इस पथ पर कभी उपयोग किया गया है। यदि आप नहीं करते हैं, तो आप पा सकते हैं कि लोग आपके JWTs का उपयोग अन्य समापन बिंदुओं पर करना शुरू करते हैं, यहां तक ​​कि वे जिनके लिए बनाए नहीं गए थे। आप इसके बजाय एक md5 (url) पर विचार कर सकते हैं, क्योंकि JWT में एक बड़ा url होने से JWT बहुत बड़ा हो जाएगा और वे काफी बड़े हो सकते हैं।

• अगर JWT को एक एपीआई में लागू किया जा रहा है, तो JWT की समाप्ति प्रत्येक उपयोग के मामले में विन्यास योग्य होनी चाहिए। उदाहरण के लिए, यदि आपके पास JWT के लिए 10 अलग-अलग उपयोग के मामलों के लिए 10 समापन बिंदु हैं, तो सुनिश्चित करें कि आप प्रत्येक समापन बिंदु को JWT स्वीकार कर सकते हैं जो अलग-अलग समय पर समाप्त होते हैं। यह आपको दूसरों से अधिक कुछ समापन बिंदुओं को लॉक करने की अनुमति देता है, उदाहरण के लिए, एक समापन बिंदु द्वारा दिया गया डेटा बहुत संवेदनशील है।

• एक निश्चित समय के बाद केवल JWTs को समाप्त करने के बजाय, JWT को लागू करने पर विचार करें जो दोनों का समर्थन करता है:

  • एन usages - समाप्त होने से पहले केवल N बार उपयोग किया जा सकता है और
  • निश्चित समय के बाद समाप्त हो जाना (यदि आपके पास केवल एक टोकन का उपयोग होता है, तो आप नहीं चाहते कि यह हमेशा के लिए जीवित रहे, यदि आप उपयोग नहीं करते हैं?)

• सभी JWT प्रमाणीकरण विफलताओं को "त्रुटि" प्रतिक्रिया शीर्षक उत्पन्न करना चाहिए जो बताता है कि JWT प्रमाणीकरण विफल क्यों हुआ। जैसे "एक्सपायर्ड", "नो यूजेज लेफ्ट", "निरस्त", आदि। इससे कार्यान्वयनकर्ताओं को पता चलता है कि उनका जेडब्ल्यूटी क्यों फेल हो रहा है।

• अपने JWTs के "हेडर" को अनदेखा करने पर विचार करें क्योंकि वे जानकारी लीक करते हैं और हैकर्स को नियंत्रण का एक उपाय देते हैं। यह ज्यादातर algहेडर में फ़ील्ड के विषय में है - इसे अनदेखा करें और बस मान लें कि हेडर वही है जो आप समर्थन करना चाहते हैं, क्योंकि यह हैकर्स Noneएल्गोरिथ्म का उपयोग करने की कोशिश करने से बचता है , जो हस्ताक्षर सुरक्षा जांच को हटा देता है।

• JWT में एक पहचानकर्ता का विवरण शामिल होना चाहिए कि किस ऐप ने टोकन उत्पन्न किया है। उदाहरण के लिए यदि आपके JWT के 2 अलग-अलग क्लाइंट, mychat और myclassifiedsapp द्वारा बनाए जा रहे हैं, तो प्रत्येक को JWT जैसे "iss": "mychat" में "iss" फ़ील्ड में प्रोजेक्ट नाम या कुछ समान होना चाहिए।

• JWT की लॉग फ़ाइलों में लॉग इन नहीं होना चाहिए। एक JWT की सामग्री को लॉग किया जा सकता है, लेकिन JWT को नहीं। यह सुनिश्चित करता है कि देव या अन्य लोग लॉग फाइल से JWT को नहीं पकड़ सकते हैं और अन्य उपयोगकर्ताओं के खातों में काम कर सकते हैं।
• अपने JWT कार्यान्वयन सुनिश्चित करें कि "कोई भी" एल्गोरिथ्म की अनुमति नहीं देता है, हैकर्स द्वारा उन्हें हस्ताक्षर किए बिना टोकन बनाने से बचने के लिए। त्रुटियों की इस श्रेणी को आपके JWT के "हेडर" की अनदेखी करके पूरी तरह से टाला जा सकता है।
• अपने JWTs में (एक्सपायरी) के iatबजाय (जारी किए गए) का उपयोग करने पर expज़ोर दें। क्यों? चूंकि iatमूल रूप से इसका मतलब है कि JWT कब बनाया गया था, इससे आप JWT की समाप्ति तिथि के आधार पर सर्वर पर समायोजित कर सकते हैं। अगर कोई expभविष्य में 20 साल में गुजरता है , तो JWT मूल रूप से हमेशा के लिए रहता है! ध्यान दें कि यदि आप iatभविष्य में हैं तो आप JWTs को स्वचालित रूप से समाप्त कर देते हैं, लेकिन क्लाइंट के समय सर्वर समय के साथ सिंक से थोड़ा बाहर होने की स्थिति में थोड़े थोड़े कमरे (जैसे 10 सेकंड) की अनुमति दें।
• एक json पेलोड से JWTs बनाने के लिए एक समापन बिंदु को लागू करने पर विचार करें, और अपने सभी कार्यान्वयन ग्राहकों को अपने JWTs बनाने के लिए इस समापन बिंदु का उपयोग करने के लिए मजबूर करें। यह सुनिश्चित करता है कि आप किसी भी सुरक्षा मुद्दों को संबोधित कर सकते हैं जो आप चाहते हैं कि कैसे JWTs आसानी से एक जगह पर बनाए जाएं। हमने अपने ऐप में इसे सीधे बंद नहीं किया, और अब धीरे-धीरे JWT सर्वर साइड सिक्योरिटी अपडेट को बाहर करना होगा क्योंकि हमारे 5 अलग-अलग क्लाइंट्स को इसे लागू करने के लिए समय चाहिए। इसके अलावा, अपने बनाएँ समापन बिंदु JWTs बनाने के लिए json पेलोड के एक सरणी को स्वीकार करते हैं, और यह आपके क्लाइंट के लिए इस समापन बिंदु पर आने वाले http अनुरोधों के # को कम करेगा।
• यदि आपके JWT का उपयोग उन समापन बिंदुओं पर किया जाएगा जो सत्र द्वारा उपयोग का समर्थन करते हैं, तो सुनिश्चित करें कि आपने अपने JWT में कुछ भी नहीं डाला है जो अनुरोध को पूरा करने के लिए आवश्यक है। आप आसानी से ऐसा कर सकते हैं यदि आप यह सुनिश्चित करते हैं कि आपका समापन बिंदु एक सत्र के साथ काम करता है, जब कोई जेडब्ल्यूटी आपूर्ति नहीं करता है।
• तो JWT के आम तौर पर बोलने वाले अंत में किसी प्रकार का एक userId या groupId होता है, और इस जानकारी के आधार पर आपके सिस्टम के हिस्से तक पहुंच की अनुमति देता है। सुनिश्चित करें कि आप अपने ऐप के एक क्षेत्र में उपयोगकर्ताओं को अन्य उपयोगकर्ताओं को प्रतिरूपित करने की अनुमति नहीं दे रहे हैं, खासकर यदि यह संवेदनशील डेटा तक पहुंच प्रदान करता है। क्यों? ठीक है, भले ही आपकी JWT पीढ़ी की प्रक्रिया केवल "आंतरिक" सेवाओं के लिए सुलभ हो, देव या अन्य आंतरिक टीम किसी भी उपयोगकर्ता के लिए डेटा तक पहुंचने के लिए JWTs उत्पन्न कर सकती हैं, जैसे कुछ यादृच्छिक क्लाइंट की कंपनी के सीईओ। उदाहरण के लिए, यदि आपका ऐप ग्राहकों के लिए वित्तीय रिकॉर्ड तक पहुंच प्रदान करता है, तो एक JWT उत्पन्न करके, एक देव किसी भी कंपनी के वित्तीय रिकॉर्ड को बिल्कुल भी हड़प सकता है! और अगर किसी हैकर को किसी भी तरह से आपके आंतरिक नेटवर्क में प्रवेश मिलता है, तो वे भी ऐसा कर सकते हैं।
• यदि आप किसी भी url की अनुमति देने जा रहे हैं जिसमें JWT को किसी भी तरह से कैश किया जा सकता है, तो सुनिश्चित करें कि विभिन्न उपयोगकर्ताओं के लिए अनुमतियाँ url में शामिल हैं, और JWT नहीं। क्यों? क्योंकि उपयोगकर्ता अंत में डेटा प्राप्त कर सकते हैं जो उन्हें नहीं करना चाहिए। उदाहरण के लिए, एक सुपर उपयोगकर्ता आपके ऐप में लॉग इन करता है, और निम्न url का अनुरोध करता है: /mysite/userInfo?jwt=XXXऔर यह url कैश हो जाता है। वे लॉगआउट करते हैं और कुछ मिनट बाद, एक नियमित उपयोगकर्ता आपके ऐप में लॉग इन करता है। वे कैश्ड सामग्री प्राप्त करेंगे - एक सुपर उपयोगकर्ता के बारे में जानकारी के साथ! यह क्लाइंट पर कम होता है, और सर्वर पर अधिक होता है, खासकर ऐसे मामलों में जहां आप अकामाई जैसे सीडीएन का उपयोग कर रहे हैं, और आप कुछ फाइलों को लंबे समय तक रहने दे रहे हैं। यह यूआरएल में संबंधित उपयोगकर्ता जानकारी को शामिल करके तय किया जा सकता है, और उदाहरण के लिए, कैश्ड अनुरोधों के लिए भी सर्वर पर इसे मान्य किया जा सकता है।/mysite/userInfo?id=52&jwt=XXX
• यदि आपका jwt एक सत्र कुकी की तरह उपयोग करने का इरादा है, और केवल उसी मशीन पर काम करना चाहिए जिसके लिए jwt बनाया गया था, तो आपको अपने jwt में एक jti फ़ील्ड जोड़ने पर विचार करना चाहिए । यह मूल रूप से एक CSRF टोकन है, जो सुनिश्चित करता है कि आपका JWT एक उपयोगकर्ता के ब्राउज़र से माताओं तक नहीं जा सकता है।

Comments

जैसा कि आप उल्लेख करते हैं created_by, JWT में इसके लिए पहले से ही एक दावा है और इसे iss(जारीकर्ता) कहा जाता है ।

— फ्रेड

हाँ अच्छा बिंदु - मैं उस के साथ अद्यतन करेंगे ... धन्यवाद!

— ब्रैड पार्क 18

Answer 3

मुझे नहीं लगता कि मैं एक विशेषज्ञ हूं, लेकिन मैं Jwt के बारे में कुछ विचार साझा करना चाहूंगा।

• 1: जैसा कि अक्षय ने कहा, आपके टोकन को मान्य करने के लिए दूसरी प्रणाली होना बेहतर है।

  एक: जिस तरह से मैं इसे संभालता हूं: मैं एक्सपायरी समय के साथ एक सत्र भंडारण में उत्पन्न हैश को संग्रहीत करता हूं। एक टोकन को मान्य करने के लिए, इसे सर्वर द्वारा जारी किया जाना चाहिए।

  b.: यह कम से कम एक चीज है जिसे उपयोग की जाने वाली हस्ताक्षर विधि की जांच करनी चाहिए। जैसे:

  header :
  {
    "alg": "none",
    "typ": "JWT"
  }
  

JWT को मान्य करने वाले कुछ पुस्तकालय बिना हैश की जाँच के इसे स्वीकार करेंगे। इसका मतलब है कि आपके नमक को जाने बिना टोकन पर हस्ताक्षर करने के लिए इस्तेमाल किया गया था, एक हैकर खुद को कुछ अधिकार दे सकता है। हमेशा सुनिश्चित करें कि ऐसा नहीं हो सकता। https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/

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

• 2: यह हर रहस्य के लिए समान है। इसे जानने का हमेशा एक तरीका है।

जिस तरह से मैं इसे संभालता हूं वह बिंदु 1. ए से जुड़ा हुआ है। : मेरे पास एक यादृच्छिक चर के साथ एक रहस्य मिला हुआ है। हर टोकन के लिए रहस्य अद्वितीय है।

हालांकि, मैं वास्तव में कैसे और किस हद तक टोकन को मान्य किया जाना चाहिए, वास्तव में सुरक्षित प्रणाली बनाने के लिए सर्वोत्तम प्रथाओं को समझने की कोशिश कर रहा हूं।

यदि आप सर्वोत्तम सुरक्षा चाहते हैं, तो आपको आँख बंद करके सर्वोत्तम प्रथाओं का पालन नहीं करना चाहिए। सबसे अच्छा तरीका यह समझना है कि आप क्या कर रहे हैं (मुझे लगता है कि यह ठीक है जब मैं आपके प्रश्न को देखता हूं), और फिर आपको आवश्यक सुरक्षा का मूल्यांकन करें। और अगर मोसाद आपके गोपनीय डेटा तक पहुंच चाहता है, तो वे हमेशा एक रास्ता खोज लेंगे। (मुझे यह ब्लॉग पोस्ट पसंद है: https://www.schneier.com/blog/archives/2015/08/mickens_on_siveu.html )

Comments

हर टोकन के लिए एक अनूठा रहस्य रखने के लिए अच्छा बिंदु लेकिन आप हर बार एक अनूठा रहस्य कैसे बनाते हैं? मैं nimbus

— jwt

शायद आपके उपयोगकर्ता के हैश पासवर्ड का उपयोग करें।

— मोमोक्जाआ

"यदि आप चीजों को उसी तरह से नहीं कर रहे हैं जैसे अन्य लोग करते हैं, तो लोगों के लिए आपकी सुरक्षा के माध्यम से रास्ता खोजना अधिक कठिन होगा।" यह मुझे अस्पष्टता के माध्यम से सुरक्षा की तरह लगता है। सर्वोत्तम प्रथाओं को कहा जाता है क्योंकि वे व्यावहारिक रूप से सबसे आम जोखिमों को कम करते हैं।

— Mnebuerquo

@Mnebuerquo मैं आपसे पूरी तरह सहमत हूं, उस आदमी ने लिखा है जिस पर भरोसा नहीं किया जाना चाहिए ;-)

— डेब्लाटन जीन-फिलिप

वह सही है, हालांकि किसी को भी सर्वोत्तम प्रथाओं का आँख बंद करके पालन नहीं करना चाहिए । यह समझना अच्छा है कि सर्वोत्तम प्रथाओं को सबसे अच्छा क्यों माना जाता है । हर सुरक्षा डिजाइन निर्णय में सुरक्षा और प्रयोज्य के बीच एक व्यापार है। क्यों आप समझदारी से उन निर्णयों को समझ सकते हैं। (हालांकि आपके उपयोगकर्ता नहीं करेंगे क्योंकि सर्वोत्तम प्रथाओं का पालन करें।)

— Mnebuerquo

Answer 4

यहाँ बहुत अच्छे जवाब। मैं उन कुछ उत्तरों को एकीकृत करूंगा जो मुझे लगता है कि सबसे अधिक प्रासंगिक हैं और कुछ और सुझाव जोड़ते हैं।

1) क्या जेडब्ल्यूटी टोकन सत्यापन केवल टोकन के हस्ताक्षर को सत्यापित करने तक सीमित होना चाहिए, जो अकेले सर्वर की अखंडता पर निर्भर है, या एक अलग सत्यापन तंत्र के साथ है?

नहीं, क्योंकि एक टोकन रहस्य के समझौते से असंबंधित कारण। हर बार जब कोई उपयोगकर्ता नाम और पासवर्ड के माध्यम से लॉग इन करता है, तो प्राधिकरण सर्वर को या तो टोकन संग्रहीत किया गया था, या उत्पन्न टोकन के बारे में मेटाडेटा संग्रहीत करना चाहिए। इस मेटाडेटा को एक प्राधिकरण रिकॉर्ड के रूप में सोचें। किसी दिए गए उपयोगकर्ता और एप्लिकेशन की जोड़ी में किसी भी समय केवल एक वैध टोकन या प्राधिकरण होना चाहिए। उपयोगी मेटाडेटा एक्सेस आईडी, ऐप आईडी से जुड़ा यूजर आईडी है, और जिस समय एक्सेस टोकन जारी किया गया था (जो मौजूदा एक्सेस टोकन को रद्द करने और नए एक्सेस टोकन जारी करने की अनुमति देता है)। प्रत्येक एपीआई अनुरोध पर, मान्य करें कि टोकन में उचित मेटाडेटा है। आपको प्रत्येक एक्सेस टोकन जारी किए जाने के बारे में जानकारी जारी रखने की आवश्यकता है, यदि कोई उपयोगकर्ता अपने खाते की क्रेडेंशियल्स से छेड़छाड़ करता है, तो वह मौजूदा एक्सेस टोकन को रद्द कर सकता है और फिर से लॉग इन करके एक नए एक्सेस टोकन का उपयोग करना शुरू कर सकता है। वह डेटाबेस को उस समय के साथ अपडेट करेगा जब एक्सेस टोकन जारी किया गया था (प्राधिकरण समय बनाया गया)। प्रत्येक API अनुरोध पर, जाँच लें कि पहुँच टोकन का समस्या समय प्राधिकरण के समय के बाद बनाया गया है।

अन्य सुरक्षा उपायों में JWT को लॉग इन नहीं करना और SHA256 जैसे सुरक्षित हस्ताक्षर एल्गोरिथ्म की आवश्यकता शामिल है।

2) यदि JWT हस्ताक्षर सत्यापन टोकन को मान्य करने का एकमात्र साधन है, जिसका अर्थ है कि सर्वर गुप्त की अखंडता ब्रेकिंग पॉइंट है, सर्वर रहस्यों को कैसे प्रबंधित किया जाना चाहिए?

सर्वर रहस्य का समझौता किसी हमलावर को किसी भी उपयोगकर्ता के लिए पहुंच टोकन जारी करने की अनुमति देता है, और चरण 1 में एक्सेस टोकन डेटा को संग्रहीत करना आवश्यक नहीं होगा ताकि सर्वर उन एक्सेस टोकन को स्वीकार करने से रोक सके। उदाहरण के लिए, यह कहें कि एक उपयोगकर्ता को एक टोकन जारी किया गया है, और फिर बाद में, एक हमलावर उस उपयोगकर्ता के लिए एक पहुँच टोकन बनाता है। पहुँच टोकन का प्राधिकरण समय मान्य होगा।

जैसे अक्षय ढालवाला कहते हैं, यदि आपके सर्वर-साइड रहस्य से समझौता किया जाता है, तो आपको इससे निपटने के लिए बड़ी समस्याएं हैं क्योंकि इसका मतलब है कि एक हमलावर ने आपके आंतरिक नेटवर्क, आपके स्रोत कोड भंडार या दोनों से समझौता किया है।

हालाँकि, एक समझौता सर्वर सीक्रेट के नुकसान को कम करने और स्रोत कोड में रहस्यों को संग्रहीत करने से बचने के लिए एक प्रणाली में https://zookeeper.apache.org जैसी समन्वय सेवा का उपयोग करके टोकन गुप्त रोटेशन शामिल है।। एप्लिकेशन को हर कुछ घंटों में गुप्त उत्पन्न करने के लिए क्रोन जॉब का उपयोग करें (हालांकि लंबे समय तक आपकी पहुंच टोकन के लिए मान्य होती है), और अपडेट किए गए रहस्य को ज़ूकीपर तक पहुंचाएं। प्रत्येक अनुप्रयोग सर्वर में जो टोकन रहस्य को जानना आवश्यक है, ZK नोड मान में परिवर्तन होने पर अद्यतन किया गया ZK क्लाइंट कॉन्फ़िगर करें। एक प्राथमिक और द्वितीयक रहस्य संग्रहित करें, और हर बार टोकन रहस्य बदल जाने के बाद, नए टोकन रहस्य को प्राथमिक और पुराने टोकन रहस्य को माध्यमिक में सेट करें। इस तरह, मौजूदा वैध टोकन अभी भी मान्य होंगे क्योंकि वे माध्यमिक रहस्य के खिलाफ मान्य होंगे। जब तक माध्यमिक रहस्य को पुराने प्राथमिक रहस्य के साथ बदल दिया जाता है, तब तक माध्यमिक रहस्य के साथ जारी किए गए सभी एक्सेस टोकन समाप्त हो जाएंगे।

Answer 5

IETF के पास OAuth वर्किंग ग्रुप में एक RFC प्रगति पर है: https://tools.ietf.org/id/draft-ietf-oauth-jwt-bcp-05.html