2008-12-03 9 views
13

हम क्लाइंट के लिए जावा वेब सेवा विकसित करने में व्यस्त हैं। दो संभावित विकल्प हैं:जावा - कॉन्फ़िगरेशन फ़ाइल से उपयोगकर्ता नाम और पासवर्ड एन्क्रिप्ट/डिक्रिप्ट करें

  • वेब सेवा क्लाइंट पर एन्क्रिप्टेड उपयोगकर्ता नाम/पासवर्ड स्टोर करें। एक विन्यास से पढ़ें। ग्राहक पक्ष पर फ़ाइल, डिक्रिप्ट और भेजें।

  • वेब सर्वर पर एन्क्रिप्टेड उपयोगकर्ता नाम/पासवर्ड स्टोर करें। एक विन्यास से पढ़ें। वेब सर्वर पर फ़ाइल, डिक्रिप्ट और वेब सेवा में उपयोग करें।

उपयोगकर्ता नाम/पासवर्ड किसी तीसरे पक्ष के आवेदन तक पहुंचने के लिए वेब सेवा द्वारा उपयोग किया जाता है।

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

इसलिए हमें जावा में कुछ तेज़ और आसान चाहिए।

कोई सिफारिशें?

सर्वर टॉमकट 5.5 है। वेब सेवा एक्सिस 2 है।

  • क्या एन्क्रिप्ट/डिक्रिप्ट पैकेज का उपयोग करना चाहिए?
  • एक प्रमुख स्टोर के बारे में क्या?
  • हम किस कॉन्फ़िगरेशन तंत्र का उपयोग करना चाहिए?
  • क्या यह तैनात करना आसान होगा?

उत्तर

18

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

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

अपने वेब सर्वर से परे तीसरे पक्ष के पासवर्ड को वितरित न करें।

ऐसा करने का सबसे सुरक्षित तरीका यह है कि इसे वेब एप्लिकेशन को अंतःक्रियात्मक रूप से प्रदान किया जाए। यह ServletContextListener हो सकता है जो एप्लिकेशन के रूप में पासवर्ड के लिए संकेत देता है, या एप्लिकेशन में एक पृष्ठ ताकि एक व्यवस्थापक इसे फ़ॉर्म के माध्यम से दर्ज कर सके। पासवर्ड ServletContext में संग्रहीत किया जाता है और तृतीय-पक्ष सेवा के अनुरोधों को प्रमाणीकृत करने के लिए उपयोग किया जाता है।

सुरक्षा में एक कदम नीचे सर्वर की फ़ाइल सिस्टम पर पासवर्ड स्टोर करना है ताकि यह केवल सर्वर चलाने वाले उपयोगकर्ता द्वारा पठनीय हो। यह सुरक्षा के लिए सर्वर की फ़ाइल सिस्टम अनुमतियों पर निर्भर करता है।

क्लाइंट या सर्वर पर पासवर्ड के एन्क्रिप्टेड रूप को स्टोर करने का प्रयास कर रहा है, बस एक कदम पीछे ले जा रहा है। एक रहस्य के साथ एक रहस्य की रक्षा करने की कोशिश करते समय आप एक अनंत वापसी में पड़ जाते हैं।

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

ग्राहकों के प्रमाण-पत्रों की सुरक्षा के लिए, क्लाइंट और आपके वेब सर्वर के बीच चैनल SSL के साथ सुरक्षित होना चाहिए। यहां, इंट्रानेट पर चलना फायदेमंद है, क्योंकि आप सर्वर पर एक स्व-हस्ताक्षरित प्रमाणपत्र का उपयोग कर सकते हैं।

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

24

जैसा कि मैं किसी भी तरह से तृतीय पक्ष वेब सेवा को कॉल करने के लिए समझता हूं, आप सादे पाठ के रूप में पासवर्ड पास करते हैं और कोई सुरक्षा प्रमाणपत्र शामिल नहीं होते हैं।

तब मैं कहूंगा कि एन्क्रिप्टेड प्रारूप (जावा एन्क्रिप्शन तंत्र के माध्यम से) में पासवर्ड स्टोर करना सबसे आसान तरीका होगा जब एन्क्रिप्शन/डिक्रिप्शन कुंजी कोड में कड़ी मेहनत की जाती है।

मैं निश्चित रूप से इसे सर्वर पक्ष (फ़ाइल सिस्टम या डीबी) पर संग्रहीत करता हूं बल्कि इसे एकाधिक ग्राहकों पर वितरित और बनाए रखता हूं।

// only the first 8 Bytes of the constructor argument are used 
// as material for generating the keySpec 
DESKeySpec keySpec = new DESKeySpec("YourSecr".getBytes("UTF8")); 
SecretKeyFactory keyFactory = SecretKeyFactory.getInstance("DES"); 
SecretKey key = keyFactory.generateSecret(keySpec); 
sun.misc.BASE64Encoder base64encoder = new BASE64Encoder(); 
sun.misc.BASE64Decoder base64decoder = new BASE64Decoder(); 
......... 

// ENCODE plainTextPassword String 
byte[] cleartext = plainTextPassword.getBytes("UTF8");  

Cipher cipher = Cipher.getInstance("DES"); // cipher is not thread safe 
cipher.init(Cipher.ENCRYPT_MODE, key); 
String encrypedPwd = base64encoder.encode(cipher.doFinal(cleartext)); 
// now you can store it 
...... 

// DECODE encryptedPwd String 
byte[] encrypedPwdBytes = base64decoder.decodeBuffer(encryptedPwd); 

Cipher cipher = Cipher.getInstance("DES");// cipher is not thread safe 
cipher.init(Cipher.DECRYPT_MODE, key); 
byte[] plainTextPwdBytes = (cipher.doFinal(encrypedPwdBytes)); 
+0

कहाँ "अपनी गुप्त कुंजी वाक्यांश" से आता है:

यहाँ कैसे है कि "डेस" एन्क्रिप्शन के साथ काम कर सकता है? यदि वह स्रोत सुरक्षित है, तो वास्तविक पासवर्ड रखने के लिए इसका उपयोग क्यों न करें? – erickson

+0

जैसा कि मैंने उल्लेख किया है कि मुख्य वाक्यांश जावा क्लास में हार्डकोड किया गया है, वैकल्पिक रूप से इसे डेटा बेस में संग्रहीत किया जा सकता है। पासवर्ड बदलने के दौरान पासवर्ड का उपयोग करने के लिए कोड को फिर से संकलित करने की आवश्यकता होगी। –

+3

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

संबंधित मुद्दे

 संबंधित मुद्दे