मैं अपने ओपन सोर्स प्रोजेक्ट में गोपनीय डेटा कैसे छिपा सकता हूं?


13

मेरे पास एक ओपन सोर्स प्रोजेक्ट है जो कई फाइल होस्ट्स के बीच ड्रॉपबॉक्स में फाइल अपलोड करता है। अभी मैं ड्रॉपबॉक्स के लिए स्क्रीन स्क्रैपिंग कर रहा हूं। उनके एपीआई का उपयोग करने के लिए, मुझे OAuth प्रमाणीकरण के लिए मेरे द्वारा प्रदान की गई SECRET कुंजी को हार्डकोड करना होगा। लेकिन मुझे डर है कि कुंजी गुप्त नहीं होगी यदि यह किसी को देखने के लिए स्पष्ट रूप से दिखाई दे।

किसी उपयोगकर्ता के खाते में वायरस अपलोड करने के लिए मेरी कुंजी का उपयोग करने के लिए दुर्भावनापूर्ण व्यक्ति के लिए यह 'संभव' है (जो पहले से ही मेरे ऐप तक पहुंच की अनुमति देता है) जो उनके पीसी (यदि उनके पास डेस्कटॉप सिंक सक्षम है) और दूसरों के पीसी में फैल जाएगा (यदि उन्होंने फोल्डर शेयर किए थे) इत्यादि। : हे

मुझे यह अनुत्तरित प्रश्न मिला जिसमें मेरी जैसी ही समस्या है।

लेकिन मैं आम तौर पर जानना चाहूंगा कि एक खुले स्रोत परियोजना में गोपनीय डेटा को कैसे छिपाया जाएगा।

मेरे पास एक विचार है।

  • स्रोत कोड में एक प्लेसहोल्डर है जैसे "<SECRET KEY HERE>" और रिलीज के लिए बाइनरी का निर्माण करते समय ही इसे भरें? (छी!)

कोई सभ्य विचार?


1
यह वास्तव में ऐसा करने का एकमात्र सुरक्षित तरीका है। आप अपनी गुप्त कुंजी को एनकोड करने के लिए pgp एन्क्रिप्शन का उपयोग कर सकते हैं, उसके बाद ही आप इसे डिकोड कर सकते हैं, लेकिन इसे प्रकाशित करने में परेशान क्यों हों।
प्रेस्कॉट

हो सकता है कि आप इस प्रश्न की जाँच करना चाहें: programmers.stackexchange.com/questions/180957/… - यह ड्रॉपबॉक्स एपीआई कुंजी के बारे में नहीं है, लेकिन सामान्य संदेश समान है।
टाडमर्स

git-crypt आपके लिए बनाया गया है :) github.com/AGWA/git-crypt
nha

जवाबों:


14

मूल विचार यह है कि आप कोड में या संकलित बाइनरी में गोपनीय मूल्यों की जांच नहीं करते हैं । खासकर अगर परियोजना खुला स्रोत है तो आपको वास्तव में नहीं करना चाहिए। ऐसा करने के लिए आप कई कॉन्फ़िगरेशन रणनीतियाँ ले सकते हैं:

कोड में प्लेसहोल्डर (हार्डककोड मान)

कोड में प्लेसहोल्डर - जैसा कि सुझाव दिया गया था - जो कि गतिशील प्रोग्रामिंग भाषाओं में सबसे अधिक सरल और आसान है क्योंकि कोड को बदलना आसान है (संकलन करने की आवश्यकता के बिना)। मैंने बहुत सारे ओपन सोर्स प्रोजेक्ट्स देखे हैं जैसे कि MediaWiki इसके साथ है LocalSettings.php

इस रणनीति के साथ नकारात्मक पक्ष यह है कि कुंजी hardcoded किया जाता है। इसलिए यदि प्रोग्राम को बाइनरी के रूप में वितरित किया जाता है, तो कुंजी हार्ड-कोडित होने से यह विशेष रूप से बनाए रखने योग्य नहीं होता है।

विन्यास पाठ फ़ाइलें

आप इसे कॉन्फ़िगरेशन पाठ फ़ाइलों को लागू करके भी कर सकते हैं , अर्थात प्रोग्राम / एप्लिकेशन कॉन्फ़िगरेशन फ़ाइल के लिए खोज करता है और इससे मान पढ़ता है। आप प्लेसहोल्डर्स के साथ एक नमूना कॉन्फ़िगरेशन में चेक-इन कर सकते हैं, लेकिन आपकी मशीन में वास्तविक कॉन्फ़िगरेशन स्थानीय है।

