जावा कोड के अंदर पासवर्ड एम्बेड करने का सबसे सुरक्षित तरीका क्या है?

Question

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

यदि कुछ तरीकों से दूसरों के मुकाबले बेहतर है (उदाहरण के लिए: जेपीएस्वर्डफिल्ड स्ट्रिंग के बजाए एक चार सरणी में पासवर्ड स्टोर करता है) और यदि आपको जावा एप्लिकेशन में हार्ड कोड करना पड़ा, तो इसे कठिन बनाने के लिए आप क्या उपाय कर सकते हैं लाने के लिए?

अद्यतन:

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

Answer 1

.... अगर आप जावा आवेदन में कठिन कोड यह करना पड़ा , इसे लाने में कठोर बनाने के लिए आप क्या उपाय कर सकते हैं?

एक शुरुआत के लिए, मैं बहुत यकीन है कि यह बुरा निर्णय लेने के लिए प्रबंधन की जिम्मेदारी के साथ व्यक्ति पूरी तरह से पता है कि इस मौलिक और irredeemably असुरक्षित है होगा।

तो शायद मैं कुछ naff एल्गोरिदम सोचता हूं जो पासवर्ड को अस्पष्ट तरीके से इकट्ठा करता है; जैसेदो बाइट एरे बनाने और उन्हें एक साथ XORing करके ... और obfuscated बाइटकोड वितरित। सबसे अच्छा आप ऐसा करने की उम्मीद कर सकते हैं कि सीमित कोड वाले लोगों के लिए अपने कोड से पासवर्ड इंजीनियर को रिवर्स करना मुश्किल हो।

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

^{1 ... और यह भी कि जॉन स्कीट इसे सुरक्षित बनाने में सक्षम नहीं होगा।}

---

कुछ मायनों दूसरों से बेहतर (उदाहरण के लिए: JPasswordField भंडार एक स्ट्रिंग के बजाय एक चार सरणी में पासवर्ड) कर रहे हैं ...

मैं बस ध्यान दें कि चाहते हैं सामान्य JPasswordField में पासवर्ड रखने के लिए एक चार सरणी का उपयोग करने के लिए तर्क और इसी तरह कोर डंप या स्वैप फ़ाइलों से पासवर्ड पढ़ने वाले बुरे लोगों के खिलाफ सुरक्षा करना है। यह वास्तव में इस मामले में मदद नहीं करेगा क्योंकि हमें यह मानना ​​है कि बुरे व्यक्ति के पास JVM में डीबगर संलग्न करने और चार सरणी से बाइट्स को कैप्चर करने के लिए पर्याप्त नियंत्रण है।

Answer 2

आप पासवर्ड हैश कर सकते हैं और यदि चाहें तो इसे एन्क्रिप्ट भी कर सकते हैं। इस पोस्ट पर एक नज़र डालें, यह उपयोगी हो सकता है। Java - encrypt/decrypt user name and password from a configuration file

Answer 3

एक सामान्य दिशानिर्देश के रूप में आपको कभी भी पासवर्ड (निश्चित रूप से) स्टोर नहीं करना चाहिए।

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

मुझे नहीं पता कि यह आपके मामले में व्यवहार्य है, लेकिन आपको इसकी ओर लक्षित करना चाहिए।

Answer 4

मुझे लगता है कि कम से कम गैर-आदर्श समाधान है, यदि आप इसमें यादृच्छिक तत्व के साथ चुनौती-आधारित प्रमाणीकरण प्रोटोकॉल कर सकते हैं।

इस तरह यह सिर्फ पासवर्ड नहीं है, यह भी कोड है जो सही प्रतिक्रियाओं, जो किया जा रिवर्स इंजीनियर की जरूरत है उत्पन्न करने के लिए पासवर्ड का उपयोग करता है।

तो यह भी दो तरह प्रमाणीकरण हो सकता है, कि अपने अंत है कि दूसरे पक्ष के भी एक ही प्रोटोकॉल/एल्गोरिथ्म का उपयोग करता है और यह भी एक ही पासवर्ड है की पुष्टि कर सकते है।

और सबसे महत्वपूर्ण बात है, तो पासवर्ड नेटवर्क पर भेजी गई कभी नहीं है, इसलिए यह सूंघा नहीं किया जा सकता।

Diffie-Helman key exchange ऐसी चीज के लिए एक व्यापक रूप से प्रयुक्त प्रोटोकॉल है, लेकिन यदि आप केवल अस्पष्टता चाहते हैं, असली सुरक्षा नहीं, तो आप हमेशा अपना सरल कार्यान्वयन कर सकते हैं। खैर, असली सुरक्षा करता है, तो सब कुछ decompiled जा सकता है और बाईटकोड से रिवर्स-इंजीनियर, लेकिन वैसे भी अपनी पहुंच से बाहर स्पष्ट रूप से है ... :)

Answer 5

क्लाइंट पक्ष पर संवेदनशील डेटा को स्टोर करने के लिए बेहद असुरक्षित है, क्योंकि पासवर्ड के लिए विशेष रूप से .class फ़ाइलों को आसानी से डिस्प्ले किया जा सकता है। क्या आपने कभी कुछ असममित एन्क्रिप्शन सामग्री को शामिल करने के बारे में सोचा है? सार्वजनिक/निजी कुंजी जोड़ी या ऐसा कुछ पसंद है?

Answer 6

मैं स्टीफन जवाब पसंद है, लेकिन मैं जोड़ना होगा ...

स्रोत कोड की सुरक्षा भी महत्वपूर्ण है। कोई फर्क नहीं पड़ता कि आप पासवर्ड को खराब करने के लिए किस विधि का उपयोग करते हैं, स्रोत तक पहुंचने वाले किसी भी व्यक्ति को आसानी से System.out.println(password) डाल सकते हैं और पासवर्ड का उपयोग किया जा सकता है, या डीबग में कोड चलाएं और चर का निरीक्षण करने के लिए कोड को रोक दें।

यहां तक ​​कि संकलन के बिना, jar के उपयोग के साथ किसी को भी डिबग मोड में जावा कार्यक्रम शुरू करने और कार्यक्रम है जहाँ पासवर्ड प्रयोग किया जाता है को रोकने और बस जार के साथ चर, स्रोत कोड के साथ तुच्छ है, लेकिन अभी भी संभव निरीक्षण कर सकते हैं और कुछ उपकरण

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