Restic: खाली पासवर्ड की अनुमति दें

रेस्टिक को खाली पासवर्ड की अनुमति देनी चाहिए।

क्या आप विस्तार कर सकते हैं कि आपका उपयोग केस क्या है? रेस्टिक को खाली पासवर्ड की अनुमति क्यों देनी चाहिए?

यह एक डिजाइन निर्णय है।

वास्तव में यह है। लेकिन मैं उत्सुक हूं कि आप क्या हासिल करने की कोशिश कर रहे हैं।

एक संबंधित मुद्दा शायद #1018 . है

निर्देशिका में फ़ाइलों को बदलते समय मैं बस कुछ निर्देशिकाओं को अस्थायी रूप से अपने स्थानीय सिस्टम पर त्वरित सुरक्षा जाल के रूप में बैकअप करना चाहता था। मैं कोई पासफ़्रेज़ याद नहीं रखना चाहता था या हर बार जब मैं बैकअप बनाना चाहता हूँ तो पासफ़्रेज़ दर्ज करने के लिए परेशान नहीं होना चाहता था। चूंकि मैंने अभी पासवर्ड के रूप में a उपयोग किया है,

स्पष्टीकरण के लिए धन्यवाद। मैं इस जांच को यथावत रखना चाहता/चाहती हूं, इसलिए मैं इस मुद्दे को अभी के लिए बंद कर रहा हूं। कृपया बेझिझक आगे की टिप्पणियाँ जोड़ें। धन्यवाद!

जब हमने कुछ समय पहले इस बारे में बात की थी तो आपने कहा था कि चर्चा होगी...
क्या आप शायद समझा सकते हैं कि आप इस चेक को उपयोगी क्यों मानते हैं? रिपॉजिटरी को अभी भी एन्क्रिप्ट किया जाना चाहिए ताकि बाद में एक पासवर्ड जोड़ा जा सके।

मैं इस चेक को उपयोगी मानता हूं क्योंकि मेरे अनुभव में, अधिकांश उपयोगकर्ता पासवर्ड सेट करना चाहेंगे। एक खाली पासवर्ड स्वीकार करना, या यहां तक ​​कि एक कोड पथ होना जो खाली पासवर्ड स्वीकार करने की अनुमति देता है, उपयोगकर्ताओं को गलती से अपने बैकअप को उचित एन्क्रिप्शन के बिना दूरस्थ स्थानों पर सहेज सकता है। एक स्थिति जहां ऐसा हो सकता है, जब पर्यावरण चर RESTIC_PASSWORD निर्यात नहीं किया जाता है या गलती से खाली स्ट्रिंग पर सेट नहीं किया जाता है।

तो, इस मामले में, मुझे ऐसा लगता है कि पासवर्ड सेट करने की छोटी सी असुविधा को दूर करने से उपयोगकर्ताओं को गलती से बचाना बेहतर है :)

हालांकि इसके लिए आसान उपाय हैं: पासवर्ड मैनेजर का उपयोग करें, स्ट्रिंग का उपयोग करें test , RESTIC_PASSWORD को एक फ़ाइल के माध्यम से स्थिर रूप से निर्यात करें जैसे /etc/profile.d , उस निर्देशिका के नाम का उपयोग करें जिसे आप पासवर्ड के रूप में (या भंडार) सहेज रहे हैं ...

कृपया ध्यान दें कि रिपॉजिटरी तक पहुंचने के लिए आपके पासवर्ड का ज्ञान आवश्यक है।
अपना पासवर्ड खोने का मतलब है कि आपका डेटा अपरिवर्तनीय रूप से खो गया है।

अगर मैं अपना डेटा हमेशा के लिए खोना नहीं चाहता, तो मैं इसे कैसे रोक सकता हूं?

@LexSong पासवर्ड मैनेजर का उपयोग करें।

मंगलवार, 03 जुलाई, 2018 को 09:56:56 पूर्वाह्न -0700 बजे, चेनफेंग बाओ ने लिखा:

@LexSong पासवर्ड मैनेजर का उपयोग करें।

आप पासवर्ड मैनेजर डेटाबेस के बैकअप का प्रस्ताव कैसे देते हैं? क्या आप
बिना किसी डेटाबेस के पासवर्ड मैनेजर का उपयोग करने का प्रस्ताव यहां दें
पासवर्ड? कौन सा पासवर्ड मैनेजर इसे प्राप्त करने के लिए रेस्टिक सपोर्ट करता है
से पासवर्ड?

पासवर्ड प्रबंधन एक बहुत बड़ा विषय है जिसके बारे में मैं इस सूत्र में बहुत अधिक विवरण में नहीं जाना चाहता। बस इस ओर इशारा करते हुए कि अगर ठीक से किया जाए, तो पासवर्ड सिरदर्द नहीं होना चाहिए। ऑनलाइन कई संसाधन हैं।

पासवर्ड मैनेजर का डेटाबेस पहले से ही ठीक से एन्क्रिप्टेड होना चाहिए, ताकि आप इसे एन्क्रिप्शन की एक और परत के बिना अपनी पसंद के अनुसार कहीं भी रख सकें। कई क्लाउड आधारित पासवर्ड प्रबंधक सेवाएं भी हैं, इसलिए आपको स्वयं बैकअप के बारे में चिंता करने की आवश्यकता नहीं है।

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

दिन के अंत में, चीजों को सही मायने में सुरक्षित रखने के लिए आपको हमेशा एक जटिल पासवर्ड/पासफ़्रेज़ याद रखना होता है।

वास्तव में, यदि आप वास्तव में किसी रेस्टिक रिपोजिटरी पर पासवर्ड नहीं चाहते हैं, तो केवल एक-वर्ण वाले डमी पासवर्ड का उपयोग क्यों न करें?

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

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

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

उपयोगकर्ता की गलतियों से सुरक्षा के लिए चेक रखने के लिए मैं पिछली टिप्पणियों से सहमत हूं।

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

किसी फ़ाइल या स्क्रिप्ट में पासवर्ड संग्रहीत करना एक त्रुटि-प्रवण समाधान है
समस्या जो मौजूद नहीं होनी चाहिए।

मैं सहमत हूं कि गलती से अपलोड होने से रोकने के लिए सावधानी बरती जानी चाहिए
रिमोट रेपो के लिए अनएन्क्रिप्टेड डेटा।

ऐसा लगता है कि कमांड लाइन विकल्प होना एक आसान समाधान होगा,
--allow-empty-password । उपयोगकर्ता उस स्विच को अपनी स्क्रिप्ट में सेट कर सकते हैं और
पासवर्ड की आवश्यकता के लिए डिफ़ॉल्ट बना रह सकता है।

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

ऐसे बैकअप पासवर्ड याद रखने के लिए नहीं होते हैं। एकमात्र जटिल एन्क्रिप्शन पासवर्ड जिसे आपको याद रखने की आवश्यकता है वह आपके पासवर्ड मैनेजर के लिए है, जिसका आप अक्सर उपयोग करेंगे। और आपको _वास्तव में पासवर्ड मैनेजर का उपयोग करना चाहिए।

किसी फ़ाइल या स्क्रिप्ट में पासवर्ड संग्रहीत करना किसी समस्या के लिए एक त्रुटि-प्रवण समाधान है जो मौजूद नहीं होना चाहिए।

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

ऐसा लगता है कि एक साधारण समाधान एक कमांड लाइन विकल्प होगा, --allow-empty-password । उपयोगकर्ता उस स्विच को अपनी स्क्रिप्ट में सेट कर सकते हैं और डिफ़ॉल्ट पासवर्ड की आवश्यकता के लिए बना रह सकता है।

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

ऐसे बैकअप पासवर्ड याद रखने के लिए नहीं होते हैं। एकमात्र जटिल एन्क्रिप्शन पासवर्ड जिसे आपको याद रखने की आवश्यकता है वह आपके पासवर्ड मैनेजर के लिए है, जिसका आप अक्सर उपयोग करेंगे। और आपको वास्तव में एक पासवर्ड मैनेजर का उपयोग करना चाहिए।

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

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

