बाद में पुन: कनेक्ट करने के लिए जावा क्लाइंट में सर्वर पासवर्ड कैसे स्टोर करें?

Question

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

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

क्या एक ही चीज़ प्राप्त करने का एक बेहतर/पसंदीदा तरीका है (यानी क्लाइंट को प्रारंभिक लॉगिन के बाद उपयोगकर्ता को अपना पासवर्ड दर्ज करने की आवश्यकता के बिना सर्वर से फिर से कनेक्ट करने की इजाजत देता है)? क्या सर्वर से भेजे गए एक समाप्ति लॉगिन टोकन जाने का एक बेहतर तरीका होगा (जहां मैं इस समाप्ति टोकन को फिर से कनेक्ट करने के बजाय पासवर्ड के बजाय सर्वर पर भेज सकता हूं)?

आखिरकार, सामान्य रूप से, किसी के लिए जावा डेस्कटॉप या एंड्रॉइड पर चल रहे एप्लिकेशन में डीबगर कनेक्ट करने के लिए कितना आसान है, जब एप्लिकेशन डिबगिंग प्रतीकों का सही ढंग से 'छीन लिया' है? क्या मुझे इस मामले के बारे में भी चिंता करने की ज़रूरत है, या जावा मेरे शिपिंग एप्लिकेशन को डिबगर, या अन्य मेमोरी विश्लेषक से बचाने के लिए संलग्न करेगा?

Answer 1

आप अपने आवेदन में एक (सिस्टम-व्यापी) कुंजी लॉगर के खिलाफ कुछ भी नहीं कर सकते हैं। इसलिए स्मृति में पासवर्ड संग्रह करना खतरनाक है लेकिन सत्र टोकन से कम जोखिम भरा है:

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

Answer 2

यदि कोई डीबगर में एप्लिकेशन तक पहुंच प्राप्त करता है तो एक हैकर पासवर्ड पुनर्प्राप्त कर सकता है।

सही। जब उपयोगकर्ता उपयोगकर्ता के भौतिक आंखों के साथ उपयोगकर्ता के भौतिक कंधे को देखकर उपयोगकर्ता प्रकार को देखता है तो हैकर को पासवर्ड तक पहुंच होती है।

और उपयोगकर्ता कंप्यूटर पर एक कीलॉगर स्टोर करने के बाद हैकर का उपयोग होता है।

क्या यह जीवन का एक तथ्य है जब किसी को ग्राहक को अस्थायी समय के लिए पासवर्ड स्टोर करने की आवश्यकता होती है?

सं

विकल्प आप व्यक्तिगत रूप से प्रत्येक उपयोगकर्ता पर जाएँ और उन्हें नहीं बता सुरक्षा को तोड़ने के लिए डिबगर का उपयोग करने के लिए है।

चलो बस उस केस के बारे में सोचें जहां उपयोगकर्ता (जो पासवर्ड जानता है) पासवर्ड सीखने के लिए डीबगर में एप्लिकेशन को सक्रिय करता है। जो वे पहले से ही जानते थे।

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

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

,

नहीं

वास्तव में

या जावा एक डिबगर, या अन्य स्मृति विश्लेषक होने से मेरे शिपिंग आवेदन की रक्षा करेगा मैं भी इस मामले के बारे में चिंता करने की ज़रूरत है, यह करने के लिए संलग्न ?

नहीं, जावा आपके उपयोगकर्ताओं की सुरक्षा नहीं करता है। सामान्य ज्ञान आपके उपयोगकर्ताओं की सुरक्षा करता है।

यदि कोई डीबगर चल रहा है, तो उन्हें कंप्यूटर का उपयोग नहीं करना चाहिए।

और 99% समय, उन्हें डीबगर शुरू नहीं होगा।

उस समय का 1%, वे गलती से डीबगर चलाएंगे - क्योंकि उपयोगकर्ता यादृच्छिक आइकन पर क्लिक करते हैं। उनमें से 1% वास्तव में आपके आवेदन को डीबगर के तहत चलाने के लिए प्राप्त करेंगे। फिर, यादृच्छिक आइकन पर क्लिक करके। उनमें से 1% वास्तव में उस स्थान पर पहुंच जाएंगे जहां वे स्क्रीन पर यादृच्छिक आइकन क्लिक करके पासवर्ड टाइप कर सकते हैं।

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

---

यह एक मैन-इन-द-बीच हमले या रिमोट कंट्रोल हमले से पूरी तरह से अलग है।

अगर कोई आपके उपयोगकर्ता के कंप्यूटर पर रिमोट कंट्रोल लेता है, तो डीबगर चलाता है, और लेनदेन देखता है, जो पूरी तरह से अलग है। यह फ़ायरवॉल और ऑपरेटिंग सिस्टम द्वारा रोक दिया गया है। जावा नहीं

---

एक KeyStore में डाल दिया और पुनः कनेक्ट

सब क्या तुमने कभी क्या कर सकते हैं कि के लिए बाद में इसे पुनः प्राप्त। "एक डीबगर कनेक्ट करें" परिदृश्य को आपके अनुप्रयोगों से रोका नहीं जा सकता है। यह उपयोगकर्ता को चेतावनी देने के लिए ओएस का काम है कि एक डीबगर जुड़ा हुआ है।

यदि आप देयता के बारे में चिंतित हैं, तो पासवर्ड स्टोर न करें। देयता का अंत

Answer 3

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

आपके द्वारा सरलता से क्या मतलब है इस पर निर्भर करता है। मुझे लगता है कि जावा अनुप्रयोगों को डीबग करना आसान है, भले ही वे डिबगिंग प्रतीकों को छीन लें। अगर वे obfuscated हैं तो भी उन्हें डीबग करने में सक्षम हो सकता है।