क्या अभिकर्मक के साथ लोकलस्टोरेज में jwt स्टोर करना सुरक्षित है?

Question

मैं वर्तमान में reactjs का उपयोग करके एक एकल पृष्ठ एप्लिकेशन बना रहा हूं। मैंने पढ़ा है कि लोकलस्टोरेज का उपयोग न करने के कई कारण एक्सएसएस कमजोरियों के कारण हैं। चूंकि React सभी उपयोगकर्ता इनपुट से बच जाता है, क्या अब लोकलस्टोरेज का उपयोग करना सुरक्षित होगा?

Comments

सेशन स्टोरेज पसंद करते हैं

— प्रणीत रोहिड़ा

"स्थानीय भंडारण में टोकन स्टोर न करें" - प्रमाण 0

— अरमान चरण

"स्थानीय भंडारण में किसी भी संवेदनशील जानकारी को संग्रहीत नहीं करने की सिफारिश की गई है।" -OWASP "उन्हें किसी भी दृढ़ता के बिना स्मृति में स्टोर करें" -थो0

— avejidah

मुझे लगता है कि Auth0 ने इस पर अपना दृष्टिकोण बदल दिया होगा - क्योंकि मैं दिए गए लिंक में उपरोक्त उद्धरण नहीं पा सकता हूं

— DauleDK

Answer 1

अधिकांश आधुनिक सिंगल पेज एप्लिकेशन में, हमें वास्तव में टोकन को क्लाइंट साइड पर स्टोर करना होगा (सबसे आम उपयोग का मामला - उपयोगकर्ता को पेज रिफ्रेश करने के बाद लॉग इन रखने के लिए)।

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

टॉम एबट ने JWT सेशनस्टोरेज और लोकलस्टोरेज सिक्योरिटी को अच्छी तरह बताया है :

वेब संग्रहण (लोकलस्टोरेज / सेशनस्टोरेज) उसी डोमेन पर जावास्क्रिप्ट के माध्यम से सुलभ है। इसका मतलब है कि आपकी साइट पर चलने वाले किसी भी जावास्क्रिप्ट का उपयोग वेब स्टोरेज तक होगा, और इसकी वजह से क्रॉस-साइट स्क्रिप्टिंग (XSS) हमलों की चपेट में आ सकते हैं । XSS, संक्षेप में, एक प्रकार की भेद्यता है जहां एक हमलावर जावास्क्रिप्ट को इंजेक्ट कर सकता है जो आपके पृष्ठ पर चलेगा। बेसिक एक्सएसएस हमलों को इनपुट के माध्यम से जावास्क्रिप्ट को इंजेक्ट करने का प्रयास करता है, जहां हमलावर <script>alert('You are Hacked');</script>यह देखने के लिए एक फॉर्म में डालता है कि क्या यह ब्राउज़र द्वारा चलाया जाता है और अन्य उपयोगकर्ताओं द्वारा देखा जा सकता है।

XSS को रोकने के लिए, सामान्य प्रतिक्रिया सभी अविश्वसनीय डेटा से बचना और एनकोड करना है। प्रतिक्रिया (ज्यादातर) आपके लिए है! XSS भेद्यता संरक्षण के लिए प्रतिक्रिया कितना जिम्मेदार है, इस बारे में यहां एक शानदार चर्चा है ।

लेकिन यह सभी संभावित कमजोरियों को कवर नहीं करता है! एक अन्य संभावित खतरा सीडीएन या बाहर के बुनियादी ढांचे पर होस्ट किए गए जावास्क्रिप्ट का उपयोग है ।

यहाँ फिर टॉम है:

आधुनिक वेब ऐप में ए / बी परीक्षण, फ़नल / मार्केट विश्लेषण और विज्ञापनों के लिए 3 पार्टी जावास्क्रिप्ट लाइब्रेरी शामिल हैं। हम अपने एप्लिकेशन में अन्य लोगों के कोड को आयात करने के लिए Bower जैसे पैकेज प्रबंधकों का उपयोग करते हैं।

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

इसलिए, मेरा निष्कर्ष यह है कि भंडारण तंत्र के रूप में, वेब संग्रहण स्थानांतरण के दौरान किसी भी सुरक्षित मानकों को लागू नहीं करता है । जो कोई भी वेब स्टोरेज को पढ़ता है और इसका उपयोग करता है, उन्हें यह सुनिश्चित करने के लिए अपनी मेहनत करनी चाहिए कि वे हमेशा HTTPS पर JWT भेजें और कभी HTTP न करें।

Comments