बाकी सॉफ्टवेयर की तरह, रेस्टिक का उद्देश्य उपयोगकर्ताओं को उनकी जरूरतों को पूरा करने में सक्षम बनाना है। आपकी ज़रूरतों में बेयर-मेटल, कुछ नहीं-पर-आपके-रेस्टिक-बैकअप पुनर्स्थापना परिदृश्य शामिल नहीं है। अन्य उपयोगकर्ताओं की जरूरतें करते हैं। कृपया अन्य लोगों की ज़रूरतों को उन पर न थोपें।

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

प्रस्तावित --allow-empty-password विकल्प के कारण बढ़ी हुई हमले की सतह के बारे में आप क्या विशिष्ट चिंताएँ देखते हैं?

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

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

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

जब तक पासवर्ड मैनेजर के साथ कोई एकीकरण नहीं होता है, तब भी यह खतरा बना रहता है कि पासवर्ड मैनेजर में मान गलत है, पुराना है या गलती से डिलीट हो गया है क्योंकि पासवर्ड मैनेजर के बाहर पासवर्ड की एक कॉपी होगी।

मैं एक खाली पासवर्ड ( --allow-empty-password ध्वज के उपयोग के माध्यम से, या शायद जोखिम को उजागर करने के लिए कुछ और वर्बोज़/अद्वितीय, जैसे एनआरपीई के --dont-blame-nrpe ध्वज) की अनुमति देने का विकल्प देखना चाहता हूं।

मेरे उपयोग के मामले:

• व्यवसाय: हमारे पास एक विश्वसनीय वातावरण में निहित एक भंडार है जिसे विशेष ज्ञान (यानी, एक भंडार पासवर्ड) के बिना किसी आपात स्थिति/आपदा से पुनर्स्थापित करने में सक्षम होने के लिए हमें "कोई भी" की आवश्यकता है।
• होम: मैं पारिवारिक फ़ोटो जैसी चीज़ों का एक रेस्टिक बैकअप बनाना चाहता/चाहती हूं। ये विशेष रूप से गोपनीय नहीं हैं, और मेरे असामयिक निधन के मामले में, मेरे परिवार को न्यूनतम प्रतिरोध के साथ इस व्यक्तिगत रूप से महत्वपूर्ण डेटा तक पहुंचने में सक्षम होना चाहिए (_उदाहरण के लिए, एक तिजोरी में पासफ़्रेज़ खोजने के बिना, जो संभवतः आउट-ऑफ- दिनांक या अन्य_ के साथ मिश्रित)।

मैं डेटा अखंडता के साथ-साथ एन्क्रिप्शन को सुनिश्चित करने के लिए पासफ़्रेज़ की आवश्यकता को समझता हूं। मुझे keys निर्देशिका में फ़ाइल (फ़ाइलें) एक JSON ऑब्जेक्ट प्रतीत होती है। शायद एक छद्म-यादृच्छिक कुंजी उत्पन्न की जा सकती है (बिना कुंजी के) और वहां संग्रहीत किया जा सकता है? यह उन उपयोगकर्ताओं की मदद नहीं करता है जो प्रदर्शन कारणों से एन्क्रिप्शन के ऊपरी हिस्से से बचने की कोशिश कर रहे हैं।

@ fd0 आप प्रस्तावित --allow-empty-password कमांड लाइन विकल्प के बारे में क्या सोचते हैं? इसे डिफ़ॉल्ट रूप से पासफ़्रेज़ की आवश्यकता होगी, लेकिन उपयोगकर्ताओं को आवश्यक होने पर इसे ओवरराइड करने की अनुमति दें।

और कृपया इस मुद्दे को फिर से खोलने पर विचार करें। कई उपयोगकर्ताओं की ज़रूरतों में गैर-गोपनीय फ़ाइलों का बैकअप लेना शामिल है, बिना भूले या गलत पासफ़्रेज़ के कारण पहुँच खोने के जोखिम के बिना।

यहां बिल्कुल नया रेस्टिक उपयोगकर्ता - अभी तक मेरा पहला भंडार भी नहीं बनाया है - लेकिन अन्य उपकरणों के साथ वर्षों का अनुभव - मेरा पसंदीदा अच्छा पुराना "डंप" है। सम्मान के साथ, यह एक नो-ब्रेनर है - निश्चित रूप से खाली पासवर्ड की अनुमति दी जानी चाहिए। अनजाने में त्रुटि के जोखिम को कम करने के लिए हर तरह से एक ध्वज जोड़ें, लेकिन कृपया उन अनुभवी (संभावित) उपयोगकर्ताओं के लिए उपयोग के मामलों को निर्देशित न करें जिन्होंने स्पष्ट रूप से अन्य आवश्यकताओं को इंगित किया है।
मैं केवल सुरक्षा के लिए स्थानीय बैकअप बनाने की कोशिश कर रहा हूं; सुरक्षा कोई समस्या नहीं है, और मुझे बैकअप की आवश्यकता की तुलना में पासवर्ड का ट्रैक खोने की अधिक संभावना है। और मुझे पासवर्ड मैनेजरों से नफरत है...

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

एक env या एक स्क्रिप्ट फ़ाइल में पासवर्ड प्रदान करने की आवश्यकता पहली जगह में पूरी सुरक्षा चीज को बेकार कर देती है।

जरूरी नहीं कि यह सच हो। ऐसा करने के अच्छे तरीके हैं।

जरूरी नहीं कि यह सच हो। ऐसा करने के अच्छे तरीके हैं।

कृपया इस तर्क को यहां दोबारा न दोहराएं। कई उपयोगकर्ताओं को अनएन्क्रिप्टेड या खाली-पासवर्ड बैकअप बनाने की आवश्यकता होती है। यदि आप उनमें से नहीं हैं, तो आपके लिए अच्छा है।

@mholt , कोई सिफारिश? मुझे अधिकतम सुरक्षा के साथ शून्य हस्तक्षेप के साथ अपने सर्वर का बैकअप लेने में खुशी होगी।

कई उपयोगकर्ताओं को अनएन्क्रिप्टेड या खाली-पासवर्ड बैकअप बनाने की आवश्यकता होती है।

यह आमतौर पर एक XY समस्या है ।

@mholt , कोई सिफारिश? मुझे अधिकतम सुरक्षा के साथ शून्य हस्तक्षेप के साथ अपने सर्वर का बैकअप लेने में खुशी होगी।

यह आपकी विशिष्ट स्थिति, खतरे के मॉडल, पर्यावरण, स्वीकार्य जोखिमों और तकनीकी और प्रयोज्य उद्देश्यों पर अत्यधिक निर्भर करता है। तो नहीं, मेरे पास किसी के लिए सिफारिशों का एक व्यापक सेट नहीं है।

यह आमतौर पर एक XY समस्या है।

तो नहीं, मेरे पास किसी के लिए सिफारिशों का एक व्यापक सेट नहीं है।

वह कृपालु रवैया मददगार नहीं है। इससे भी बदतर यह है कि हमें यह बताने के बाद कि हमारी ज़रूरतें गलत हैं, फिर आप कोई सलाह देने से इनकार करते हैं। यह एक FOSS प्रोजेक्ट है, न कि Apple, Inc.

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

यह कई उपयोगकर्ताओं के लिए एक सामान्य मामला है, और यह तय करना आपके लिए नहीं है कि उपयोगकर्ताओं की क्या ज़रूरतें हैं।

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

अपने उपयोग के मामलों की व्याख्या करने के लिए धन्यवाद और आप फिर से चिंतित हैं। रिकॉर्ड के लिए, मुझे लगता है कि वे मान्य हैं, खासकर "खोया पासवर्ड"। मुझे यह भी लगता है कि restic init जैसे --allow-empty-password लिए एक विशेष ध्वज काम करेगा (मेरे पास कोने के मामलों के लिए कुछ विचार हैं, लेकिन मुझे विश्वास है कि उन्हें हल किया जा सकता है)। इसलिए मैं इस मुद्दे को फिर से खोलूंगा।

