DriverManager.getConnection क्यों नहीं (स्ट्रिंग यूआरएल, स्ट्रिंग उपयोगकर्ता, चार [] पासवर्ड)?

Question

हम जानते हैं कि java.lang पर char [] को पसंद करना एक अच्छा अभ्यास है। पासवर्ड स्टोर करने के लिए स्ट्रिंग। यह निम्नलिखित दो कारणों से है (जैसा कि मैंने पढ़ा है):

1. char [] mutable हैं ताकि हम उपयोग के बाद पासवर्ड साफ़ कर सकें।
2. स्ट्रिंग अक्षर एक पूल में जाता है जो अन्य वस्तुओं के रूप में एकत्रित कचरा नहीं लेता है, इसलिए स्मृति डंप में दिखाई दे सकता है।

लेकिन java.sql.DriverManager में getConnection() नहीं है जो उपरोक्त सर्वोत्तम अभ्यास का अनुपालन करता है क्योंकि इसका पासवर्ड पैरामीटर स्ट्रिंग है।

DriverManager.getConnection (स्ट्रिंग यूआरएल, स्ट्रिंग उपयोगकर्ता, स्ट्रिंग पासवर्ड)

मुझे लगता है कि एपीआई निम्नलिखित हस्ताक्षर के साथ एक ओवरलोड विधि होनी चाहिए:

DriverManager.getConnection (स्ट्रिंग यूआरएल, स्ट्रिंग उपयोगकर्ता, char [] पासवर्ड)

आप इस बारे में क्या सोचते हैं? क्या आप इस ड्रॉ को दूर करने के लिए कोई वैकल्पिक तरीका देखते हैं?

अपने विचार सुनना अच्छा लगेगा।

Answer 1

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

Answer 2

कोई केवल अनुमान लगा सकता है, जब तक आप एपीआई के डिजाइनर से नहीं पूछ सकते।

मुख्य एपीआई पासवर्ड के लिए String के बजाय char[] का उपयोग करता है कि मैं के बारे में पता JPasswordField है:

मेरे अटकलें यह है। ऐसा करने के लिए प्रोग्राम को मूल्यों का उपयोग करने के बाद उपयोगकर्ता द्वारा दर्ज किए गए पासवर्ड को अन्य मानों के साथ ओवरराइट करने की अनुमति देने के लिए ऐसा किया जाता है (जो String के साथ संभव नहीं है, जो कम से कम कम से कम मेमोरी-एकत्रित होने तक स्मृति में रुक जाएगा) ।

एक डेटाबेस से कनेक्ट करने के लिए इस्तेमाल पासवर्ड आमतौर पर नहीं उपयोगकर्ता के प्रवेश किया सबसे अनुप्रयोगों मुझे पता है, लेकिन विन्यास/निर्देशिका किसी तरह से आता है/...

कोई फर्क नहीं कहाँ से आता है: आवेदन एक बार यह ज्ञात नहीं होने के बाद इसे पुन: निर्माण करने में सक्षम है। उपयोगकर्ता द्वारा दर्ज किए गए पासवर्ड और प्रोग्रामेटिक रूप से अधिग्रहीत पासवर्ड के बीच यह बड़ा अंतर है।

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

</speculation>

Answer 3

आपका कारण # 2 है नहीं है एक मैंने स्ट्रिंग पर char [] के उपयोग के लिए सबसे अधिक सामान्य रूप से देखा है।हालांकि, आम तौर पर मुझे लगता है कि यदि आप मानते हैं कि किसी को आपके प्रोग्राम स्थिति में डीबगर या अन्य माध्यमों के माध्यम से पहुंच है, तो कोई कारण नहीं है कि वे char [] की सामग्री को भी नहीं देख सकते हैं।

Answer 4

char [] arrays का उपयोग करने का तर्क सबसे अधिक लागू होता है जहां उपयोगकर्ता पासवर्ड टाइप करता है, और आप उस पासवर्ड के संपर्क को कम करना चाहते हैं।

जेडीबीसी कनेक्शन लगभग कभी ऐसा नहीं होते हैं। पासवर्ड कुछ कॉन्फ़िगरेशन फ़ाइल में संग्रहीत किया जाता है, शायद obfuscated, और स्मृति पढ़ने की क्षमता की तुलना में एक रिसाव का एक बड़ा स्रोत है।

वैसे भी, जेडीबीसी मानक गुण वस्तुओं और यहां तक ​​कि यूआरएल में पासवर्ड पास करने की अनुमति देता है, इसलिए मुझे लगता है कि char[] पासवर्ड पैरामीटर आपको सुरक्षा की झूठी भावना देगा।

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

Answer 5

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

तो अगर आपको लगता है कि आपको अपने पासवर्ड को char में स्टोर करना होगा [] आप getConnection() को कॉल करने से पहले भी एक स्ट्रिंग ऑब्जेक्ट बना सकते हैं। यदि चालक कार्यान्वयन स्ट्रिंग ऑब्जेक्ट को आंतरिक रूप से संग्रहीत नहीं करता है तो यह जल्द से जल्द पहुंच योग्य नहीं होगा और इस प्रकार बहुत तेजी से एकत्रित हो जाएगा। अभी भी इसे वापस पढ़ने का एकमात्र मौका है कि सीधे जेवीएम की स्मृति की जांच करें जहां यह अभी भी मौजूद हो। तो आप सही हैं कि एक char [] का उपयोग थोड़ा और अधिक सुरक्षित होगा, लेकिन कुछ भी बिंदु पर पासवर्ड को स्मृति में होना आवश्यक नहीं होगा।

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

Answer 6

आप एक अच्छा मुद्दा बनाते हैं, और अधिकांश लोग इसका जवाब दे रहे हैं। सबसे बुरी स्थिति परिदृश्य यह है कि ओएस द्वारा "अस्थायी" पासवर्ड को आपके द्वारा स्पष्ट पाठ दिमाग में बदल दिया गया है। इसके बाद, यह स्वैप फ़ाइल आसानी से पढ़ी जाती है, और डिस्क पर भी ज़ीरो द्वारा ओवरराइट किया जा सकता है यदि हमलावर के पास लगभग 1500 उपकरण हैं ...

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

किसी भी तरह से ...

• आप वर्तमान में संभव नहीं है क्या पूछना है, लेकिन अच्छा होगा।
• यहां तक ​​कि चार [] कुछ शर्तों (जैसे स्वैपिंग) से बच सकते हैं।
• आपका पासवर्ड डेटाबेस के रास्ते पर कई बार कॉपी हो जाएगा, इसलिए char [] समस्या का केवल एक हिस्सा हल करता है।

वास्तविकता यह है कि जब तक मंच विशेष रूप से सुरक्षा के लिए डिज़ाइन नहीं किया जाता है, तो सभी विधियां केवल रणनीति में देरी कर रही हैं।करो, आप क्या कर सकते हैं, लेकिन यदि निर्धारित व्यक्ति आपकी मशीन तक पहुंच प्राप्त कर सकता है, तो char [] आपको 1 घंटे अधिकतम प्राप्त करेगा।