तो अगर मैं आपको सही तरीके से समझ रहा हूं, तो आप कुकीज़ की सलाह देते हैं? सुनिश्चित करने के लिए। धन्यवाद!

— सुपरलेमन

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

— कालोयान कोसव

मुझे लगता है कि आपके पास ये मिश्रित हैं? XSS के लिए आधुनिक वेब फ्रेमवर्क मजबूत हैं। लेकिन xsrf के लिए इतना नहीं। पूरी तरह से कुकीज़ के उपयोग से बचने के लिए xsrf के लिए सबसे अच्छा बचाव है। स्थानीय भंडारण एक विशिष्ट डोमेन के लिए सैंडबॉक्स है, जिसका अर्थ है कि एक हमलावर डोमेन इसे एक्सेस नहीं कर सकता है। वेब फ्रेमवर्क उपयोगकर्ता के इनपुट को स्वचालित रूप से एन्कोडिंग और सैनेटाइज़ करके xss से बचाव करता है। देखें angular.io/guide/security

— mikejones1477

यदि आप "कुकीज़ की सलाह देते हैं [इसके बजाय]", तो, क्या मैं आपको यह कहने की सलाह दे सकता हूं कि उत्तर में कहीं है? बल्कि सिर्फ टिप्पणियों में?

— स्पैक्टर

मैं यहाँ थोड़ा लेट हो गया हूँ, अभी इन विषयों को पढ़ रहा हूँ और मैं एक चीज़ के बारे में उलझन में हूँ, बहुत से लोग बात करते हैं कि आप केवल http से कुकी के साथ सुरक्षित हैं यदि आप Xss से प्रभावित हैं, लेकिन, अगर आपके पास xss है atacker को आपको कुछ भी चुराने की आवश्यकता नहीं है, वह उस कुकी का उपयोग करते हुए आपको अव्यवस्थित करने के लिए पृष्ठ से एक पोस्ट बना सकता है (भले ही वह उसे चोरी न करे)। क्या मैं कुछ भूल रहा हूँ???

— बोरजा अल्वारेज़

Answer 2

मुझे पता है कि यह एक पुराना प्रश्न है लेकिन @ mikejones1477 ने जो कहा है, उसके अनुसार, आधुनिक फ्रंट एंड लाइब्रेरी और फ्रेमवर्क आपको XSS से सुरक्षा प्रदान करने वाले पाठ से बच जाते हैं। कुकीज़ का उपयोग करने का सुरक्षित तरीका क्यों नहीं है इसका कारण यह है कि जब लोकलस्टोरेज करता है तो कुकीज़ CSRF को रोकती नहीं हैं (यह भी याद रखें कि कुकीज़ जावास्क्रिप्ट द्वारा भी सुलभ हैं, इसलिए XSS यहाँ बड़ी समस्या नहीं है), इस उत्तर को फिर से शुरू करें ।

स्थानीय संग्रहण में एक प्रमाणीकरण टोकन संग्रहीत करने और मैन्युअल रूप से प्रत्येक अनुरोध में जोड़ने का कारण CSRF से सुरक्षा करता है वह है मुख्य शब्द: मैनुअल। चूँकि ब्राउज़र स्वचालित रूप से उस सामान्य टोकन को नहीं भेज रहा है, अगर मैं bad.com पर जाता हूं और यह POST http://example.com/delete-my-account भेजने का प्रबंधन करता है , तो यह मेरे ऑर्टन टोकन को भेजने में सक्षम नहीं होगा, इसलिए अनुरोध पर ध्यान नहीं दिया गया है।

बेशक httplyly पवित्र क़ब्र है, लेकिन आप अभी भी CSR सुरक्षा भेद्यता के साथ रिएक्टज या किसी भी जेएस ढांचे से पहुंच नहीं सकते हैं। मेरी सिफारिश स्थानीय स्तर पर होगी या यदि आप कुकीज़ का उपयोग करना चाहते हैं तो सुनिश्चित करें कि आपकी CSRF समस्या का कुछ समाधान इम्प्लाईमेटिंग जैसे कि django करता है ।

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

Comments

