रूबी में एक चर "डुप्लिकेट"
मेरे पास एक उपयोग का मामला है जहां मुझे सुरक्षा कारणों से कुछ डेटा के निपटान की आवश्यकता होती है जिस क्षण मुझे इसकी आवश्यकता नहीं होती है ।
मैं रूबी में एक सर्वर लिख रहा हूं जो लॉगिन और पासवर्ड से संबंधित है। मैं अपने डेटाबेस में पासवर्ड स्टोर करने के लिए BCrypt का उपयोग करता हूं। मेरा सर्वर पासवर्ड प्राप्त करता है, उसमें से एक bcrypt हैश बनाता है, और फिर मूल पासवर्ड का उपयोग नहीं करता है।
मुझे एक प्रकार के साइबर हमले का पता है जिसमें रैम से डेटा चोरी करना शामिल है, और मुझे चिंता है कि एक हमलावर कच्चे समय में उपयोगकर्ता के पासवर्ड को चोरी कर सकता है, जबकि पासवर्ड अभी भी स्मृति में है। मुझे यकीन नहीं है कि बस का उपयोग password_in_string_form = nilकरना पर्याप्त होगा।
मैं उस चर को शून्य करना चाहता हूं जो उस उपयोगकर्ता के पासवर्ड को रखता है जो मैं उसके साथ किया जाता हूं। Nullify से मेरा मतलब है कि कुछ / zeroes के साथ कुछ भरने के लिए / dev / null का उपयोग करना। अंतिम लक्ष्य डेटा का अपरिवर्तनीय विनाश है ।
जवाब
मुझे यकीन नहीं है कि अगर बस का उपयोग
password_in_string_form = nilकरना पर्याप्त होगा।
नहीं, यह पर्याप्त नहीं होगा। ऑब्जेक्ट को तुरंत एकत्र किया जा सकता है या नहीं किया जा सकता है, और यहां तक कि अगर यह था, तो वह सामग्री को स्मृति से मिटाने का कारण नहीं बनता है।
हालांकि, जब तक वे जमे हुए नहीं होते हैं, तब तक रूबी तार मुड़े हुए होते हैं । इस प्रकार, जब तक आप पासवर्ड स्ट्रिंग को फ्रीज नहीं करते हैं, तब तक आप इसकी सामग्री को शून्य या यादृच्छिक वर्णों से बदल सकते हैं, या इससे पहले कि आप इसे जाने दें। विशेष रूप से, यह काम करना चाहिए, कुछ प्रोविजोस के अधीन, बाद में कवर किया गया:
(0 ... password_in_string_form.length).each do |i|
password_in_string_form[i] = ' '
end
लेकिन देखभाल की जरूरत है, इस दृष्टिकोण के लिए, जो अधिक मुहावरेदार लग सकता है, काम नहीं करता है:
# SURPRISE! This does not reliably remove the password from memory!
password_in_string_form.replace(' ' * password_in_string_form.length)
लक्ष्य स्ट्रिंग की सामग्री को इन-प्लेस में अपडेट करने के बजाय, replace()रूबी के आंतरिक आवंटनकर्ता को सामग्री जारी करता है (जो उन्हें संशोधित नहीं करता है), और प्रतिस्थापन के विवरण के आधार पर नई सामग्री के लिए एक रणनीति चुनता है।
हालांकि, उन दो दृष्टिकोणों के बीच प्रभाव में अंतर आपके लिए एक बड़ा चेतावनी ध्वज होना चाहिए। रूबी एक उच्च स्तरीय भाषा है। यह आपको बहुत अधिक लाभ देता है, लेकिन ठीक विवरण पर नियंत्रण की कीमत पर, जैसे कि स्मृति में डेटा और कब तक बनाए रखा जाता है।
और यह मुझे प्रोविस में लाता है। यहाँ मुख्य हैं:
जैसा कि आप पासवर्ड स्ट्रिंग को संभालते हैं, आपको इसकी या इसके किसी भी हिस्से की प्रतियां बनाने से बचने के लिए ध्यान रखना चाहिए, या फिर सभी प्रतियों को कैप्चर करने के लिए और उन्हें कचरा भी करना चाहिए। यह विस्तार से कुछ अनुशासन और ध्यान आकर्षित करेगा, क्योंकि ऐसी प्रतियां बनाना बहुत आसान है।
पासवर्ड स्ट्रिंग को ट्रैश करना आपके उद्देश्य को प्राप्त करने के लिए पर्याप्त नहीं हो सकता है। आपको मेमोरी में पासवर्ड की किसी अन्य कॉपी को भी रद्दी करना होगा, जैसे कि पासवर्ड स्ट्रिंग को अलग करने के लिए। यदि आपका वेब एप्लिकेशन है, उदाहरण के लिए, इसमें HTTP अनुरोध की सामग्री शामिल होगी जिसमें पासवर्ड आपके आवेदन पर दिया गया था, और शायद इससे अलग किए गए पासवर्ड स्ट्रिंग की तुलना में इससे अधिक तार निकले। अन्य प्रकार के अनुप्रयोगों पर भी यही बात लागू होती है।
पासवर्ड केवल वह चीज़ नहीं हो सकती है जिसकी आपको सुरक्षा करने की आवश्यकता है। यदि एक विरोधी ऐसी स्थिति में है जहां वे मेजबान मशीन की मेमोरी से पासवर्ड चुरा सकते हैं, तो वे उस संवेदनशील डेटा को चोरी करने की स्थिति में भी हैं जो उपयोगकर्ता लॉगिन करने के बाद एक्सेस करते हैं।
इन और अन्य कारणों के लिए, यदि आपके सर्वर के लिए सुरक्षा आवश्यकताएं निर्धारित करती हैं कि उपयोगकर्ता पासवर्डों की इन-मेमोरी प्रतियां जल्द से जल्द नष्ट हो जाती हैं, तो उनकी आवश्यकता नहीं है, तो (शुद्ध) रूबी एक उपयुक्त कार्यान्वयन भाषा नहीं हो सकती है।
दूसरी ओर, यदि कोई विरोधी मेमोरी / स्वैप से पासवर्ड को स्क्रैप करने के लिए पर्याप्त पहुंच प्राप्त करता है, तो यह संभवतः पहले से ही गेम है। कम से कम, उनके पास वह सब कुछ होगा जो आपके एप्लिकेशन तक पहुंच सकता है। यह पासवर्ड को पूरी तरह से लूट नहीं बनाता है, लेकिन आपको इसे अपने मूल्यांकन में विचार करना चाहिए कि इस मुद्दे को कितना समर्पित करना है।
रूबी में यह संभव नहीं है।
आपको यह सुनिश्चित करने के लिए प्रत्येक कार्यान्वयन (ओपल, ट्रफलहुबी, जेरीबी, रुबिनियस, एमआरयूबी, यारवी, आदि) के लिए कुछ कोड लिखना होगा। कार्यान्वयन के आधार पर, कार्यान्वयन की प्रबंधित मेमोरी के अंदर ऐसा करना संभव नहीं हो सकता है , बिना मेमोरी का एक अलग टुकड़ा होने के बिना, जिसे आप स्वयं प्रबंधित करते हैं।
यानी आपको शायद देशी कोड के कुछ छोटे टुकड़े की आवश्यकता होगी जो कि मूल स्मृति के अपने छोटे टुकड़े का प्रबंधन करता है और इसे आपके रूबी प्रोग्राम में इंजेक्ट करता है।