कृपया ध्यान रखें कि खाली पासवर्ड की अनुमति देने से "खोए हुए पासवर्ड" के लिए सुरक्षा संबंधी चिंता का समाधान हो जाएगा, लेकिन फिर भी हमेशा की तरह सभी डेटा को एन्क्रिप्ट किया जाएगा।

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

तो, कृपया, सब लोग, इस चर्चा को उत्पादक बनाए रखें, भले ही आप असहमत हों। :)

@ fd0 अस्पष्ट होने के लिए मुझे क्षमा करें। मैं आपसे या किसी रेस्टिक डेवलपर से किसी चीज की मांग या अपेक्षा नहीं करता हूं। यह आपका प्रोजेक्ट और आपका समय है, और आप जो चाहें उस पर काम कर सकते हैं।

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

मैं जिन टिप्पणियों पर आपत्ति करता हूं (आपकी नहीं) जो यह बताती हैं कि जो उपयोगकर्ता इस सुविधा को चाहते हैं वे अपनी जरूरतों को नहीं समझते हैं, खासकर जब विकल्पों का सुझाव देने से इनकार कर दिया जाता है। यह असभ्य और अनुपयोगी शोर है।

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

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

restic --password-file /dev/null -r s3:http://172.28.0.7:9000/bup2 init

यह केवल आधा है जो मैं चाहता हूं, क्योंकि यह अभी भी एन्क्रिप्ट कर रहा है, लेकिन एक खाली पासवर्ड के साथ। अगर मैं कर सकता तो मैं उस सीपीयू उपयोग को पुनर्प्राप्त करना चाहता हूं।

कृपया ध्यान रखें कि खाली पासवर्ड की अनुमति देने से "खोए हुए पासवर्ड" के लिए सुरक्षा संबंधी चिंता का समाधान हो जाएगा, लेकिन फिर भी हमेशा की तरह सभी डेटा को एन्क्रिप्ट किया जाएगा।

हम्म, खाली पासवर्ड के साथ अभी भी एन्क्रिप्ट करने के पीछे क्या प्रेरणा है?

मेरा मतलब है, कम शक्ति वाले हार्डवेयर पर रेस्टिक चलाते समय एन्क्रिप्शन कुछ ध्यान देने योग्य रनटाइम ओवरहेड जोड़ता है।

संपादित करें: ठीक है, https://github.com/restic/restic/issues/1018#issuecomment -307549863 - विशेष रूप से दूसरा बिंदु मेरे प्रश्न का उत्तर देता है।

restic --password-file /dev/null -r s3:http://172.28.0.7:9000/bup2 init

इस सुझाव के साथ मुख्य समस्या यह है: यह सिर्फ काम नहीं करता है, रेस्टिक अंतःक्रियात्मक रूप से पासवर्ड मांग रहा है:

~# restic -r '/tmp/restic/' -p '/dev/null' init
enter password for new repository:

धन्यवाद, @fd0 , मुद्दे को फिर से खोलने के लिए। मैं @alphapapa से सहमत हैं, मेरा इरादा किसी भी मुक्त समय डेवलपर्स पुश करने के लिए कुछ भी वे के साथ मज़ा नहीं है पर उनके समय बिताने के लिए नहीं है।

हमें बस दूसरे के द्वारा कहा जाना पसंद नहीं है हम अपनी जरूरत को नहीं समझते हैं।

मेरे विचार से बैकअप टूल की सबसे महत्वपूर्ण विशेषता किसी भी स्थिति में पुनर्स्थापना करने की क्षमता है। यद्यपि सुरक्षा का बहुत, बहुत अधिक महत्व है, यह विशिष्ट स्थिति पर निर्भर करता है कि क्या डेटा सुरक्षा (पुनर्स्थापित करने की क्षमता) या डेटा सुरक्षा (अनधिकृत पहुंच से सुरक्षा) की उच्च प्राथमिकता है।

बेशक, आप स्वतंत्र रूप से केवल उन स्थितियों के लिए एक उपकरण विकसित करने का निर्णय ले सकते हैं जहां सुरक्षा अधिक महत्वपूर्ण है, सुरक्षा।

जैसा कि @mholt ने "XY-Problem" का उल्लेख किया है: अनुरोध सार्वजनिक उपलब्ध जेनेरिक रेस्टिक दस्तावेज़ीकरण से परे किसी भी ज्ञान के बिना आपदा वसूली करने में सक्षम होना है और निश्चित रूप से रिपोजिटरी तक पहुंच है।
"बिना किसी जानकारी के" पासवर्ड प्रबंधकों की आवश्यकता या उपयोग को शामिल नहीं करता है।

मुझे यह समस्या मिलने का कारण यह है: _मैं कुछ लोगों को उनके पीसी के साथ निजी तौर पर मदद कर रहा हूं। उनके पासवर्ड को संभालना एक गड़बड़ है, यूएसबी-ड्राइव पर बैकअप सेट करते समय उन्हें उचित पासवर्ड हैंडलिंग सिखाने की कोशिश करने का परिणाम केवल या तो बैकअप नहीं बना पाएगा या जरूरत पड़ने पर पासवर्ड उपलब्ध नहीं होगा। पुनर्स्थापना की आवश्यकता होने पर उन्हें किसी और से सहायता मिल सकती है, इसलिए स्थिति को कम करने के लिए मैं जो कुछ भी लेकर आता हूं वह शून्य हो सकता है।_

अभी, मैं उसी यूएसबी-ड्राइव पर एक टेक्स्ट फ़ाइल में पासवर्ड सहेज रहा हूं, जो रेस्टिक बैकअप रिपोजिटरी के रूप में है, जो पूरी तरह से पासवर्ड रखने की सुरक्षा को खराब कर देता है।
और मुझे यह समाधान पसंद नहीं है क्योंकि पासवर्ड का उपयोग करना जो सुरक्षा की कोई अतिरिक्त परत नहीं देता है सुरक्षा की एक बहुत ही गलत कल्पना देता है।

बेशक मैं यहाँ केवल व्यक्तिगत स्थानीय बैकअप के बारे में बात कर रहा हूँ। सेवर्स के लिए, मैं कुछ अलग ऑफलाइन स्टोरेज में कॉपी किए गए मजबूत पासवर्ड की सलाह देता हूं।

मुझे लगता है कि यहाँ एक और समस्या है; अगर कुछ ढांचे/एपीआई खाली पासवर्ड की अनुमति देते हैं और कुछ नहीं करते हैं। और किसी को एक इनपुट को डिक्रिप्ट करना होता है जिसे किसी अन्य एपीआई द्वारा खाली पासवर्ड के साथ एन्क्रिप्ट किया गया था। यह वर्तमान में https://github.com/RNCryptor/JNCryptor के साथ मेरी समस्या है

तो, कृपया, सब लोग, इस चर्चा को उत्पादक बनाए रखें, भले ही आप असहमत हों। :)

इस सूत्र को पढ़ने के बाद, मुझे बातचीत उपयोगी लगी, क्योंकि परिणाम सकारात्मक था।

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

व्यक्तिगत रूप से, इस मामले में, मुझे लगता है कि हर किसी पर "सुरक्षा" क्या होनी चाहिए, इसकी पूर्वधारणा लागू करना एक गलती है। डेटा सुरक्षा का पहला नियम यह है कि डेटा उन लोगों के लिए सुलभ होना चाहिए जो इसे पाने के हकदार हैं। नियम # 1 से समझौता करने वाले किसी भी नियम पर उचित सावधानी से विचार किया जाना चाहिए।

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

कुछ सामान्य गलतियाँ जो हम हर दिन देखते हैं:

1) इस बात पर जोर देना कि किसी मीडिया को लिखे गए डेटा को आराम से एन्क्रिप्ट किया गया है, खुद को एन्क्रिप्ट किया जाना चाहिए, यहां तक ​​कि एक विश्वसनीय वातावरण में भी। इंटरसेप्शन का डर कहां खत्म होता है? हम कहां से भरोसा करना शुरू करें कि उपयोगकर्ता संभावित रूप से सक्षम हो सकता है, और यह कि अनावश्यक परतों को जोड़ने से डेटा हानि का जोखिम बढ़ जाता है?