सुनिश्चित नहीं हैं कि आप कुकीज़ का उपयोग करते समय यह क्यों कहेंगे कि आप अभी भी CSRF के लिए असुरक्षित हैं। झंडे के साथ एक कुकी का उपयोग करना HttpOnly SameSite=strictऔर secure, आपके द्वारा सेट की गई जानकारी को कुकीज़ में सुरक्षित रखेगा। फिर XSS के खिलाफ, आप बस यह सुनिश्चित करें कि आपका जावास्क्रिप्ट किसी भी प्रमाणीकरण से संबंधित डेटा, जैसे टोकन और पासवर्ड (अर्थ, उन्हें वेब स्टोरेज में स्टोर न करें) के बारे में पता नहीं है - यदि आप दुर्भावनापूर्ण स्क्रिप्ट आयात करते हैं, तो उस स्क्रिप्ट तक पहुंच नहीं होगी संवेदनशील डेटा के लिए। हां, आपको जेएस के माध्यम से टोकन तक पहुंच नहीं होगी, लेकिन यह वास्तव में समस्या नहीं होनी चाहिए।

— जूल

@ मम्पी यही तो मैंने कहा है। लेकिन ओपी जावास्क्रिप्ट से एक्सेस करने का तरीका पूछ रहा है। यहाँ मैं समझा रहा हूँ कि js से सुलभ टोकन स्टोर करने का सबसे अच्छा तरीका क्या है।

— मौरिसियो कोरटज़ार

Answer 3

असल में अपने JWT को अपने लोकलस्टोरेज में स्टोर करना ठीक है।

और मुझे लगता है कि यह एक अच्छा तरीका है। अगर हम सीडीएन का उपयोग कर एक्सएसएस, एक्सएसएस के बारे में बात कर रहे हैं, तो यह आपके ग्राहक के लॉगिन / पास के रूप में अच्छी तरह से होने का एक संभावित जोखिम है। स्थानीय संग्रहण में डेटा संग्रहीत करने से CSRF के हमलों को कम से कम रोका जा सकेगा।

आपको दोनों के बारे में पता होना चाहिए और जो आप चाहते हैं उसे चुनें। दोनों हमलों यह सब आप के बारे में पता होना चाहिए की जरूरत नहीं है, बस याद रखें: आपका पूरा एपीपी केवल आपके app के सबसे सुरक्षित बिंदु के रूप में सुरक्षित है।

एक बार फिर से भंडारण ठीक है, XSS, CSRF के लिए असुरक्षित हो, ... नहीं है

Comments

यही कारण है कि यह करना सुरक्षित है: - JWT को कुकी में स्टोर करें ताकि इसे XSS से पुनर्प्राप्त न किया जा सके - CSRF टोकन को लोकलस्टोरेज में स्टोर करें ताकि इसे CSRF

— एलेजग्रो कैवाज़ोस

आप एक अच्छा बिंदु लाते हैं: यदि आपकी साइट दुर्भावनापूर्ण स्क्रिप्ट चलाती है, तो यह वैसे भी खेल है। वे बस प्रकार के पासवर्ड के आदान-प्रदान की घटनाओं के लिए बाध्य कर सकते हैं और आपके उपयोगकर्ता की प्रमाणीकरण जानकारी को चोरी कर सकते हैं (जो कि बहुत कुछ है, जो जेडब्ल्यूटी कोर टोकन को चोरी करने से बहुत खराब है)। XW से पहले से ही होने वाले संभावित नुकसान को बढ़ाने के लिए लोकलस्टोरेज में JWTs को स्टोर करना बहुत कम है।

— कार्ल लेथ

Answer 4

यदि आप CDN का उपयोग करते हैं तो यह सुरक्षित नहीं है:

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

तूफान के माध्यम से

किसी भी स्क्रिप्ट की आपको बाहर से आवश्यकता होती है, संभावित रूप से समझौता किया जा सकता है और अपने ग्राहक के भंडारण से किसी भी JWTS को हड़प सकता है और हमलावर के सर्वर पर व्यक्तिगत डेटा वापस भेज सकता है।

Comments

अगर मैं cdns का उपयोग करने की योजना नहीं बनाता तो क्या यह सुरक्षित होगा?

लेख के लेखक ने सीडीएन के माध्यम से या सीधे केंद्रीय सर्वर से सेवा प्राप्त साइटों पर एक्सएसएस के बीच कोई अंतर नहीं किया। क्या आपका स्पष्टीकरण यहाँ भी लागू नहीं होगा, न केवल सीडीएन के लिए?

— Vlad

Answer 5

स्थानीय डिज़ाइन को जावास्क्रिप्ट द्वारा सुलभ होने के लिए डिज़ाइन किया गया है, इसलिए यह कोई XSS सुरक्षा प्रदान नहीं करता है। जैसा कि अन्य उत्तरों में उल्लेख किया गया है, XSS हमले करने के संभावित तरीकों का एक गुच्छा है, जिसमें से स्थानीयस्टोर डिफ़ॉल्ट रूप से संरक्षित नहीं है।