आपके मामले में आप key.confवास्तविक कुंजी के साथ एक पाठ फ़ाइल बना सकते हैं , प्रोग्राम को उस फ़ाइल का उपयोग करने दें और इसे संस्करण नियंत्रण द्वारा अनदेखा कर दें। आप मददगार होने के लिए, key.conf.exampleएक बोगस कुंजी के साथ एक पाठ फ़ाइल में जांच कर सकते हैं और उस-में मदद कर सकते हैं। सुनिश्चित करें कि आपका प्रोग्राम / एप्लिकेशन उपयोगकर्ता के लिए सही फ़ाइल में वास्तविक कुंजी जोड़ने के लिए एक उपयोगी त्रुटि संदेश बनाता है।

कुछ प्रोग्रामिंग भाषाओं में एपीआई होते हैं जो आपके लिए यह स्वचालित रूप से प्रदान करते हैं, जैसे:

यदि आपका एप्लिकेशन एक डेटाबेस ऐप है, तो डेटाबेस में कुंजी या अन्य कॉन्फ़िगरेशन चर डालने पर विचार करें। यह ऊपर कॉन्फ़िगरेशन पाठ फ़ाइल के समान है, लेकिन आप इसके बजाय डेटाबेस तालिका में कुंजी जैसे सभी कॉन्फ़िगरेशन चर डालते हैं।

वरीयताओं को देखने या एक बैक ऑफिस ऐप के माध्यम से

यदि प्रोग्राम एक खिड़की या विचारों के साथ एक वेब अनुप्रयोग है, तो आप एप्लिकेशन को कॉन्फ़िगरेशन फ़ाइल बनाने के लिए भी दे सकते हैं, वरीयताओं के दृश्य के माध्यम से। इस तरह से आपको ऊपर दिए गए सुझाव के अनुसार एक उदाहरण कॉन्फ़िगर फ़ाइल में जांच करने की आवश्यकता नहीं है।

मीडियाविकि ने LocalSettings.phpप्रारंभिक इंस्टॉलेशन प्रक्रिया में फ़ाइल को ऑटो-जेनरेट करके इसे हल किया ।

बेशक यह उन कार्यक्रमों के लिए एक विकल्प नहीं है जो केवल पृष्ठभूमि प्रक्रियाओं, सेवाओं या डेमॉन के रूप में चलते हैं। हालाँकि, इसीलिए आप अलग-अलग GUI प्रोजेक्ट बनाते हैं, ताकि प्रशासन और वरीयताओं की सेटिंग्स के लिए एक बिंदु बनाया जा सके, वेब ऐप्स में आमतौर पर बैक ऑफिस एप्लिकेशन कहा जाता है ।


यहां एक बात ध्यान देने योग्य है: एप्लिकेशन को स्वयं अपनी कॉन्फ़िगरेशन सेटिंग्स को संशोधित करने का मतलब है कि सेटिंग फ़ाइल को एप्लिकेशन के उपयोगकर्ता द्वारा लिखने योग्य होना चाहिए, जो बदले में हमले की सतह को बढ़ाता है, इसलिए आपको कठिन सोचना चाहिए कि क्या आपको वास्तव में इस तरह के यूआई की आवश्यकता है।
tdammers

2

सबसे आसान तरीका केवल गोपनीय डेटा प्रकाशित नहीं करना है। कुछ विकल्प:

  • प्रश्न में प्लेसहोल्डर का उपयोग करें।
  • विशेष रूप से कुंजी के लिए हेडर फ़ाइल का उपयोग करें, इसे स्रोत नियंत्रण के लिए न करें, और केवल इसे विश्वसनीय पार्टियों में निजी रूप से वितरित करें।

मैंने ओपन सोर्स डेवलपमेंट के लिए दूसरे विकल्प का उपयोग किया है क्योंकि इसका मतलब है कि आपको बिल्ड करने से ठीक पहले डिटेल्स भरने की चिंता नहीं करनी है, या एक बदलाव करने के लिए याद नहीं रखना है।


2

यदि किसी के पास स्रोत कोड (या बाइट कोड है, जो रिवर्स इंजीनियर हो सकता है) तो वे कोड को डिबगर में चलाकर गुप्त कुंजी प्राप्त करने में सक्षम होंगे, और उस बिंदु पर ब्रेक पॉइंट डालेंगे जहां आप कुंजी भेजते हैं।

आप एक पूर्वनिर्मित सी लाइब्रेरी की आपूर्ति करके इसे थोड़ा कठिन बना सकते हैं जो ड्रॉप बॉक्स से बात करता है, जिसमें कुंजी इनकोडेड है, लेकिन अभी भी बहुत सारे तरीके हैं जिसमें चाबियाँ लीक हो जाएंगी (उदाहरण के लिए सोच स्ट्रिंग)।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.