2) एक विशिष्ट प्रारूप के पासवर्ड पर जोर देना, यानी कम से कम एक अपरकेस अक्षर, एक संख्या और एक गैर-अल्फ़ान्यूमेरिक के साथ 8 वर्ण - यह 20 वर्षों के लिए एक सामान्य प्रथा थी और अब इसे खारिज कर दिया गया है क्योंकि दर्द लाभ से अधिक है। इसके बजाय हमें यादगार, उच्च-एन्ट्रॉपी पासवर्ड जैसे xkcdpassword पर जोर देना चाहिए, या एक पासवर्ड मैनेजर के साथ एकीकृत करना चाहिए (जो प्रभावी रूप से सभी प्रमुख उपभोक्ताओं को एक साझा सुरक्षा SPOF मास्टर पासवर्ड पर निर्भर करता है जिसे स्पीयरफिश किया जा सकता है - बस COMMODO से पूछें) या 2FA (संभावित रूप से बेहतर) को एकीकृत करें दूसरे कारक की भौतिक सुरक्षा पर निर्भर करता है, जिसमें N+1 कुंजी अतिरेक भी शामिल है)।

3) एक मास्टर पासवर्ड के साथ - इसे एक सत्र में कैश करने में विफल होने के कारण उपयोगकर्ता को दिन भर में कई बार इसे दर्ज करने के लिए मजबूर होना पड़ता है कि इसमें प्रवेश करने की कार्रवाई एक विशिष्ट हमला वेक्टर बन जाती है।

4) एक मास्टर पासवर्ड के साथ - नीतियों की जाँच करने में विफल और मास्टर पासवर्ड के लिए आँख बंद करके क्वेरी करना ताकि उपयोगकर्ता इसे प्रस्तुत करने का आदी हो जाए, जब इसकी वास्तव में आवश्यकता नहीं होनी चाहिए, जिसके परिणामस्वरूप वे गंभीर रूप से विश्लेषण करना बंद कर देते हैं कि उन्हें इसे प्रदान करना चाहिए या नहीं। यह उदाहरण।

5) कम से कम विशेषाधिकार की नीति को इस हद तक लागू करना कि उपयोगकर्ता इससे नाराज हो जाएं और ऑप्ट इन करने से बचें, या इसके आसपास काम करने के तरीके खोजें, अगर कोई अधिक अनुमेय योजना थी तो दरवाजे को अधिक समय तक खुला छोड़ दें।

6) एन+1 अतिरेक के बिना कम से कम विशेषाधिकार की नीति लागू करना, उर्फ ​​'व्यापार निरंतरता/"प्रमुख व्यक्ति नीति" विचारों की कमी। यानी एक साझा संसाधन को 2 निजी कुंजियों के पीछे लॉक करने के बजाय ताकि इसे केवल तभी एक्सेस किया जा सके जब दोनों सहमत हों (2 का कोरम), इसे 3 में से किसी भी 2 निजी कुंजी के पीछे लॉक करें। कोई हमेशा के लिए नहीं रहता।

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

आइए यह भी याद रखने की कोशिश करें कि पूरी तरह से दुरुपयोग के डर से चीजों को उपयोगकर्ताओं से दूर ले जाना, मौलिक रूप से गलत है - जैसे कि डर से किए गए लगभग सभी निर्णय। सभी को दंडित करना क्योंकि कोई गलत काम कर सकता है, समग्र रूप से समाज को कम करता है।

यदि आपको इस क्षण में लगता है कि आप उस अवधारणा से असहमत हैं, तो एक गहरी सांस लें, दस तक गिनें, फिर इस पर विचार करें: एक समाज के रूप में हमें क्या करना चाहिए जब कोई व्यक्ति अपने सिर को कचरे के डिब्बे में डाल कर आत्महत्या कर लेता है व्हिप क्रीम स्प्रे करें और नाइट्रस ऑक्साइड की पूरी कैन को अंदर लें? क्या हमें स्प्रे व्हिप क्रीम को सभी से दूर ले जाना चाहिए? प्लास्टिक की थैली? सांस लेना? इन सभी चीजों का इस तरह से दुरुपयोग किया जा सकता है जिससे उपयोगकर्ता की मृत्यु हो जाती है।

चीजों को दूर ले जाने के लिए घुटने के बल चलने के बजाय, जैसा कि हम मैच के साथ खेलने वाले बच्चे के साथ करेंगे, इसके बजाय हमें लोगों को इन चीजों का सही उपयोग करने के लिए शिक्षित करने के पक्ष में गलती करनी चाहिए। या प्रवेश के बार को इस तरह बढ़ाएं कि केवल आरटीएफएम वाले ही इसे ढूंढ सकें।

अंत में यहीं हुआ, और उस परिणाम को स्वीकार करने का निर्णय तब तक नहीं आया जब तक कि सभी मुद्दों और विचारों को पहले ही व्यक्त नहीं कर दिया गया। मैं सार्वजनिक टीवी स्टेशनों पर संसदीय वाद-विवाद सत्र देखने की सलाह देता हूं, उदाहरण के लिए कि अनुत्पादक बहस कैसी लगती है, योग्य। यहाँ के प्रतिभागी तुलनात्मक रूप से एक दूसरे के प्रति असाधारण रूप से सम्मानजनक थे।

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

और फिर से स्वर के बारे में। यह ओपन-सोर्स दुनिया के लिए सामान्य है। और यह कुछ मनोवैज्ञानिक तंत्र द्वारा समर्थित है। जिस आलोचना से लेखक सहमत नहीं हैं, उसे अपना खाली समय बिताने के दावे के रूप में माना जाता है। और हर बार हमें याद दिलाना पड़ता है: हम यहां आपके खाली समय की चर्चा नहीं करते हैं, बल्कि हम आपके प्रतिभाशाली प्राणी, उसकी कार्यक्षमता और उसके पीछे के तर्क का पता लगाते हैं। हम यह कभी नहीं भूलते कि हमारी मांग को पूरा करने के लिए आपका कोई दायित्व नहीं है और आपको कुछ भी न करने का पूरा अधिकार है। लेकिन अगर आप जो करते हैं उसे पसंद करते हैं, तो यह (शायद) हो सकता है क्योंकि दूसरे इसे पसंद करते हैं। तो वहाँ कुछ आशा मौजूद हो सकती है कि आप कम से कम बहुमत की मांग को पूरा करने में रुचि रखते हैं।

पीएस ये सब सिर्फ अमूर्त शेख़ी हैं और कोई अभ्यास क्रिया नहीं है।

एक बात है जिसे मैंने कभी भी भंडार के लिए कोई पासवर्ड नहीं देने की चर्चा के बारे में समझा है (यह मानते हुए कि संदर्भ @ fd0 पहले लिखा गया था, कि डेटा अभी भी एन्क्रिप्ट किया जाएगा); वे लोग क्यों नहीं जो "पासवर्ड नहीं चाहते" एक डमी पासवर्ड का उपयोग करते हैं जैसे "1234" या जो कुछ भी? रेस्टिक में कोड लिखने का क्या मतलब है जो पासवर्ड को हटा देता है, जब यदि आप पासवर्ड रखने की परवाह नहीं करते हैं तो आप केवल एक डमी पासवर्ड का उपयोग कर सकते हैं? यह एक पर्यावरण चर या पासवर्ड फ़ाइल दूर है, अगर आपको लगता है कि इसे रेस्टिक चलाते समय कमांड लाइन पर टाइप करना बोझिल है।

@rawtaz इस धागे पर पिछली टिप्पणियों में इसका उत्तर दिया गया है।

बस मुझे यह कहना चाहिए कि restic init -r foo --no-password शायद restic init -r foo --allow-empty-password से बेहतर ध्वज नाम है, केवल इसलिए कि पूर्व बिंदु पर अधिक है और बाद वाला बहुत ही वर्बोज़ है।

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

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

टीडी

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

मैं एक खाली पासवर्ड ( --allow-empty-password ध्वज के उपयोग के माध्यम से, या शायद जोखिम को उजागर करने के लिए कुछ और वर्बोज़/अद्वितीय, जैसे एनआरपीई के --dont-blame-nrpe ध्वज) की अनुमति देने का विकल्प देखना चाहता हूं।