हालाँकि, कुकीज़ में सुरक्षा झंडे होते हैं जो XSS और CSRF हमलों से बचाते हैं। HttpOnly ध्वज क्लाइंट साइड जावास्क्रिप्ट को कुकी तक पहुंचने से रोकता है, सुरक्षित ध्वज केवल ब्राउज़र को कुकी को ssl के माध्यम से स्थानांतरित करने की अनुमति देता है, और सेमसाइट ध्वज यह सुनिश्चित करता है कि कुकी मूल में ही भेजी जाए। हालाँकि, मैंने अभी जाँच की है और सेमसाइट वर्तमान में केवल ओपेरा और क्रोम में समर्थित है, इसलिए CSRF से बचाव के लिए अन्य रणनीतियों का उपयोग करना बेहतर है। उदाहरण के लिए, किसी अन्य उपयोगकर्ता डेटा के साथ किसी अन्य कुकी में एन्क्रिप्टेड टोकन भेजना।

इसलिए प्रमाणीकरण डेटा संग्रहीत करने के लिए कुकीज़ अधिक सुरक्षित विकल्प हैं।

Comments

खिचड़ी भाषा: HttpOnly CSRF से आपकी रक्षा कैसे कर सकता है?

— एलेक्स लयालका

@AlexLyalka कहने का मतलब यह नहीं था कि HttpOnly CSRF से बचाता है, बल्कि सभी कुकी झंडे XSS और CSRF से सुरक्षित कर सकते हैं। सेमसाइट कुछ सुरक्षा प्रदान करता है, जो कुकीज़ को मूल से अलग किसी साइट पर भेजे जाने से रोकता है। हालाँकि मैंने अभी जाँच की है और उस झंडे के लिए समर्थन बहुत कम है। CSRF से कुछ उपयोगकर्ता पहचान के साथ एक अलग एन्क्रिप्टेड टोकन से बचना भी संभव है, जिसे सर्वर पर जांचा जाता है।

— इवान

ठीक है, अगर कोई आपके वेब में कोड निष्पादित कर सकता है, तो वह आपके उपयोगकर्ता के नाम पर वेब पोस्ट करने के लिए बस एक पोस्ट नहीं कर सकता है? ठीक है, वह आपकी http केवल कुकीज़ प्राप्त नहीं कर सकता, लेकिन वह उन कुकीज़ का उपयोग करके कॉल कर सकता है, इसलिए मैं अभी भी नहीं देख पा रहा हूं

— Borja Alvarez

@BorjaAlverez एक बड़ा अंतर है। हां, XSS के माध्यम से कोई लॉग-इन उपयोगकर्ता की ओर से अनुरोध कर सकता है, लेकिन टोकन से समझौता करना बदतर है। उदाहरण के लिए: टोकन एपीआई तक पहुंच प्रदान कर सकता है जो क्लाइंट एप्लिकेशन का उपयोग नहीं करता है; टोकन में उपयोगकर्ता (ईमेल पता, प्रोफ़ाइल और अनुदान) के बारे में अन्य जानकारी हो सकती है; टोकन का उपयोग आपके एप्लिकेशन के खिलाफ पुनरावृत्ति के हमलों में किया जा सकता है; टोकन को id_token_hintओआईडीसी ऑर्टिकल सर्वर के रूप में पारित किया जा सकता है ; टोकन साइपर के बारे में एक हमलावर जानकारी प्रदान करता है जो इसे हस्ताक्षर करने के लिए इस्तेमाल किया गया था; आदि

— avejidah

Answer 6

इसे देखने का एक तरीका जोखिम या नुकसान के स्तर पर विचार करना है।

क्या आप बिना उपयोगकर्ताओं, POC / MVP के कोई ऐप बना रहे हैं? क्या आप एक स्टार्टअप हैं जिसे बाजार में उतरने और अपने ऐप का परीक्षण करने की आवश्यकता है? यदि हां, तो मैं शायद सबसे सरल समाधान को लागू करूंगा और उत्पाद-बाजार-फिट को खोजने पर ध्यान केंद्रित करूंगा। स्थानीयस्टोरेज का उपयोग करें क्योंकि इसे लागू करने में अक्सर आसान होता है।

क्या आप कई दैनिक सक्रिय उपयोगकर्ताओं या किसी ऐसे ऐप के साथ v2 का निर्माण कर रहे हैं, जिस पर लोग / व्यवसाय बहुत अधिक निर्भर हैं। हैक होने का मतलब होगा कि वसूली के लिए बहुत कम या कोई जगह नहीं है? यदि ऐसा है, तो मैं आपकी निर्भरता पर एक लंबा नज़र डालूंगा और http-केवल कुकी में टोकन जानकारी संग्रहीत करने पर विचार करूंगा।

