मुझे एक डीबी पासवर्ड को एन्क्रिप्टेड स्ट्रिंग के रूप में सहेजने की आवश्यकता है और फिर कनेक्ट करने से पहले डिक्रिप्ट करना होगा।जावा दो तरह एन्क्रिप्शन लाइब्रेरी
क्या कोई मुझे जावा में एक अच्छी दो-तरफा एन्क्रिप्शन लाइब्रेरी का संदर्भ दे सकता है?
दान, इस धागे पर एक नज़र डालें क्योंकि जावा के एपीआई के माध्यम से एक संपत्ति फ़ाइल में ऐसा करने के बारे में कुछ उपयोगी जानकारी है।
सुरक्षा Base64 एन्कोडिंग का वास्तविक रूप में लगभग रूप में किसी भी "हार्ड" एन्क्रिप्शन के रूप में अच्छा होगा।
(टिप्पणी में विवाद :)।)
संपादित करें: ठीक है, हाल ही में downvote मुझे वापस यहाँ कुछ शब्द जोड़ने के लिए लाया।
उपरोक्त कथन है कि यह असंभव कुछ अन्य पार्टी के लिए एक सुरक्षित तरीके से किसी भी स्वचालित गतिविधि प्रमाणित है लोगों को याद दिलाने के लिए है। यदि आप किसी संग्रहीत पासवर्ड को एन्क्रिप्ट और डिक्रिप्ट करने के लिए पासवर्ड का उपयोग करेंगे, तो आप यह नया पासवर्ड कहां स्टोर करेंगे? आसान! दूसरे पासवर्ड को सुरक्षित रूप से स्टोर करने के लिए बस एक तिहाई पासवर्ड बनाएं और इसी तरह।
प्वाइंट है: कुछ स्वचालित प्रक्रिया द्वारा डिक्रिप्ट करने योग्य कोई भी पासवर्ड वास्तव में एन्क्रिप्टेड नहीं है बल्कि केवल obfuscated है। इस प्रकार, एन्क्रिप्शन पहली जगह व्यर्थ है।
यह सही नहीं है, लेकिन अभी भी बेहतर है। आप सही हैं कि आपको पासवर्ड के शीर्ष पर पासवर्ड जोड़ना होगा ... लेकिन इसे सादे दृष्टि में छोड़ना और भी खराब हो सकता है। मान लें कि आप उपयोगकर्ताओं की ओर से प्रमाणीकृत करने के लिए बाहरी सेवा के लिए पासवर्ड संग्रहीत कर रहे थे। यदि आपने इसे सादे टेक्स्ट में संग्रहीत किया है और आपका डेटाबेस (केवल) उल्लंघन किया गया है, तो वे पासवर्ड प्राप्त करेंगे। यदि आपने उन्हें एन्क्रिप्ट किया है और फ़ाइल में संग्रहीत कुंजी (और रनटाइम पर ऐप मेमोरी) थी और डेटाबेस (केवल) का उल्लंघन किया गया था, तो हमलावर को डिक्रिप्शन कुंजी को बल देना होगा। रिकॉर्ड प्रति नमक का उपयोग करके उन्हें और भी धीमा कर दिया जाएगा। –
बेशक आप सही हैं। फिर भी, आप कहते हैं "और फ़ाइल में एक कुंजी संग्रहित थी" ... और यदि वह फ़ाइल एक दिन इंटरनेट पर यात्रा लेती है तो यह सब फिर से चला गया है।मुझे लगता है कि यह आवश्यक जानकारी को कुछ हद तक विभाजित करने के लिए सबसे अच्छा प्रयास तकनीक तक उबालता है और उम्मीद करता है कि किसी को भी * सभी * व्यक्तिगत भागों पर कोई झलक नहीं मिलती है। – JimmyB
निश्चित बात, पूरी तरह से सहमत हैं! –
आमतौर पर पासवर्ड हैश के रूप में रखा जाता है, इसलिए वास्तविक पासवर्ड प्राप्त करने की प्रक्रिया संभव नहीं है, हम इसे वापस परिवर्तित करने के अलावा, हम पासवर्ड उपयोगकर्ता को हैश में दर्ज करते हैं और फिर उनसे मेल खाते हैं। यदि आप अपने उपयोग के बारे में अधिक जानकारी दे सकते हैं तो यह स्पष्ट होगा
भी हैशिंग और एन्क्रिप्शन दो चीजें हैं, लिप्यंतरण एक ऐसा रूप है जहां आप वापस परिवर्तित कर सकते हैं लेकिन हैशिंग एक तरह से सड़क है। –
यदि आप पासवर्ड-आधारित एन्क्रिप्शन (दो-तरफा तकनीक) का उपयोग करके अपने पासवर्ड एन्क्रिप्ट करते हैं और एक हमलावर को आपका एन्क्रिप्शन पासवर्ड पता होता है, तो आपके सभी उपयोगकर्ता पासवर्ड होंगे पता चला (और, शायद, एक समय में सभी)। यदि आपके पास डिक्रिप्ट करने में सक्षम होने के लिए ऐसा एन्क्रिप्शन पासवर्ड (या कुंजी) नहीं है, तो यह जोखिम गायब हो जाता है, और हमलावर को ब्रूट फोर्स या इसी तरह की रणनीतियों पर भरोसा करना होगा। मिला [यहां] (http://www.jasypt.org/howtoencryptuserpasswords.html) – AndroidHustle
यह सही है। पासवर्ड हमेशा [_hashed_] होना चाहिए (http://en.wikipedia.org/wiki/Hash) और एन्क्रिप्ट नहीं किया जाना चाहिए। – dwalldorf
@entek: मुझे लगता है कि आप इस सवाल को गलत समझते हैं, जैसा कि मैंने इसे पढ़ा है, यह उपयोगकर्ता पासवर्ड संग्रहीत करने के बारे में नहीं है, बल्कि डेटाबेस तक पहुंचने के लिए पासवर्ड है। कनेक्ट करने के लिए आपको डीबी उपयोगकर्ता और पासवर्ड की आवश्यकता होगी। अब, एक वेब एप्लिकेशन के लिए इसे जेएनडीआई-संसाधनों के माध्यम से ऐप-सर्वर द्वारा संभाला जाना चाहिए और पासवर्ड को सुरक्षित रूप से संग्रहीत करना चाहिए, लेकिन यदि आप एक सादा ओल्ड जावा ऐप लिख रहे हैं, जो जेडीबीसी के माध्यम से डीबी तक पहुंचता है, तो आपको कहीं भी पासवर्ड की आवश्यकता होगी । और इसे सादे पाठ में छोड़ना ऐसा करने का तरीका नहीं है, इसलिए पासवर्ड को एन्क्रिप्शन निश्चित रूप से वैध उपयोग केस है ... – beny23