मेरे उपयोग के मामले:

* **Business:** we have a repository contained in a trusted environment that we need "anyone" to be able restore from in an emergency/disaster without having to have special knowledge (ie, a repository password).

* **Home:** I would like to create a restic backup of things like family photos. These are not particularly confidential, and in the case of my untimely demise, my family need to be able to access this personally important data with minimum resistance (_for example, without having to find a passphrase in a safe, that's possibly out-of-date or mixed up with another_).

मैं डेटा अखंडता के साथ-साथ एन्क्रिप्शन को सुनिश्चित करने के लिए पासफ़्रेज़ की आवश्यकता को समझता हूं। मुझे keys निर्देशिका में फ़ाइल (फ़ाइलें) एक JSON ऑब्जेक्ट प्रतीत होती है। शायद एक छद्म-यादृच्छिक कुंजी उत्पन्न की जा सकती है (बिना कुंजी के) और वहां संग्रहीत किया जा सकता है? यह उन उपयोगकर्ताओं की मदद नहीं करता है जो प्रदर्शन कारणों से एन्क्रिप्शन के ऊपरी हिस्से से बचने की कोशिश कर रहे हैं।

• व्यवसाय: हमारे पास एक विश्वसनीय वातावरण में निहित एक भंडार है जिसे विशेष ज्ञान (यानी, एक भंडार पासवर्ड) के बिना किसी आपात स्थिति/आपदा से पुनर्स्थापित करने में सक्षम होने के लिए हमें "कोई भी" की आवश्यकता है।

लेकिन उन "किसी" को पहले से ही विशेष ज्ञान/निर्देशों की आवश्यकता है। उन्हें यह जानने की जरूरत है कि डेटा को पुनर्स्थापित करने के लिए रेस्टिक कैसे चलाया जाए, जिसमें किस रिपॉजिटरी का उपयोग करना है और अन्य चीजें शामिल हैं, और फिर उन निर्देशों में एक डमी पासवर्ड शामिल करना अविश्वसनीय रूप से आसान होगा। या वे एक स्क्रिप्ट या इसी तरह के स्वचालन का उपयोग करेंगे जो उनके लिए पुनर्स्थापना करता है (जिस स्थिति में उन्हें अभी भी उस उपकरण का उपयोग करने के लिए कहां जाना है, इसके बारे में जानने/निर्देश प्राप्त करने की आवश्यकता है), जिस स्थिति में डमी पासवर्ड को संभाला जाएगा स्क्रिप्ट . कोई फर्क नहीं पड़ता कि आप इसे कैसे देखते हैं, एक डमी पासवर्ड एक गैर-मुद्दा है। और गंभीरता से, अगर हर कोई इसे अचानक भूल जाएगा, तो लोग केवल 1234 का अनुमान लगाने में सक्षम होंगे या इसे जबरदस्ती बल देंगे। यह कोई समस्या नहीं है :P

• होम: मैं पारिवारिक फ़ोटो जैसी चीज़ों का एक रेस्टिक बैकअप बनाना चाहता/चाहती हूं। ये विशेष रूप से गोपनीय नहीं हैं, और मेरे असामयिक निधन के मामले में, मेरे परिवार को न्यूनतम प्रतिरोध के साथ इस व्यक्तिगत रूप से महत्वपूर्ण डेटा तक पहुंचने में सक्षम होना चाहिए (_उदाहरण के लिए, एक तिजोरी में पासफ़्रेज़ खोजने के बिना, जो संभवतः आउट-ऑफ- दिनांक या अन्य_ के साथ मिश्रित)।

किसकी प्रतीक्षा? पृथ्वी पर आप कोई पासवर्ड क्यों नहीं रखना चाहेंगे, और जब यह संभव नहीं है (वर्तमान में कम से कम) एक सुपर सरल डमी पासवर्ड (जैसे 1234) का उपयोग करें, और फिर उस सुपर सरल डमी पासवर्ड को एक तिजोरी में रखें ? यह पूरी तरह से व्यर्थ होगा। इसे कहीं और रखें, और जो इसके लायक है, शायद आपके पास पहले से ही अन्य सूचनाओं का एक पूरा समूह है जो आपके परिवार को आपकी मृत्यु के मामले में जानने की आवश्यकता है, इसलिए बस उसके साथ अपना डमी पासवर्ड डालें।

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

हां, वे सुझाव पहले ही दिए जा चुके हैं, इसलिए अब हम मंडलियों में जा रहे हैं। व्यक्तिगत रूप से बोलते हुए, वे उपयुक्त समाधान नहीं हैं जिनके साथ मैं अपने पर्यावरण और उपयोग के मामलों के लिए सहज हूं।

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

हां, वे सुझाव पहले ही दिए जा चुके हैं, इसलिए अब हम मंडलियों में जा रहे हैं।

हाँ, और ईमानदारी से मैंने अभी भी एक वास्तविक स्पष्टीकरण नहीं देखा है कि एक डमी पासवर्ड को संभालना इतना कठिन क्यों है, मुझे लगता है कि मैंने इसकी अधिकतर जटिलताओं को देखा है।

व्यक्तिगत रूप से बोलते हुए, वे उपयुक्त समाधान नहीं हैं जिनके साथ मैं अपने पर्यावरण और उपयोग के मामलों के लिए सहज हूं।

यह एक ऐसी चीज है जिसका मैं पूरी तरह से सम्मान करता हूं। हर किसी का उपयोग मामला अलग-अलग होता है और आपके पास अपना वर्कफ़्लो होता है :)

मुझे लगता है कि किसी बिंदु पर हमें --no-password या समान मिलेगा, उम्मीद है कि यह इस उपयोग के मामले को भी हल करेगा। आपके सहयोग के लिए धन्यवाद!

रावताज़ ने लिखा

बस मुझे यह कहना चाहिए कि restic init -r foo --no-password शायद restic init -r foo --allow-empty-password से बेहतर ध्वज नाम है, केवल इसलिए कि पूर्व बिंदु पर अधिक है और बाद वाला बहुत ही वर्बोज़ है।

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

मैं डमी पासवर्ड उपयोग/हैंडलिंग के बारे में चिंतित नहीं हूं - इसके बजाय मैं कभी-कभी सीपीयू उपयोग के बारे में चिंतित हूं, जब यह लो-एंड हार्डवेयर पर चल रहा हो तो अनिवार्य एन्क्रिप्शन द्वारा बैकअप प्रक्रिया को धीमा कर देता है।

#1018 (अनएन्क्रिप्टेड बैकअप) को हल करने से भी यह समस्या हल हो जाएगी - यानी --unencrypted स्विच के बजाय --no-password स्विच के साथ।

मैंने वास्तव में लोअर-एंड हार्डवेयर पर रेस्टिक का उपयोग किया था जहां सीपीयू में निश्चित रूप से एईएस-एनआई (या एक समान एक्सटेंशन) नहीं था और जहां बैकअप तब सीपीयू बाध्य था। एक अन्य मामले में सीपीयू थोड़ा अधिक शक्तिशाली था लेकिन एकमात्र उपलब्ध बाहरी हार्ड ड्राइव पहले से ही एलयूकेएस एन्क्रिप्टेड था और इस प्रकार यह सीपीयू बाध्य था क्योंकि यह समानांतर में दो एन्क्रिप्टिंग प्रक्रियाओं को संभालने के लिए पर्याप्त शक्तिशाली नहीं था।

यह भी देखें: https://github.com/restic/restic/issues/1018#issuecomment -307549863

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

यदि आप रूट पासवर्ड खो देते हैं तो आप init=/bin/bash विकल्प के साथ बूट कर सकते हैं और पूर्ण पहुंच प्राप्त कर सकते हैं। हालांकि इस छेद को बंद किया जा सकता था, यह अभी भी अधिकांश प्रणालियों में मौजूद है। क्यों? क्योंकि अनुपलब्धता से नुकसान उन मामलों में असुरक्षा से अधिक होगा। इस प्रकार यह सुरक्षा और उपलब्धता के बीच एक समझौता है। उच्च आवश्यकता वाले सिस्टम के लिए विशेष समाधान मौजूद हैं, जैसे अनावश्यक कुंजी, सुरक्षा और उपलब्धता दोनों प्रदान करते हैं।

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

