2009-10-02 15 views
6

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

क्या स्मृति डंप का उपयोग करके इस पासवर्ड को पढ़ने की कोई संभावना है। (धोखा इंजन का उपयोग करके मान लीजिए।) मैं इस जेवीएम चीज से परेशान हूं। क्या JVM इस के खिलाफ कुछ प्रकार की सुरक्षा प्रदान करता है। यदि ऐसा कोई अभ्यास नहीं है जिसे मुझे "चोरी" से बचने के लिए उपयोग करने की आवश्यकता है।

एक व्यावहारिक खतरा एक ट्रोजन होगा; जो एक बाहरी पार्टी को स्मृति डंप के खंड भेजता है।

+2

मैं सिर्फ यह ध्यान रखना चाहूंगा कि तिथि के सभी उत्तर समान रूप से जावा नहीं बल्कि सभी भाषाओं के लिए समान रूप से लागू होते हैं। समस्या बिल्कुल वही है। कुछ भाषाएं दूसरों की तुलना में इसे थोड़ा आसान या कठिन बना सकती हैं, लेकिन उनमें सभी की मूलभूत "भेद्यता" होती है। –

+0

यदि किसी 'किसी' के पास किसी स्पष्ट कारण के लिए JVM तक पहुंच है, तो आपको चिंता करने के लिए निरीक्षण हमलों की तुलना में खराब चीजें हैं। ज्यादातर लोग 'गेम ओवर' कहेंगे। Http://stackoverflow.com/questions/646224/how-does-one-store-password-hashes-securely-in-memory-when-creating-accounts –

+0

सर्वर पर पासवर्ड संग्रहीत करें और इसे जांचें आवश्यक –

उत्तर

11

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

असल में, जब तक "हमलावर" भी "प्रेषक" होता है, तब तक आप अंततः क्रैक होने जा रहे हैं - यही कारण है कि संगीत और वीडियो उद्योग काम करने के लिए डीआरएम नहीं प्राप्त कर सकते हैं।

मेरा सुझाव है कि आप Applied Cryptography की एक प्रतिलिपि लें और "क्रिप्टोग्राफिक प्रोटोकॉल" के पहले खंड को पढ़ें। वास्तविक क्रिप्टो के गणित में प्रवेश किए बिना भी, यह आपको इस क्षेत्र में सभी प्रकार के डिजाइन पैटर्न का एक अच्छा अवलोकन देगा।

7

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

करने के लिए यह हो रहा केवल सादे पाठ में पासवर्ड रखने के लिए जब आप वास्तव में, तो डंप या यह एन्क्रिप्ट करना की संभावना को कम। यहां ध्यान देने योग्य एक बात यह है कि जेपीएस्वर्डफिल्ड एक स्ट्रिंग के बजाए एक char [] देता है। ऐसा इसलिए है क्योंकि स्ट्रिंग गायब होने पर आपका कोई नियंत्रण नहीं होता है। जब आप एक char [] गायब हो जाएंगे तब भी आपका कोई नियंत्रण नहीं होगा जब आप पासवर्ड के साथ किए जाते हैं तो आप इसे जंक से भर सकते हैं।

मैं कहता हूं क्योंकि यह किसी को रोक नहीं देगा। जब तक पासवर्ड स्मृति में होता है तब तक इसे पुनर्प्राप्त किया जा सकता है, और क्योंकि डिक्रिप्शन को भी वितरित करने का हिस्सा होना पड़ता है, यह भी आपके पासवर्ड को खुले खुले छोड़कर क्रैक किया जा सकता है।

+0

Yup, के लिए (char nextChar: pw) nextChar = 0; // जो काम नहीं कर सकता है, ध्यान दें: अंतिम char [] अंतिम नहीं है –

+0

आपको फोरैच के बजाय लूप के लिए सामान्य का उपयोग करना होगा। और हां यह कहने लायक है कि अंतिम एक सरणी के संदर्भ पर लागू होता है न कि मूल्यों पर। –

2

यदि प्रोग्राम पासवर्ड जानता है, तो प्रोग्राम का उपयोग करने वाला कोई भी व्यक्ति पासवर्ड निकाल सकता है।

+3

कोई भी पर्याप्त तकनीकी रूप से कुशल ... –

2

सिद्धांत रूप में आप इसे ऊपर डिबगर ... एक ब्रेकपाइंट सेट करने के लिए हुक कर सकते हैं ... और स्ट्रिंग सामग्री

4

यह जावा के साथ कोई संबंध नहीं है - ठीक उसी समस्या (यदि यह वास्तव में एक है) किसी भी भाषा में लिखे गए अनुप्रयोगों के लिए मौजूद है: निष्पादन योग्य कोई बात नहीं एक पासवर्ड, शामिल

  • तो कैसे सुलझा या एन्क्रिप्टेड , जिनके पास निष्पादन योग्य पहुंच है, वे पासवर्ड ढूंढ सकते हैं।
  • यदि कोई एप्लिकेशन किसी पासवर्ड या कुंजी को अस्थायी रूप से जानता है (उदा। नेटवर्क प्रमाणीकरण प्रोटोकॉल के हिस्से के रूप में) तो कोई भी जो उस एप्लिकेशन को देख सकता है जिसमें एप्लिकेशन निष्पादित हो रहा है, वह पासवर्ड ढूंढ सकता है।

बाद आम तौर पर एक समस्या नहीं माना जाता है, क्योंकि एक आधुनिक ओएस मनमाना अनुप्रयोगों एक दूसरे की स्मृति का निरीक्षण करने की अनुमति नहीं है, और privilege escalation हमले आम तौर पर हमले के विभिन्न वैक्टर पर भरोसा करते हैं।

+0

यह एक समस्या है यदि आप इसके बारे में नहीं जानते हैं और अपनी प्रणाली विकसित करते हैं जैसे कि "एन्क्रिप्टेड" कुंजी वास्तव में सुरक्षित थी। –

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