2015-01-30 38 views
7

व्यूस्टेट को एन्क्रिप्ट करने के संबंध में मुझे मिले सभी संदर्भ पृष्ठों में, पासवर्ड पर एकमात्र टिप्पणी "आपका पासवर्ड यहां" है।com.sun.faces.ClientStateSavingPassword - वास्तविक पासवर्ड के लिए सिफारिशें?

क्या पासवर्ड की लंबाई/जटिलता के बारे में कोई सिफारिशें हैं जिनका हमें उपयोग करना चाहिए?

उत्तर

16

Mojarra संस्करण पर निर्भर करता है। पिछले संस्करणों में इसकी कई त्रुटियां/विफल रही थीं।

मोजररा 1.2.x - 2.1.18, इसका वास्तव में उपयोग नहीं किया गया था। जेएनडीआई प्रवेश नाम अर्थात् गलत तरीके से दस्तावेज किया गया था। यह documentedcom.sun.faces.ClientStateSavingPassword (Mojarra's other web.xml context parameters के समान उपसर्ग के साथ) था, लेकिन actually कोड ClientStateSavingPassword के लिए चेक करता है। इसके बाद आपको इसे उस नाम पर पंजीकृत करना चाहिए।

<env-entry> 
    <env-entry-name>ClientStateSavingPassword</env-entry-name> 
    <env-entry-type>java.lang.String</env-entry-type> 
    <env-entry-value>[Your Password]</env-entry-value> 
</env-entry> 

अन्यथा, ग्राहक राज्य वास्तव में एन्क्रिप्टेड नहीं है।

Mojarra 1.2.x में - 2.0.3, पासवर्ड एक DES algorithm key उत्पन्न करने के लिए एक SecureRandom seed के रूप में इस्तेमाल किया जा will। इसलिए, आम तौर पर, एक ही नियम "real world" passwords के रूप में लागू होते हैं। केवल, यह आसानी से compromised हो सकता है यदि पासवर्ड "बहुत आसान" है और हमलावर सफलतापूर्वक अनुमान लगाता है/पासवर्ड का आकलन/आंकड़े करता है।

में Mojarra 2.0.4 - 2.1.x, वे एईएस के लिए डेस से एल्गोरिथ्म और कोड changed अब नहीं actually प्रदान की पासवर्ड अब और का उपयोग कुंजी (संभावित comprisions रोकने के लिए) उत्पन्न करने के लिए करते हैं। इसके बजाए, एक पूरी तरह से यादृच्छिक कुंजी generated है, जो अधिक सुरक्षित है। जेएनडीआई प्रविष्टि अब मूल रूप से नियंत्रित करती है कि ग्राहक स्थिति को एन्क्रिप्ट किया जाना चाहिए या नहीं। दूसरे शब्दों में, यह अब एक बुलियन कॉन्फ़िगरेशन प्रविष्टि की तरह व्यवहार करता है। इस प्रकार यह बिल्कुल कोई फर्क नहीं पड़ता कि आप किस पासवर्ड का उपयोग करते हैं।

<env-entry> 
    <env-entry-name>ClientStateSavingPassword</env-entry-name> 
    <env-entry-type>java.lang.String</env-entry-type> 
    <env-entry-value>[Any value is interpreted as boolean=true to enable encryption]</env-entry-value> 
</env-entry> 

में Mojarra 2.1.19 - 2.1.x, वे पर JNDI प्रविष्टि नाम प्रलेखन संरेखित करने के लिए कोड fixed। तो अगर आप दस्तावेज JNDI प्रविष्टि नाम इस्तेमाल कर सकते हैं:,

<env-entry> 
    <env-entry-name>com.sun.faces.ClientStateSavingPassword</env-entry-name> 
    <env-entry-type>java.lang.String</env-entry-type> 
    <env-entry-value>[Any value is interpreted as boolean=true to enable encryption]</env-entry-value> 
</env-entry> 

हालांकि यह अभी भी एईएस कुंजी है, जो 2.0.4 के बाद से बदल गया था प्रभावित नहीं करता है, यह अभी भी मूल रूप से केवल एन्क्रिप्शन/अक्षम कर देता है सक्षम बनाता है।

में Mojarra 2.2.0 - 2.3.x, JSF 2.2 specification (7.8.2 अध्याय) के हिस्से के रूप में, ग्राहक के पक्ष राज्य अब डिफ़ॉल्ट always एन्क्रिप्टेड कर रहा है। यह केवल तभी अक्षम होगा जब web.xml संदर्भ पैरामीटर com.sun.faces.disableClientStateEncryption मूल्य true के साथ सेट किया गया है। यह still एईएस एल्गोरिदम का उपयोग completely random key के साथ करता है। जेएनडीआई प्रविष्टि com.sun.faces.ClientStateSavingPassword अब अब और उपयोग नहीं किया गया है।

में Mojarra 2.2.6 - 2.3.x, वे प्रति issue 3087 रूप में एक नया JNDI प्रविष्टि जो आप Base64 इनकोडिंग प्रारूप में एईएस कुंजी, the jsf/ClientSideSecretKey निर्दिष्ट कर सकते हैं जोड़ा।क्लाइंट साइड स्टेटस में विफल होने पर यह बगफिक्स का हिस्सा है जब क्लस्टर पर्यावरण में एक जेएसएफ वेबपैप का उपयोग किया जाता है, क्योंकि प्रत्येक सर्वर ने एक अलग एईएस कुंजी का उपयोग किया जो केवल ERROR: MAC did not verify! का कारण बनता है जब राज्य को सहेजने वाले किसी अन्य सर्वर से राज्य को पुनर्स्थापित किया जाता है , जैसा कि issue 2557 में वर्णित है।

<env-entry> 
    <env-entry-name>jsf/ClientSideSecretKey</env-entry-name> 
    <env-entry-type>java.lang.String</env-entry-type> 
    <env-entry-value>[AES key in Base64 format]</env-entry-value> 
</env-entry> 

आप इस AES key generator का उपयोग एक (पुनर्जीवित करने के लिए पेज को ताज़ा) उत्पन्न करने के लिए कर सकते हैं या टुकड़ा नीचे का उपयोग उत्पन्न करने के लिए अपने स्वयं के Base64 -encoded AES256 कुंजी:

KeyGenerator keyGen = KeyGenerator.getInstance("AES"); 
keyGen.init(256); // Use 128 for AES128 (when server don't have JCE installed). 
String key = Base64.getEncoder().encodeToString(keyGen.generateKey().getEncoded()); 
System.out.println(key); // Prints AES key in Base64 format. 
+0

के रूप में निश्चित रूप मुझे आशा है कि हो सकता है के बारे में के लिए :) मैं ठीक से जांचूँगा कि कौन सा संस्करण चल रहा है - धन्यवाद। मुझे तब तक 16 घंटे का समय मिल गया है जब तक कि मैं बक्षीस नहीं दे सकता, इसलिए मैं इसे इस उत्तर पर पोस्ट करूंगा। –

+0

आपका स्वागत है। आप बकाया अवधि की अवधि समाप्त होने तक भी प्रतीक्षा कर सकते हैं। आम तौर पर, आपको बक्षीस के आखिरी दिन अपवॉट्स पर अधिक मौका मिलता है (क्योंकि यह प्रश्न तब "फीचर्ड" सूची के शीर्ष पर तैरता है), इस तरह आप अंक वापस कमा सकते हैं। – BalusC

+0

यह देखते हुए कि मुझे पता है कि यह पहले एन्क्रिप्ट नहीं किया गया था, और यह 'com.sun.faces.ClientStateSavingPassword' का उपयोग करता है, ऐसा लगता है कि मैं 2.1.19 - 2.1.x ब्लॉक में पड़ता हूं। हम एक क्लस्टर पर्यावरण में हैं - क्या मैं प्रत्येक सर्वर पर इस्तेमाल होने वाली विभिन्न एईएस कुंजी के साथ मुद्दों में भाग लेने की संभावना है? दुर्भाग्यवश, –

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