BTW: चूक सॉफ्टवेयर की गुणवत्ता का प्रतीक है।

@vstavrinov कृपया यह कहने से पहले कि यह सुरक्षा उपकरण नहीं है, कृपया

लेकिन अगर आप पासवर्ड भूल गए हैं तो आप अपना डेटा हमेशा के लिए खो देते हैं।

हां, और इसीलिए आप (इस मामले में आसान विकल्प है) एक डमी पासवर्ड का उपयोग करें ताकि आप पासवर्ड को भूल जाने पर भी हमेशा महसूस कर सकें।

और वास्तविक जीवन में आप कोई भी सरल डमी पासवर्ड भूल सकते हैं।

यदि आप करते हैं, तो आपने एक बहुत ही जटिल डमी पासवर्ड चुना है, और यह वास्तव में अब एक साधारण डमी पासवर्ड नहीं है।

यह पूरी चर्चा हास्यास्पद रूप से मूर्खतापूर्ण, स्पष्ट रूप से होती जा रही है। मुझे विश्वास नहीं हो रहा है कि लोग कह रहे हैं कि 1234 जैसा पासवर्ड, जो सबसे आम और स्पष्ट पासवर्ड में से एक है, कुछ ऐसा है जिसे वे भूल सकते हैं और फिर वास्तविक त्वरित पता लगाने में सक्षम नहीं हैं (उदाहरण के लिए कुछ स्पष्ट डमी की कोशिश करके) पासवर्ड)। मैं कहूंगा कि जब आप उस स्थिति में हों तो 1234 "अनुमान" न कर पाने के लिए आपको वास्तविक कठिन प्रयास करना होगा, और तब भी आप इसका अनुमान न लगाने में असफल होंगे।

लेकिन अगर आप पासवर्ड भूल गए हैं तो आप अपना डेटा हमेशा के लिए खो देते हैं।

विकिपीडिया आपकी मदद कर सकता है: https://en.wikipedia.org/wiki/List_of_the_most_common_passwords#List से सबसे सामान्य पासवर्ड

एक स्थिति जहां ऐसा हो सकता है, जब पर्यावरण चर RESTIC_PASSWORD को निर्यात नहीं किया जाता है या गलती से खाली स्ट्रिंग पर सेट नहीं किया जाता है।

कोड के लिए यह जांचना संभव है कि कोई पासवर्ड स्पष्ट रूप से खाली स्ट्रिंग पर सेट किया गया था या बस सेट नहीं किया गया था (कोई कमांड लाइन विकल्प निर्दिष्ट नहीं है, पर्यावरण चर सेट नहीं है -> खाली स्ट्रिंग से अलग)।

मुझे लगता है कि उपयोगकर्ता को यह विकल्प दिया जाना चाहिए कि वह कौन सा पासवर्ड चुनना चाहता है।

#1018 (अनएन्क्रिप्टेड बैकअप) को हल करने से भी इस समस्या का समाधान हो जाएगा - यानी --नो-पासवर्ड स्विच के बजाय - अनएन्क्रिप्टेड स्विच के साथ।

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

@rawtaz

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

दूर नहीं। मुझे इंगित करें जहां मैं कहता हूं "यह सुरक्षा के बारे में चिंतित नहीं है"। मैं नही। आप वही कहते हैं: "यह एक बैकअप टूल है"। बैकअप सुरक्षा नहीं है, है ना?. तो रेस्टिक एक सुरक्षा उपकरण नहीं है। और "... प्राथमिक विशेषताओं में से एक ..."। आप फिर से सही हैं: यह एक विशेषता है। यानी सुरक्षा एक विशेषता है, जबकि बैकअप एक कार्यात्मक (लक्षित) पदनाम है।

@rawtaz

यह पूरी चर्चा हास्यास्पद रूप से मूर्खतापूर्ण, स्पष्ट रूप से होती जा रही है। मुझे विश्वास नहीं हो रहा है कि लोग कह रहे हैं कि 1234 जैसा पासवर्ड...

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

लेकिन मुझे लगता है कि यह समझना अधिक महत्वपूर्ण है कि पासवर्ड सुरक्षा और एन्क्रिप्शन वैकल्पिक होना चाहिए।

क्यों? बैकअप टूल में डिफ़ॉल्ट एन्क्रिप्शन "क्यों" होना चाहिए? सिर्फ इसलिए कि यह एक "बैकअप" टूल है? आप बस यही कह रहे हैं लेकिन इसका कोई कारण नहीं है।

कोई भी डिजाइन निर्णय सभी को खुश नहीं कर सकता। रेस्टिक सुरक्षा पर अधिक जोर देने के लिए _chooses_ और मेरे जैसे उपयोगकर्ता _love_ कि मजबूत एन्क्रिप्शन डिफ़ॉल्ट है।

• यदि आप सुरक्षा की परवाह नहीं करते हैं, तो आप डिफ़ॉल्ट रूप से सुरक्षित सिस्टम का _cannot_ दुरुपयोग कर सकते हैं। सबसे खराब स्थिति में, आपको कुछ त्रुटियां दिखाई देती हैं और एक समायोजित आदेश के साथ पुन: प्रयास करें।
• यदि आप सुरक्षा की परवाह करते हैं, तो एक असुरक्षित-दर-डिफ़ॉल्ट प्रणाली का विनाशकारी प्रभाव के लिए दुरुपयोग करने के कई तरीके हैं। एक फ़्लैग गुम है, और आपका संवेदनशील डेटा लीक हो गया है, शायद _irreversibly_.

ध्वज के लिए पूछना एक बात है जो पासवर्ड को छोड़ सकता है, लेकिन डिफ़ॉल्ट रूप से बिना एन्क्रिप्शन के लिए बहस करना उन सभी मौजूदा उपयोगकर्ताओं के लिए एक खतरनाक "पेंच है" जो रेस्टिक के एन्क्रिप्शन पर भरोसा कर रहे हैं। भयावह उपयोगकर्ता त्रुटियों की संभावना बहुत बड़ी है।

@cfbao

लेकिन मुझे लगता है कि यह समझना अधिक महत्वपूर्ण है कि पासवर्ड सुरक्षा और एन्क्रिप्शन वैकल्पिक होना चाहिए।

क्यों? बैकअप टूल में डिफ़ॉल्ट एन्क्रिप्शन "क्यों" होना चाहिए? सिर्फ इसलिए कि यह एक "बैकअप" टूल है? आप बस यही कह रहे हैं लेकिन इसका कोई कारण नहीं है।

"वैकल्पिक" "डिफ़ॉल्ट" के समान नहीं है। इस तरह की चूक बहस योग्य हो सकती है। लेकिन विकल्प होना ज्यादा महत्वपूर्ण है। जबकि हमारे पास कोई विकल्प नहीं है, लेकिन चूक से कोई लेना-देना नहीं है। यही तो बात है। पहले विकल्प प्रदान करें फिर चूक पर चर्चा करना समझ में आता है।

इस मामले में (मुद्दा) यह बहुत आसान है - --no-password या restic init समान ध्वज होने की संभावना होगी (डिफ़ॉल्ट रूप से अभी भी यह है कि रेस्टिक इनिट पर पासवर्ड का अनुरोध करता है), लेकिन यह सिर्फ है @ fd0 की अंतिम प्रतिक्रिया पर मेरा विचार। और इस समय कोई ईटीए नहीं है, इसके बारे में पूछने की कोई आवश्यकता नहीं है :)

इस बीच, एक डमी पासवर्ड का उपयोग करें :) मुझे लगता है कि एक उचित कार्यान्वयन में पासवर्ड/कुंजी को हटाने/अनसेट करने की क्षमता शामिल है जिसे पहले रेपो में प्रवेश करने के लिए उपयोग किया जाता था, इसलिए किसी को पूरे भंडार को फिर से नहीं बनाना चाहिए।