लोकलस्टोरेज और कुकी / सेशन स्टोरेज दोनों का उपयोग करने के अपने-अपने पेशेवरों और विपक्ष हैं।

जैसा कि पहले उत्तर में कहा गया है: यदि आपके आवेदन में XSS भेद्यता है, तो न तो आपके उपयोगकर्ता की रक्षा करेगा। चूंकि अधिकांश आधुनिक अनुप्रयोगों में एक दर्जन या अधिक विभिन्न निर्भरताएं होती हैं, इसलिए यह गारंटी देना कठिन हो जाता है कि आपके आवेदन की निर्भरता में से कोई भी XSS असुरक्षित नहीं है।

यदि आपके आवेदन में XSS भेद्यता है और एक हैकर इसका फायदा उठाने में सक्षम है, तो हैकर आपके उपयोगकर्ता की ओर से कार्रवाई कर सकेगा। हैकर लोकलस्टोरेज से टोकन प्राप्त करके GET / POST अनुरोध कर सकता है या टोकन केवल HTTP-केवल कुकी में संग्रहीत होने पर POST अनुरोध कर सकता है।

स्थानीय संग्रहण में आपके टोकन को संग्रहीत करने का एकमात्र पक्ष यह है कि हैकर आपके टोकन को पढ़ सकेगा।

Answer 7

न तो लोकलस्टोरीज या httpOnly कुकी स्वीकार्य है? एक समझौता किए गए तीसरे पक्ष के पुस्तकालय के संबंध में, एकमात्र समाधान जो मुझे पता है कि संवेदनशील जानकारी को चोरी होने से कम / रोक देगा, सबस्रोसिटी इंटीग्रिटी लागू किया जाएगा ।

Subresource Integrity (SRI) एक सुरक्षा सुविधा है जो ब्राउज़रों को यह सत्यापित करने में सक्षम बनाती है कि वे जो संसाधन लाते हैं (उदाहरण के लिए, एक CDN से) वे बिना किसी अप्रत्याशित हेरफेर के वितरित किए जाते हैं। यह आपको एक क्रिप्टोग्राफिक हैश प्रदान करने की अनुमति देता है जो एक भ्रूण संसाधन से मेल खाना चाहिए।

जब तक समझौता किया गया 3 पार्टी लाइब्रेरी आपकी वेबसाइट पर सक्रिय रहता है, तब तक एक keylogger उपयोगकर्ता नाम, पासवर्ड जैसी जानकारी एकत्र करना शुरू कर सकता है, और जो भी आप साइट पर इनपुट करते हैं।

HttpOnly कुकी दूसरे कंप्यूटर से एक्सेस को रोकेगी लेकिन हैकर को उपयोगकर्ता के कंप्यूटर से छेड़छाड़ करने से रोकने के लिए कुछ नहीं करेगी।

Answer 8

जब तक आप इसे एन्क्रिप्ट करते हैं, तब तक लोकलस्टोरेज में अपना टोकन स्टोर करना सुरक्षित होता है। नीचे एक संपीड़ित कोड स्निपेट दिखाया गया है, जिसमें से कई तरीके आप कर सकते हैं।

    import SimpleCrypto from 'simple-crypto-js';

    const saveToken = (token = '') => {
          const encryptInit = new SimpleCrypto('PRIVATE_KEY_STORED_IN_ENV_FILE');
          const encryptedToken = encryptInit.encrypt(token);

          localStorage.setItem('token', encryptedToken);
     }

फिर, अपने टोकन का उपयोग करने से पहले इसे उपयोग करके डिक्रिप्ट करें PRIVATE_KEY_STORED_IN_ENV_FILE

Comments

@HassanAlthaf आप यहां बिंदु को याद कर रहे हैं, कभी भी 100% सुरक्षित प्रूफ ऐप नहीं होगा, यह सिर्फ इतना है, आप हमले की सतह को कम कर रहे हैं और कम से कम env फ़ाइल को सीधे जीथब पर प्रकाशित नहीं किया जाएगा। साथ ही, बंडल किए गए कोड को अव्यवस्थित और व्यवस्थित किया जाएगा, जिससे हमलावरों को ढूंढना मुश्किल हो जाएगा।

— किदली केविन

निजी कुंजी को उजागर नहीं किया जाना चाहिए। आप संपूर्ण API से समझौता करेंगे।

— हसन अल्ताफ

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

— किदली केविन