हालाँकि, एन्क्रिप्शन एक और चीज़ है, और उस दूसरे मुद्दे पर नज़र रखी जाती है।

मुझे नो पासवर्ड विकल्प की बहुत अधिक परवाह नहीं है, लेकिन आप डिफॉल्ट नो एन्क्रिप्शन के लिए बहस कर रहे थे:

तो पासवर्ड सुरक्षा और एन्क्रिप्शन केवल विकल्प के रूप में प्रदान किया जा सकता है और डिफ़ॉल्ट रूप से जगह में नहीं होना चाहिए।

BTW: चूक सॉफ्टवेयर की गुणवत्ता का प्रतीक है।

जो मुझे खतरनाक लगता है।

हालांकि मैं आम तौर पर @rawtaz के बिंदुओं से सहमत हूं, अगर चर्चा सख्ती से बिना पासवर्ड विकल्प (डिफ़ॉल्ट रूप से नहीं बदलने) के बारे में है, तो इसमें मेरी बहुत अधिक हिस्सेदारी नहीं है।

@cfbao

मुझे नो पासवर्ड विकल्प की बहुत अधिक परवाह नहीं है, लेकिन आप डिफॉल्ट नो एन्क्रिप्शन के लिए बहस कर रहे थे:

तो पासवर्ड सुरक्षा और एन्क्रिप्शन केवल विकल्प के रूप में प्रदान किया जा सकता है और डिफ़ॉल्ट रूप से जगह में नहीं होना चाहिए।

आप इस उद्धरण में भी देख सकते हैं कि "विकल्प" पहले हैं और "डिफ़ॉल्ट" अगला है। और वह बात फिर से है।

इस मामले में (मुद्दा) यह बहुत आसान है - --no-password या restic init समान ध्वज होने की संभावना होगी (डिफ़ॉल्ट रूप से अभी भी यह है कि रेस्टिक इनिट पर पासवर्ड का अनुरोध करता है), लेकिन यह सिर्फ है @ fd0 की अंतिम प्रतिक्रिया पर मेरा विचार। और इस समय कोई ईटीए नहीं है, इसके बारे में पूछने की कोई आवश्यकता नहीं है :)

इस बीच, एक डमी पासवर्ड का उपयोग करें :) मुझे लगता है कि एक उचित कार्यान्वयन में पासवर्ड/कुंजी को हटाने/अनसेट करने की क्षमता शामिल है जिसे पहले रेपो में प्रवेश करने के लिए उपयोग किया जाता था, इसलिए किसी को पूरे भंडार को फिर से नहीं बनाना चाहिए।

डमी पासवर्ड का समर्थन करने के लिए रेस्टिक के लिए शायद एक आसान समाधान होगा कि यदि उपयोगकर्ता द्वारा कोई पासवर्ड निर्दिष्ट नहीं किया गया है तो यह मौजूदा भंडार खोलने का प्रयास करेगा।

डमी पासवर्ड को संभालने के संबंध में: कोई स्पष्ट सर्वश्रेष्ठ डमी पासवर्ड नहीं है जो सभी के लिए काम करता हो। 1234 एक कष्टप्रद डमी पासवर्ड है क्योंकि इसे ऊपर जाने और टाइप करने के लिए चार अंगुलियों की आवश्यकता होती है। उदाहरण के लिए "asdf" टाइप करने के लिए बहुत तेज़ है। साथ ही कुछ सेवाएं पासवर्ड विकल्पों को प्रतिबंधित करती हैं, इसलिए केवल संख्याएं या केवल चार अंक संभव नहीं हो सकते हैं। इसलिए रेस्टिक के अंदर एक समाधान सबसे अधिक उपयोगकर्ता के अनुकूल होगा। तब यूजर्स को केवल एक बार डमी पासवर्ड टाइप करना होगा।

डिज़ाइन के दृष्टिकोण से सुरक्षा की दृष्टि से, किसी भी प्रकार का डमी पासवर्ड प्रदान करना एक बुरा विचार है।

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

नकली या डमी हार्डकोडेड पासवर्ड के एक सेट को रेस्टिक ट्राई करने से बस परेशानी हो रही है। क्या होगा यदि कोई गरीब आत्मा आपके प्रस्तावित "जादू" पासवर्ड में से एक को चुन ले? क्या हम उन्हें हमारे विशेष नकली, नकली एन्क्रिप्शन पासवर्ड चुनने से आगाह करते हैं? "नहीं टेड, आप अपने रिपॉजिटरी पासवर्ड के रूप में SPACECHICKEN नहीं चुन सकते, यह _special_ है।" ;)

मैं उपयोगकर्ताओं को ("--नो-रिपोजिटरी-पासवर्ड") के साथ पैर में खुद को शूट करने के लिए एक विकल्प प्रदान करने के साथ ठीक हूं, लेकिन मुझे नहीं लगता कि रेस्टिक को इससे आगे जाना चाहिए ताकि उपयोगकर्ताओं के बहुत छोटे खंड को खुश किया जा सके। कम सुरक्षा की इच्छा।

डिज़ाइन के दृष्टिकोण से सुरक्षा की दृष्टि से, किसी भी प्रकार का डमी पासवर्ड प्रदान करना एक बुरा विचार है।

पासवर्ड न देने की अनुमति देने से भी बदतर क्यों है?

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

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

नकली या डमी हार्डकोडेड पासवर्ड के एक सेट को रेस्टिक ट्राई करने से बस परेशानी हो रही है। क्या होगा यदि कोई गरीब आत्मा आपके प्रस्तावित "जादू" पासवर्ड में से एक को चुन ले? क्या हम उन्हें हमारे विशेष नकली, नकली एन्क्रिप्शन पासवर्ड चुनने से आगाह करते हैं? "नहीं टेड, आप अपने रिपॉजिटरी पासवर्ड के रूप में SPACECHICKEN नहीं चुन सकते, यह _special_ है।" ;)

वास्तव में समस्या क्या है? टेड अब भी यह पासवर्ड चुन सकता है। इसका सीधा सा मतलब है कि अगर वे इसे निर्दिष्ट नहीं करते हैं तो रेस्टिक आसानी से इसका इस्तेमाल करेंगे। रेस्टिक अभी भी रिपॉजिटरी को उसी तरह एन्क्रिप्ट/डिक्रिप्ट करेगा जैसे कि एक विशेष पासवर्ड नहीं था।

मैं उपयोगकर्ताओं को ("--नो-रिपोजिटरी-पासवर्ड") के साथ पैर में खुद को शूट करने के लिए एक विकल्प प्रदान करने के साथ ठीक हूं, लेकिन मुझे नहीं लगता कि रेस्टिक को इससे आगे जाना चाहिए ताकि उपयोगकर्ताओं के बहुत छोटे खंड को खुश किया जा सके। कम सुरक्षा की इच्छा।

इसे "खुद को पैर में गोली मारो" कहना अनावश्यक रूप से न्यायपूर्ण है और यह भी कम सुरक्षा का संकेत नहीं देता है। रैंसमवेयर के खिलाफ उपलब्धता और लचीलापन एक सुरक्षा अवधारणा का हिस्सा होना चाहिए। एन्क्रिप्शन पासवर्ड की अनुपलब्धता के कारण बैकअप को पुनर्स्थापित करने की अनुपलब्ध क्षमता सुरक्षा को कम कर देगी। बैकअप को केवल-उपलब्ध भंडारण प्रणाली में सुरक्षित रूप से संग्रहीत करने से यहां सुरक्षा स्तर कम नहीं होगा।

Why is it worse than allowing no password?

मुझे यकीन नहीं है कि मैं किसी को यह समझाने के बारे में कैसे जाउंगा कि हार्डकोडेड, छुपा, गुप्त रूप से भंडार पासवर्ड के खिलाफ कोशिश की गई है, यह एक बुरा विचार होगा। यदि आपको लगता है कि वे हैं, तो संभवत: कोई सुरक्षा केंद्रित तर्क नहीं है जो आपको आश्वस्त करेगा।

What exactly is the problem? Ted can still choose this password. It just means that restic conveniently will use it if they do not specify it. Restic would still encrypt/decrypt the repository the same way as if was not a special password.

मैंने एक मनोरंजक उदाहरण चुना, शायद मुझे नहीं करना चाहिए था। आइए मान लें कि आपका डमी पासवर्ड जिसे आप गुप्त रूप से रखना चाहते हैं और डिक्रिप्शन विफल होने पर स्वचालित रूप से प्रयास करें: "12345"। एक भोला उपयोगकर्ता इसे अपने पासवर्ड के रूप में बहुत अच्छी तरह से चुन सकता है। अब उनके पास एक भंडार है जो उनका मानना ​​​​है कि एन्क्रिप्ट किया गया है (और तरह का है) लेकिन _anyones_ रेस्टिक डिक्रिप्ट कर सकता है। यह तर्क आपके द्वारा अपने हार्डकोड किए गए सेट में चुने गए पासवर्ड के किसी भी सेट के लिए लागू होता है। यह मौलिक रूप से खराब सुरक्षा डिजाइन है।

आप जो प्रस्ताव दे रहे हैं उसके लिए एक शब्द है। इसे एन्क्रिप्शन बैकडोर कहा जाता है :) दस्तावेज़ों में उस पिछले दरवाजे को छिपाने का मतलब है कि सभी पाठक रेस्टिक का उपयोग करने से पहले मैनुअल को पूरी तरह से पढ़ लेंगे। क्या यह अधिक लोगों की ज़रूरतों को पूरा नहीं करेगा कि उन्हें दस्तावेज़ों को पढ़ने के लिए यह निर्धारित करने के लिए कि कैसे सुरक्षित रूप से कम करना चाहिए, क्या वे अजीब तरह से चाहते हैं?

Calling this "shoot themselves in the foot" is unnecessarily judgmental and also it does not imply reduced security. Availability and resilience against ransomware should be part of a security concept. The missing ability to restore a backup because of missing access to the encryption password would lessen the security. Storing the backup securely to an append-only storage system would not decrease the security level, here.

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

यहां तक ​​​​कि केवल स्टोरेज मीडिया को जोड़ने का आपका उदाहरण आराम-एन्क्रिप्शन से दृढ़ता से लाभान्वित होगा। मैं यहाँ सर्वोत्तम प्रथाओं में मार्गदर्शन के लिए NIST, ISO 27002, NERC, IEC 62443 या वास्तव में किसी भी विश्व स्तर पर स्वीकृत मानक के हालिया सेट को पढ़ने की सलाह दूंगा। हम नए क्षेत्र में नहीं हैं।

मुझे यह भी बताना चाहिए कि हम इस धागे में दो मुद्दों का प्रभावी ढंग से सामना कर रहे हैं: कुंजी प्रबंधन और एन्क्रिप्शन।

शायद यहीं से भ्रम पैदा होता है।

हो सकता है कि इस मुद्दे को दस्तावेज़ीकरण द्वारा हल किया जा सकता है जो कुछ ऐसा कहता है:

यदि आप अपने भंडार को पासवर्ड से सुरक्षित नहीं करना चाहते हैं, तो बस स्ट्रिंग का उपयोग करें: password

इस तरह किसी भी कुंजी को प्रबंधित किए बिना रेस्टिक के साथ बैकअप/पुनर्स्थापना प्राप्त करने का एक प्रसिद्ध तरीका है।

Why is it worse than allowing no password?

मुझे यकीन नहीं है कि मैं किसी को यह समझाने के बारे में कैसे जाउंगा कि हार्डकोडेड, छुपा, गुप्त रूप से भंडार पासवर्ड के खिलाफ कोशिश की गई है, यह एक बुरा विचार होगा। यदि आपको लगता है कि वे हैं, तो संभवत: कोई सुरक्षा केंद्रित तर्क नहीं है जो आपको आश्वस्त करेगा।

मुझे लगता है कि आप वहां "नहीं" खो रहे हैं ...

What exactly is the problem? Ted can still choose this password. It just means that restic conveniently will use it if they do not specify it. Restic would still encrypt/decrypt the repository the same way as if was not a special password.

मैंने एक मनोरंजक उदाहरण चुना, शायद मुझे नहीं करना चाहिए था। आइए मान लें कि आपका डमी पासवर्ड जिसे आप गुप्त रूप से रखना चाहते हैं और डिक्रिप्शन विफल होने पर स्वचालित रूप से प्रयास करें: "12345"। एक भोला उपयोगकर्ता इसे अपने पासवर्ड के रूप में बहुत अच्छी तरह से चुन सकता है। अब उनके पास एक भंडार है जो उनका मानना ​​​​है कि एन्क्रिप्ट किया गया है (और तरह का है) लेकिन _anyones_ रेस्टिक डिक्रिप्ट कर सकता है। यह तर्क आपके द्वारा अपने हार्डकोड किए गए सेट में चुने गए पासवर्ड के किसी भी सेट के लिए लागू होता है। यह मौलिक रूप से खराब सुरक्षा डिजाइन है।

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

आप जो प्रस्ताव दे रहे हैं उसके लिए एक शब्द है। इसे एन्क्रिप्शन बैकडोर कहा जाता है :) दस्तावेज़ों में उस पिछले दरवाजे को छिपाने का मतलब है कि सभी पाठक रेस्टिक का उपयोग करने से पहले मैनुअल को पूरी तरह से पढ़ लेंगे। क्या यह अधिक लोगों की ज़रूरतों को पूरा नहीं करेगा कि उन्हें दस्तावेज़ों को पढ़ने के लिए यह निर्धारित करने के लिए कि कैसे सुरक्षित रूप से कम करना चाहिए, क्या वे अजीब तरह से चाहते हैं?

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

Calling this "shoot themselves in the foot" is unnecessarily judgmental and also it does not imply reduced security. Availability and resilience against ransomware should be part of a security concept. The missing ability to restore a backup because of missing access to the encryption password would lessen the security. Storing the backup securely to an append-only storage system would not decrease the security level, here.

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

आपकी राय में असुरक्षित डिफ़ॉल्ट क्या है?

यहां तक ​​​​कि केवल स्टोरेज मीडिया को जोड़ने का आपका उदाहरण आराम-एन्क्रिप्शन से दृढ़ता से लाभान्वित होगा। मैं यहाँ सर्वोत्तम प्रथाओं में मार्गदर्शन के लिए NIST, ISO 27002, NERC, IEC 62443 या वास्तव में किसी भी विश्व स्तर पर स्वीकृत मानक के हालिया सेट को पढ़ने की सलाह दूंगा। हम नए क्षेत्र में नहीं हैं।

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

इस धागे से सदस्यता समाप्त कर रहा है ...

आइए इसे यहीं पर छोड़ दें, यह स्पष्ट है कि कुछ लोग --no-password से init विकल्प चाहते हैं, और बस यही इस मुद्दे के बारे में है। एन्क्रिप्शन या नहीं एक अलग मुद्दा है।

यहाँ बस एक त्वरित टिप्पणी:
मैं एक ऐसा उपयोगकर्ता हूं जो एन्क्रिप्शन की परवाह नहीं करता है। मेरे डेटा के बारे में कुछ भी संवेदनशील नहीं है। मैं उन लोगों के बारे में परवाह करता हूं जो 20-40 वर्षों में उपयोग करने में सक्षम हैं जो मैं नहीं हूं। बस rclone का उपयोग करना एक और खराब विकल्प है।

इसके लिए रेस्टिक एक अच्छे टूल की तरह दिखता है, एन्क्रिप्शन को अनिवार्य करने के अलावा और पासवर्ड का मतलब है कि मुझे इसे ध्यान में रखना होगा। शायद बैकअप रिपोजिटरी में एक रीडमे। यह अधिक काम है और कोई भी समाधान (मेरी तरफ से) वैसे भी किसी भी एन्क्रिप्शन को हरा देता है।

निशान

आपके योगदान के लिए धन्यवाद, मुझे लगता है कि हमने पर्याप्त जानकारी एकत्र कर ली है।