Restic: السماح بكلمات مرور فارغة

يجب أن تسمح Restic بكلمات المرور الفارغة.

هل يمكنك توضيح ما هي حالة الاستخدام الخاصة بك؟ لماذا يجب أن تسمح restic بكلمات مرور فارغة؟

إنه قرار تصميم.

بالتاكيد هو. لكني أشعر بالفضول فيما تحاول تحقيقه.

القضية ذات الصلة ربما تكون # 1018

أردت فقط نسخ بعض الدلائل احتياطيًا مؤقتًا على نظامي المحلي كشبكة أمان سريعة عند تغيير الملفات في دليل. لا أريد أن أتذكر عبارة مرور أو أن أزعجني لإدخال عبارة مرور في كل مرة أريد إنشاء نسخة احتياطية. نظرًا لأنني استخدمت للتو a ككلمة مرور ، فلا توجد فائدة أمنية حقيقية في استخدام كلمة المرور هذه مقارنة بعدم استخدام كلمة مرور على الإطلاق. لذلك ، فإن أي حمل منخفض للتذكر أو إدخال كلمة مرور عديمة الفائدة يجعل الأداة أقل مثالية.

شكرا على الشرح. أود الاحتفاظ بهذا الفحص في مكانه ، لذلك أغلق هذه المشكلة في الوقت الحالي. لا تتردد في إضافة المزيد من التعليقات. شكرا!

عندما تحدثنا عن هذا منذ فترة قلت أنه سيكون هناك نقاش ...
هل يمكنك أن تشرح لماذا تعتبر هذا الفحص مفيدًا؟ يجب أن يظل المستودع مشفرًا بحيث يمكن إضافة كلمة مرور بعد ذلك.

أنا أعتبر هذا الفحص مفيدًا لأنه من واقع خبرتي ، سيرغب معظم المستخدمين في تعيين كلمة مرور. قد يؤدي قبول كلمة مرور فارغة ، أو حتى وجود مسار رمز يسمح بقبول كلمات المرور الفارغة ، إلى قيام المستخدمين بحفظ نسخهم الاحتياطية بطريق الخطأ في مواقع بعيدة دون تشفير مناسب. أحد المواقف التي قد يحدث فيها هذا هو عندما لا يتم تصدير متغير البيئة RESTIC_PASSWORD أو يتم تعيينه على سلسلة فارغة عن طريق الخطأ.

لذلك ، في هذه الحالة ، أشعر أن حماية المستخدمين من الخطأ أفضل من إزالة الإزعاج البسيط المتمثل في الاضطرار إلى تعيين كلمة مرور :)

هناك حلول سهلة لذلك: استخدم مدير كلمات المرور ، واستخدم السلسلة test ، وقم بتصدير RESTIC_PASSWORD بشكل ثابت عبر ملف ، على سبيل المثال في /etc/profile.d ، استخدم اسم الدليل الذي تريده يتم الحفظ (أو المستودع) ككلمة المرور ...

يرجى ملاحظة أن المعرفة بكلمة المرور الخاصة بك مطلوبة للوصول إلى المستودع.
يعني فقدان كلمة المرور أن بياناتك ستفقد بشكل غير قابل للاسترداد.

كيف يمكنني منع حدوث ذلك إذا كنت لا أرغب في فقدان بياناتي إلى الأبد؟

LexSong استخدم مدير كلمات المرور.

في الثلاثاء ، يوليو 03 ، 2018 الساعة 09:56:56 صباحًا -0700 ، كتب تشينفينج باو:

LexSong استخدم مدير كلمات المرور.

كيف تقترح إجراء نسخ احتياطي لقاعدة بيانات مدير كلمات المرور؟ هل
اقترح هنا استخدام مدير كلمات المرور مع قاعدة بيانات بدون ملف
كلمه السر؟ مدير كلمات المرور الذي يدعم restic للحصول على ملف
كلمة السر من؟

تعد إدارة كلمات المرور موضوعًا ضخمًا لا أريد الخوض في الكثير من التفاصيل في هذا الموضوع. فقط أشير إلى أنه إذا تم إجراؤها بشكل صحيح ، فلا ينبغي أن تكون كلمات المرور مشكلة. هناك العديد من الموارد على الإنترنت.

يجب أن تكون قاعدة بيانات مدير كلمات المرور مشفرة بالفعل بشكل صحيح ، بحيث يمكنك وضعها في أي مكان تريد دون طبقة أخرى من التشفير. هناك أيضًا العديد من خدمات إدارة كلمات المرور المستندة إلى السحابة ، لذلك لا داعي للقلق بشأن النسخ الاحتياطية بنفسك.

بالنسبة إلى دعم restic ، يمكنك فقط وضع كلمة المرور في ملف نص عادي محليًا واستخدام الخيار --password-file . ثم لا تحتاج إلى إدخال كلمة المرور يدويًا. يجب أيضًا وضع كلمة المرور نفسها في مدير كلمات المرور للتسجيل.

في نهاية اليوم ، هناك دائمًا كلمة مرور / عبارة مرور واحدة معقدة يتعين عليك حفظها للحفاظ على أمان الأشياء حقًا.

في الواقع ، إذا كنت لا تريد حقًا كلمة مرور على مستودع ثابت ، فلماذا لا تستخدم فقط كلمة مرور وهمية مكونة من حرف واحد؟

كان استخدام "a" ككلمة مرور هو الحل البديل الخاص بي بالفعل ولكن لا أشعر أنه مناسب لأنني لا أستطيع التأكد من أنني أتذكر استخدام هذا عندما أرى هذا الريبو لسبب ما مرة أخرى في غضون بضع سنوات في حال نسيت حذفه عندما لا أحتاج اليه بعد الآن. لذلك قد أضطر إلى تنفيذ نوع من الإجبار الغاشم لمعرفة ذلك. هذا كل عمل يمكن تجنبه.

في الماضي ، استخدمت بالفعل كلمات مرور مؤقتة بسيطة في المواقف التي تركتني في هذه الحالة عند حماية قرص صلب خارجي مؤقتًا بكلمة مرور لتسهيل حذفه بعد ذلك. ومع ذلك ، لم أحذفه ، لذا عندما أردت استخدامه في المرة القادمة ، أردت التأكد من عدم وجود أي شيء مهم على محرك الأقراص. للأسف ، لم تعد كلمة المرور من مدير كلمات المرور تعمل بعد الآن لأنني نسيت تحديثها / إزالتها من هناك. لذلك عندما أفكر في نفسي في المستقبل ، يبدو أنها فكرة جيدة أن أجعل الأمر أسهل بالنسبة له من خلال عدم إنشاء مستودعات ثابتة لا أستطيع فك تشفيرها.

لدي فكرة أخرى ، ماذا عن restic سيحاول استخدام "restic" ككلمة مرور افتراضية عندما لا توجد كلمة مرور للوصول إلى المستودع والعودة إلى رسالة الخطأ إذا لم تعمل؟ ثم يمكن للمستخدمين استخدام كلمة المرور هذه للإشارة إلى أنهم لا يحتاجون إلى تشفير ، وسوف يفتحها restic دون سحر إضافي.

أوافق على التعليقات السابقة للحفاظ على التحقق من الحماية من أخطاء المستخدم.

يحتاج Restic إلى دعم كلمات المرور الفارغة للأسباب التي سبق ذكرها. أنا
على وجه التحديد لا أريد تشفير النسخ الاحتياطية المحلية الخاصة بي لأنني لا أريد
لتفقد الوصول إليها. لا أريد المخاطرة بنسيان كلمة المرور و
عدم القدرة على استعادة البيانات. هذه مخاطرة حقيقية لأن المستخدمين عادة
نادرًا جدًا ، وغالبًا ما يتم تشغيل النسخ الاحتياطية غير المراقبة التي لا يفعلون ذلك
بحاجة إلى إدخال كلمة المرور ، مما يزيد من احتمالية نسيانها.

يعد تخزين كلمة المرور في ملف أو برنامج نصي حلاً بديلاً عرضة للخطأ لملف
مشكلة لا ينبغي أن توجد.

أوافق على وجوب توخي الحذر لمنع التحميل عن طريق الخطأ
البيانات غير المشفرة إلى وحدات إعادة الشراء البعيدة.

يبدو أن الحل البسيط هو أن يكون لديك خيار سطر أوامر ،
--allow-empty-password . يمكن للمستخدمين ضبط هذا التبديل في نصوصهم و
قد يظل الافتراضي يتطلب كلمة مرور.

هذه مخاطرة حقيقية لأن المستخدمين عادةً ما يستعيدون نادرًا جدًا ، وغالبًا ما يقومون بتشغيل نسخ احتياطية غير مراقبة لا يحتاجون إلى إدخال كلمة المرور من أجلها ، مما يزيد من احتمال نسيانها.

لا يُقصد من كلمات المرور الاحتياطية حفظها في الذاكرة. كلمة مرور التشفير المعقدة الوحيدة التي تحتاج إلى تذكرها هي كلمة مرور مدير كلمات المرور الخاصة بك ، والتي ستستخدمها كثيرًا. ويجب عليك _ حقًا_ استخدام مدير كلمات المرور.

يعد تخزين كلمة المرور في ملف أو برنامج نصي حلاً بديلاً عرضة للخطأ لمشكلة لا ينبغي أن تكون موجودة.

عذرًا ، أنا فقط لا أرى كيف أنه حل بديل عرضة للخطأ. يبدو أنها طريقة صالحة تمامًا لأتمتة التشفير بالنسبة لي. يتم حل المشكلة ، مرة أخرى ، باستخدام مدير كلمات المرور.

يبدو أن الحل البسيط هو أن يكون لديك خيار سطر أوامر ، --allow-empty-password . يمكن للمستخدمين ضبط هذا التبديل في البرامج النصية الخاصة بهم ويمكن أن يظل الإعداد الافتراضي يتطلب كلمة مرور.

يبدو أن هذا وسيلة معقولة لتجنب أخطاء المستخدم. ومع ذلك ، لا تزال هناك مخاوف بشأن زيادة سطح الهجوم ، وتحتاج إلى معالجة بحذر شديد.

لا يُقصد من كلمات المرور الاحتياطية حفظها في الذاكرة. كلمة مرور التشفير المعقدة الوحيدة التي تحتاج إلى تذكرها هي كلمة مرور مدير كلمات المرور الخاصة بك ، والتي ستستخدمها كثيرًا. ويجب عليك حقًا استخدام مدير كلمات المرور.

مدير كلمات المرور ليس حلاً صالحًا على الإطلاق لهذه المشكلة. بيت القصيد من عمل النسخ الاحتياطية هو الاحتفاظ بنسخة احتياطية من ملفاتك ، داخل مجموعة النسخ الاحتياطي المشفرة؟

عند تصميم نظام نسخ احتياطي ، يجب أن تخطط لأسوأ سيناريو ، والذي يتضمن الاستعادة عندما لا يتوفر لديك أي شيء باستثناء النسخة الاحتياطية. من الواضح أن ما تفعله هو نسخ قاعدة بيانات مدير كلمات المرور احتياطيًا بشكل منفصل عن النسخ الاحتياطية الخاصة بـ Restic. هذا جيد بالنسبة لك ، لكن ليس لك أن تفرض هذا النظام على مستخدمين آخرين. ومن السخف أن نقول إن مدير كلمات المرور ضروري لاستخدام Restic ، خاصةً عندما لا يكون مصممًا حتى للتكامل مع واحد. إذا كان الأمر كذلك ، من فضلك أرني الوثائق الخاصة بهذا المعنى.

تهدف Restic ، مثل الكثير من البرامج ، إلى تمكين المستخدمين من تلبية احتياجاتهم. لا تتضمن احتياجاتك سيناريو استعادة النسخة الاحتياطية من المعدن ، ولا شيء سوى النسخ الاحتياطي. احتياجات المستخدمين الآخرين تفعل ذلك. من فضلك لا تملي عليهم احتياجات الآخرين.

يبدو أن هذا وسيلة معقولة لتجنب أخطاء المستخدم. ومع ذلك ، لا تزال هناك مخاوف بشأن زيادة سطح الهجوم ، وتحتاج إلى معالجة بحذر شديد.

ما هي المخاوف المحددة التي تراها فيما يتعلق بسطح الهجوم المتزايد الناتج عن الخيار --allow-empty-password المقترح؟

يبدو أن هذا وسيلة معقولة لتجنب أخطاء المستخدم. ومع ذلك ، لا تزال هناك مخاوف بشأن زيادة سطح الهجوم ، وتحتاج إلى معالجة بحذر شديد.

كانت فكرتي الأخرى هي أن تستخدم restic كلمة مرور افتراضية للوصول إلى مستودع عندما لا يتم تحديد كلمة مرور ، على سبيل المثال restic . ثم لا تتغير واجهة المستخدم الخاصة بإنشاء مستودع جديد وفقط عندما يستخدم المستخدم كلمة المرور الافتراضية ، سيتمكن تلقائيًا من الوصول إلى المستودع ولا يحتاج المستخدم إلى تذكر كلمة المرور.

عذرًا ، أنا فقط لا أرى كيف أنه حل بديل عرضة للخطأ. يبدو أنها طريقة صالحة تمامًا لأتمتة التشفير بالنسبة لي. يتم حل المشكلة ، مرة أخرى ، باستخدام مدير كلمات المرور.

طالما أنه لا يوجد تكامل مع مدير كلمات المرور ، فلا يزال هناك خطر من أن القيمة الموجودة في مدير كلمات المرور خاطئة أو قديمة أو تم حذفها عن طريق الخطأ حيث ستكون هناك نسخة من كلمة المرور خارج مدير كلمات المرور.

أود أيضًا أن أرى خيارًا للسماح بكلمة مرور فارغة (من خلال استخدام علامة --allow-empty-password ، أو ربما شيء أكثر تفصيلاً / فريدًا لتسليط الضوء على المخاطر ، مثل NRPE's --dont-blame-nrpe flag).

حالات الاستخدام الخاصة بي:

• الأعمال: لدينا مستودع موجود في بيئة موثوق بها نحتاج إلى "أي شخص" لاستعادته في حالة الطوارئ / الكوارث دون الحاجة إلى معرفة خاصة (أي كلمة مرور المستودع).
• الصفحة الرئيسية: أرغب في إنشاء نسخة احتياطية ثابتة لأشياء مثل صور العائلة. هذه ليست سرية بشكل خاص ، وفي حالة وفاتي المبكرة ، يجب أن تكون عائلتي قادرة على الوصول إلى هذه البيانات المهمة شخصيًا بأقل قدر من المقاومة (_ على سبيل المثال ، دون الحاجة إلى العثور على عبارة مرور في خزنة ، ربما يكون ذلك خارج- التاريخ أو مختلطة مع آخر_).

أفهم الحاجة إلى عبارة مرور لضمان سلامة البيانات وكذلك التشفير. أرى أن الملف (الملفات) في الدليل keys يبدو ككائن JSON. ربما يمكن إنشاء مفتاح psuedo-random (بدلاً من عدم وجود مفتاح) وتخزينه هناك؟ هذا لا يساعد المستخدمين الذين يحاولون تجنب عبء التشفير لأسباب تتعلق بالأداء.

@ fd0 ما رأيك في خيار سطر الأوامر --allow-empty-password المقترح؟ قد يتطلب عبارات مرور بشكل افتراضي ، ولكنه يسمح للمستخدمين بتجاوزها عند الضرورة.

ويرجى النظر في إعادة فتح هذه القضية. تتضمن احتياجات العديد من المستخدمين النسخ الاحتياطي للملفات غير السرية دون المخاطرة بفقدان الوصول بسبب عبارات المرور المنسية أو في غير محلها.

مستخدم جديد للراحة هنا - لم يقم حتى بإنشاء مستودع التخزين الأول الخاص بي حتى الآن - ولكن سنوات من الخبرة مع الأدوات الأخرى - المفضل لدي هو "التفريغ" القديم الجيد. مع الاحترام ، هذا أمر لا يحتاج إلى تفكير - بالطبع يجب السماح بكلمات المرور الفارغة. بكل الوسائل ، أضف علامة لتقليل مخاطر الخطأ غير المقصود ، ولكن يرجى عدم إملاء حالات الاستخدام على المستخدمين ذوي الخبرة (المحتملين) الذين أشاروا بوضوح إلى احتياجات أخرى.
كل ما أحاول القيام به هو عمل نسخ احتياطية محلية من أجل السلامة ؛ لا يمثل الأمان مشكلة ، ومن المرجح أن أفقد كلمة المرور أكثر مما أحتاج إلى النسخ الاحتياطي. وأنا أكره مديري كلمات المرور ...

إن وجود متطلبات كلمة المرور يجعل من الصعب أتمتة النسخ الاحتياطية ، والحاجة إلى توفير كلمة المرور في بيئة أو ملف نصي يجعل كل شيء أمني عديم الفائدة في المقام الأول.

الحاجة إلى توفير كلمة المرور في بيئة أو ملف نصي يجعل كل شيء أمني عديم الفائدة في المقام الأول.

هذا ليس صحيحًا بالضرورة. هناك طرق جيدة للقيام بذلك.

هذا ليس صحيحًا بالضرورة. هناك طرق جيدة للقيام بذلك.

من فضلك لا تكرر هذه الحجة هنا. يحتاج العديد من المستخدمين إلى عمل نسخ احتياطية لكلمة المرور غير مشفرة أو فارغة. إذا لم تكن واحدًا منهم ، فهذا جيد لك.

@ mholt ، أي توصيات؟ سأكون أكثر من سعيد لعمل نسخ احتياطي للخوادم الخاصة بي بدون أي تدخل مع أقصى درجات الأمان.

يحتاج العديد من المستخدمين إلى عمل نسخ احتياطية لكلمة المرور غير مشفرة أو فارغة.

هذه عادة مشكلة XY .

@ mholt ، أي توصيات؟ سأكون أكثر من سعيد لعمل نسخ احتياطي للخوادم الخاصة بي بدون أي تدخل مع أقصى درجات الأمان.

يعتمد بشكل كبير على الموقف الخاص بك ، ونموذج التهديد ، والبيئة ، والمخاطر المقبولة ، والأهداف الفنية وقابلية الاستخدام. لذا لا ، ليس لدي مجموعة شاملة من التوصيات لأي شخص.

هذه عادة مشكلة XY.

لذا لا ، ليس لدي مجموعة شاملة من التوصيات لأي شخص.

هذا الموقف المتعالي ليس مفيدًا. والأسوأ من ذلك أنه بعد إخبارنا بأن احتياجاتنا خاطئة ، فإنك ترفض تقديم أي نصيحة. هذا مشروع البرمجيات الحرة والمفتوحة المصدر ، وليس شركة Apple.

على سبيل المثال ، لا أحتاج ولا أريد تشفير النسخ الاحتياطية المحلية لبياناتي غير المشفرة بالفعل. إذا فشل قرصي الأساسي وأحتاج إلى استعادة النسخ الاحتياطية الخاصة بي ، فسيتم تخزين عبارة المرور داخل مستودع النسخ الاحتياطي مع البرامج النصية وملفات التكوين الخاصة بي. شاغلي الأساسي هو عدم منع الآخرين من الوصول إلى هذه البيانات غير الحساسة - شاغلي الأساسي هو سهولة الاسترداد وعدم إقفال بياناتي.

هذه حالة شائعة للعديد من المستخدمين ، وليس لك أن تقرر ما هي احتياجات المستخدمين.

البرمجيات موجودة لخدمة المستخدمين ، وليس لإجبار المستخدمين على الإذعان لمطالبها.

نشكرك على توضيح حالة (حالات) الاستخدام الخاصة بك وما يقلقك مرة أخرى. للتسجيل ، أعتقد أنها صالحة ، وخاصة واحدة "فقدت كلمة المرور". أعتقد أيضًا أن علامة خاصة لـ restic init مثل --allow-empty-password ستعمل (لدي بعض الاعتبارات لحالات الزاوية ، لكنني على ثقة من أنه يمكن حلها). لذلك سأعيد فتح هذه المشكلة.

يرجى الانتباه إلى أن السماح لكلمات المرور الفارغة سيعالج مشكلة الأمان المتعلقة بـ "فقدان كلمة المرور" ، ولكنه سيظل يشفر جميع البيانات كالمعتاد.

في ملاحظة مختلفة ، لا أحب النغمة في هذا الموضوع على الإطلاق. أنت حر في عدم استخدام restic ، هذا جيد تمامًا. يعمل معظمنا على restic في أوقات فراغنا. تظهر بعض التعليقات في هذا الموضوع على أنها معاد صياغتها: "يجب عليك تنفيذ هذه الميزة ، هناك مستخدمون يحتاجون إليها!". هذا ليس هو الحال. يمكننا التفكير في ذلك وتنفيذه ، ولكن يمكننا أيضًا أن نقرر عدم القيام بأي شيء.

لذا ، من فضلكم ، دعونا نجعل هذه المناقشة مثمرة ، حتى لو كنتم غير موافقين. :)

@ fd0 اغفر لي لكوني غير واضح. أنا لا أطالب أو أتوقع أي شيء منك أو من أي من مطوري Restic. إنه مشروعك ووقتك ، ويمكنك العمل على ما تريد.

ما أطلبه هو أن تفكر في هذه الميزة وحالة الاستخدام. إذا لم تكن مهتمًا بتنفيذها بنفسك ، فلا بأس بذلك ، وأطلب منك ترك القضية مفتوحة حتى يتمكن الآخرون من مناقشتها ، وأن تفكر في أي علاقات عامة قد تنفذها.

ما أعترض عليه هو التعليقات (وليس تعليقاتك) التي تشير إلى أن المستخدمين الذين يريدون هذه الميزة لا يفهمون احتياجاتهم الخاصة ، خاصة عندما يتبعها رفض اقتراح البدائل. هذا ضجيج وقح وغير مفيد.

بالنسبة لي ، أنا أستخدم git-Annex مع جهاز تحكم عن بعد خاص bup. يدعم الملحق بالفعل تشفير الملفات (التي قمت بإيقافها ، للاستفادة من ميزة إزالة الأخطاء في bup). ثم أقوم بعمل نسخة احتياطية من bup repo (وهو مجرد مستودع git رائع) إلى خادم بعيد. يمكنني بعد ذلك حذف bup repo ، لأنه مجرد ذاكرة تخزين مؤقت ، والقيام باستعادة عبر restic ، حسب الحاجة.

لذلك ، بشكل أساسي ، أقوم بتجميع مجموعة من الأدوات ذات الاستخدام الفردي معًا ، بطريقة Unix (tm) ، حيث يقوم كل منها بعمله بشكل جيد. تقوم Restic (أنا الآن بالتبديل من الازدواجية) بإلغاء تكرار النوافذ المنزلقة والكتلة ، إلى سحابة بعيدة ، وهذا كل ما أحتاجه للقيام به. يحدث التشفير وإلغاء تكرار الكتلة المحلية في طبقة مختلفة. لذلك ، لا أرغب في تحديد كلمة مرور ، ولا أي تشفير (مما يوفر فعليًا استخدام وحدة المعالجة المركزية).

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

هذا نصف ما أريده فقط ، لأنه لا يزال مشفرًا ، لكن بكلمة مرور فارغة. أود استعادة استخدام وحدة المعالجة المركزية ، إذا كان بإمكاني.

يرجى الانتباه إلى أن السماح لكلمات المرور الفارغة سيعالج مشكلة الأمان المتعلقة بـ "فقدان كلمة المرور" ، ولكنه سيظل يشفر جميع البيانات كالمعتاد.

حسنًا ، ما الدافع وراء استمرار التشفير بكلمة مرور فارغة؟

أعني ، عند تشغيل restic على أجهزة منخفضة الطاقة ، يضيف التشفير بعض الحمل الملحوظ لوقت التشغيل.

تحرير: حسنًا ، 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 بكلمة مرور بشكل تفاعلي ثم:

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

شكرًا لك @ fd0 على إعادة فتح المشكلة. أتفق مع alphapapa ، في نيتي عدم دفع أي مطورين لقضاء وقت الفراغ لقضاء وقتهم في أي شيء لا يستمتعون به.

نحن فقط لا نحب أن يخبرنا الآخرون أننا لا نفهم حاجتنا الخاصة.

من وجهة نظري ، فإن أهم ميزة لأداة النسخ الاحتياطي هي القدرة على إجراء استعادة في أي حال. على الرغم من أن الأمان له أهمية كبيرة جدًا ، إلا أنه يعتمد على الموقف المحدد سواء كانت سلامة البيانات (القدرة على الاستعادة) أو أمن البيانات (الحماية من الوصول غير المصرح به) لها أولوية أعلى.

بالطبع ، يمكنك أن تقرر بحرية تطوير أداة فقط في المواقف التي يكون فيها الأمن أكثر أهمية من السلامة.

كما ذكر mholt "XY-Problem": الطلب هو أن تكون قادرًا على القيام باستعادة الكوارث دون أي معرفة تتجاوز التوثيق العام المتاح العام وبالطبع الوصول إلى المستودع نفسه.
"بدون أي معرفة" يستبعد الحاجة إلى مديري كلمات المرور أو استخدامها.

السبب في أنني وجدت هذه المشكلة هو: _أنا أساعد بعض الأشخاص في استخدام أجهزة الكمبيوتر الخاصة بهم على انفراد. تعاملهم مع كلمات المرور هو فوضى ، محاولة تعليمهم التعامل الصحيح مع كلمة المرور أثناء إعداد نسخة احتياطية على محركات أقراص USB لن يؤدي إلا إلى عدم إنشاء نسخ احتياطية على الإطلاق أو عدم إتاحة كلمة المرور عند الحاجة. قد يحصلون على مساعدة من شخص آخر عندما يحتاجون إلى استعادة ، لذا فإن أي شيء أتوصل إليه للتخفيف من الموقف قد يكون باطلاً.

في الوقت الحالي ، أقوم بحفظ كلمة المرور في ملف نصي على نفس محرك أقراص USB مثل مستودع النسخ الاحتياطي الثابت ، مما يفسد أمان الحصول على كلمة مرور تمامًا.
وأنا لا أحب هذا الحل لأن استخدام كلمة مرور لا تعطي أي طبقة إضافية من الأمان يعطي تخيلًا خاطئًا للأمان.

بالطبع أنا أتحدث فقط عن النسخ الاحتياطية المحلية الشخصية هنا. بالنسبة إلى الخوادم ، أوصي باستخدام كلمات مرور قوية يتم نسخها إلى وحدة تخزين منفصلة في وضع عدم الاتصال.

أعتقد أن هناك مشكلة أخرى هنا ؛ إذا كانت بعض الأطر / واجهات برمجة التطبيقات تسمح بكلمات مرور فارغة والبعض الآخر لا. ويجب على المرء أن يفك تشفير المدخلات التي تم تشفيرها بواسطة واجهة برمجة تطبيقات أخرى بكلمة مرور فارغة. هذه هي مشكلتي حاليًا مع https://github.com/RNCryptor/JNCryptor

لذا ، من فضلكم ، دعونا نجعل هذه المناقشة مثمرة ، حتى لو كنتم غير موافقين. :)

بعد قراءة هذا الموضوع ، أجد المحادثة مثمرة ، لأن النتيجة كانت إيجابية.

أود أن أذكر الجميع بأن هذا هو Github - إذا كنت تشعر بقوة تجاه شيء ما ولم يتقبل مشرف المشروع ، فلا تتردد في عمل شوكة - يستغرق الأمر ثوانٍ حرفيًا. إذا كنت تفتقر إلى المهارة لإجراء التغيير بنفسك ، فطلب من الآخرين مساعدتك. ستجد أن المشرفين يمكن أن يكونوا أكثر انفتاحًا لقبول التصحيح الذي ينفذ شيئًا لم يكن لديهم الدافع لتطبيقه بأنفسهم.

أنا شخصياً ، في هذه الحالة ، أعتقد أن فرض تصور مسبق لما "يجب" أن يكون الأمن على الجميع ، هو خطأ. القاعدة الأولى لأمن البيانات هي أن البيانات يجب أن تكون في متناول أولئك الذين يحق لهم الحصول عليها. يجب النظر في أي قاعدة من شأنها المساومة على القاعدة رقم 1 بعناية.

الأمن هو موضوع مليء بالخوف والسياسات التي يقودها الخوف ، مما يؤدي إلى عمليات تنفيذ ساذجة ومتسرعة ومنافقة في كثير من الأحيان ، لأن القليل منا يحب في الواقع التفكير في كل الأشياء التي يمكن أن تسوء. لا نرغب حتى في مواجهة انتقادات الآخرين عندما يُنظر إلينا على أننا نسمح للأمور بأن تسير على نحو خاطئ.

بعض الأخطاء الشائعة التي نراها كل يوم:

1) الإصرار على أن البيانات المكتوبة على وسائط مشفرة في حالة سكون ، يجب أن تكون مشفرة بحد ذاتها ، حتى في بيئة موثوقة. أين ينتهي الخوف من الاعتراض؟ من أين نبدأ في الثقة في أن المستخدم يمكن أن يكون مؤهلاً ، وأن إضافة طبقات زائدة عن الحاجة تزيد فقط من خطر فقدان البيانات؟

2) الإصرار على كلمة مرور بتنسيق معين ، أي 8 أحرف بها حرف كبير واحد على الأقل ورقم واحد وواحد غير أبجدي رقمي - كانت هذه ممارسة شائعة لمدة 20 عامًا وقد تم كشف زيفها الآن لأن الألم يتجاوز المكسب. بدلاً من ذلك ، يجب علينا الإصرار على كلمات مرور لا تُنسى وعالية الإنتروبيا مثل xkcdpassword ، أو الاندماج مع مدير كلمات المرور (مما يجعل جميع المستهلكين الرئيسيين يعتمدون بشكل فعال على كلمة مرور رئيسية SPOF للأمان المشترك والتي يمكن أن تكون متقنة - فقط اسأل COMMODO) أو دمج 2FA (من المحتمل أن يكون أفضل اعتمادًا على الأمان المادي للعامل الثاني ، بما في ذلك تكرار مفتاح N + 1).

3) باستخدام كلمة مرور رئيسية - الفشل في تخزينها مؤقتًا في جلسة ما بحيث يضطر المستخدم إلى إدخالها عدة مرات على مدار اليوم بحيث يصبح الإجراء الذي يقوم به دخوله بمثابة ناقل هجوم واضح.

4) باستخدام كلمة مرور رئيسية - الفشل في التحقق من السياسات والاستعلام بشكل أعمى عن كلمة المرور الرئيسية بحيث يصبح المستخدم معتادًا على تقديمها عندما لا تكون مطلوبة بالفعل ، مما يؤدي إلى توقفهم عن التحليل النقدي لما إذا كان يجب عليهم توفيرها أم لا هذا المثال.

5) فرض سياسة ذات امتياز أقل لدرجة أن المستخدمين يستاءون منها ويتجنبوا الاشتراك ، أو يجدون طرقًا للتغلب عليها ، تاركين الباب مفتوحًا لفترة أطول بكثير مما لو كان هناك مخطط أكثر تساهلاً.

6) فرض سياسة الامتياز الأقل دون التكرار N + 1 ، ويعرف أيضًا باسم عدم وجود اعتبارات "استمرارية العمل / سياسة الرجل الرئيسي". على سبيل المثال ، بدلاً من قفل مورد مشترك خلف مفتاحين خاصين بحيث لا يمكن الوصول إليه إلا عندما يتفق كلاهما (النصاب 2) ، قم بقفله خلف أي مفتاحين من ثلاثة مفاتيح خاصة. لا أحد يعيش إلى الأبد.

في أي وقت نقوم فيه كمبرمجين بتنفيذ مخطط تشفير مفتاح واحد ، نحتاج إلى النظر في أهمية إمكانية الوصول ، والاستماع إلى مخاوف أولئك الذين يدركون بشكل مؤلم عواقب فقدان المفتاح لنظام تشفير مفتاح واحد.

دعونا أيضًا نحاول أن نتذكر بلطف أن أخذ الأشياء بعيدًا عن المستخدمين لمجرد الخوف من سوء الاستخدام ، هو خطأ جوهري - مثل جميع القرارات تقريبًا التي يتم اتخاذها بدافع الخوف. معاقبة الجميع لأن شخصًا ما قد يفعل شيئًا خاطئًا ، يقلل من المجتمع ككل.

إذا شعرت في هذه اللحظة أنك لا توافق على هذا المفهوم ، فخذ نفسًا عميقًا ، وعد إلى عشرة ، ثم ضع في اعتبارك هذا: ما الذي يجب أن نفعله كمجتمع عندما ينتحر شخص ما عن طريق وضع رأسه في كيس قمامة به علبة من رش كريمة الخفق واستنشاق علبة أكسيد النيتروز بالكامل؟ هل يجب أن نأخذ بخاخ كريم الخفق بعيدًا عن الجميع؟ اكياس بلاستيك؟ عمليه التنفس؟ يمكن إساءة استخدام كل هذه الأشياء بطريقة تؤدي إلى وفاة المستخدم.

بدلًا من الاندفاع غير العادي لإبعاد الأشياء ، كما نفعل مع طفل يلعب بالمباريات ، يجب علينا بدلاً من ذلك أن نخطئ في جانب تثقيف الناس لاستخدام هذه الأشياء بشكل صحيح. أو قم برفع مستوى الدخول بحيث لا يجده سوى أولئك الذين RTFM.

هذا ما حدث في النهاية هنا ، وقرار قبول هذه النتيجة لم يأتِ حتى يتم التعبير عن جميع القضايا والآراء بالفعل. أوصي بمشاهدة جلسات النقاش البرلماني على محطات التلفزيون العامة للحصول على أمثلة لما يبدو عليه النقاش غير المثمر ، لول. كان المشاركون هنا محترمين بشكل استثنائي تجاه بعضهم البعض بالمقارنة.

تذكر أدوات الأرشفة القديمة الجيدة حيث كان التشفير وحماية كلمة المرور متاحين كخيارات واضحة فقط ولكن ليس بشكل افتراضي. وهذا هو المنطق الصحيح لأن الأمان قد يحتوي على الكثير من الحلول الخارجية خارج نطاق الأداة المساعدة هذا ولأن هذه الرعاية متروكة للمستخدم. ما تفعله هو مجرد توفير أدوات الأمان التي يختارها المستخدمون. لكن المؤلف يفضل الاهتمام بما لا يطلبه المستخدم لمنع سوء الاستخدام.

ومرة أخرى عن النغمة. هذا أمر معتاد في عالم مفتوح المصدر. وهي مدعومة ببعض الآليات النفسية. يتم التعامل مع الانتقادات التي لا يوافق عليها المؤلفون على أنها مطالبة بقضاء أوقات فراغهم. وفي كل مرة علينا أن نذكر: لا نناقش هنا وقت فراغك ، بل نستكشف مخلوقك العبقري ووظائفه والمنطق الكامن وراءه. لا ننسى أبدًا أنه ليس لديك التزامات لتلبية مطالبنا ولك الحق الكامل في عدم القيام بأي شيء على الإطلاق. ولكن إذا كنت تحب ما تفعله ، فقد يكون (ربما) لأن الآخرين يحبونه. لذلك قد يكون هناك بعض الأمل في أنك مهتم بتلبية الطلب على الأقل من الأغلبية.

ملاحظة: كل هذه مجرد صرخات مجردة وليس المقصود بها أي إجراءات ممارسة.

هناك شيء واحد لم أفهمه مطلقًا أثناء المناقشة حول عدم السماح بكلمة مرور للمستودع (بافتراض أن السياق @ fd0 كتب سابقًا ، أن البيانات ستظل مشفرة) ؛ لماذا لا يستخدم هؤلاء الذين "لا يريدون" كلمة مرور كلمة مرور وهمية مثل "1234" أو أيًا كان؟ ما الهدف من كتابة الكود في restic الذي يزيل كلمة المرور ، إذا كنت لا تهتم بالحصول على كلمة مرور ، يمكنك فقط استخدام كلمة مرور وهمية؟ إنه متغير بيئة واحد أو ملف كلمة مرور بعيدًا ، إذا كنت تعتقد أنه من الصعب كتابته في سطر الأوامر عند تشغيل restic.

rawtaz تمت الإجابة على هذا في التعليقات السابقة على هذا الموضوع.

فقط دعني أقول أن restic init -r foo --no-password ربما يكون اسم علم أفضل من restic init -r foo --allow-empty-password ، ببساطة لأن الأول هو أكثر دقة والأخير مطول للغاية.

أخفق في رؤية أي حجج جيدة لماذا لا يعد استخدام كلمة مرور وهمية طريقة قابلة للتطبيق تمامًا للقيام بذلك بدلاً من زيادة قاعدة الكود الثابت في هذا الموضوع. لقد رأيت أحدهم يقول إنه قد ينسى كلمة المرور "أ". في حين أن هذا قد يكون صحيحًا ، فمن الممكن بالتأكيد اختراع كلمة مرور وهمية بسيطة وتذكر ذلك ، أو على الأقل اكتشافها من جديد عند الحاجة. ولكن مهما كان الأمر ، فإن العلم يعمل بشكل جيد أيضًا ، أنا مندهش من حجم المشكلة التي يبدو أنها: د

حسنًا ، هذا مثال. عمل نسخة احتياطية restic قبل عام. مكتوبة أ
كلمة مرور وهمية ، قراءة من ملف. لم أكتب كلمة المرور
أي مكان آخر. بعد عام من عدم استخدام هذا الجهاز ، أصبحت تمامًا
نسيت كل من العملية وكلمة المرور - وأهدرت ساعة في محاولة ذلك
خمن كلمة المرور قبل العثور عليها في النهاية (والهندسة العكسية)
النص. خطأي بالكامل ، لكني لا أحتاج إلى الأمان ،
ولا تريد أن تضطر إلى تذكر كلمة مرور وهمية. و اذا انا
لم يكن بإمكاني الوصول إلى الملفات الأصلية ، لكنت قد أغلقت.

TD

أليس هذا بسبب المبالغة في تعقيدها؟ واحدة من أكثر كلمات المرور شيوعًا هي 1234. استخدم ذلك ولن تضطر إلى محاولة العثور عليه في مكان ما (بافتراض أنك لا تعتقد أنك استخدمت كلمة مرور أكثر تعقيدًا) لأنه عندما تحتاج إلى إدخال كلمة مرور وهمية ، فأنت تعلم أنها 1234. لكن بالتأكيد ، أرى ما تقصده.

أود أيضًا أن أرى خيارًا للسماح بكلمة مرور فارغة (من خلال استخدام علامة --allow-empty-password ، أو ربما شيء أكثر تفصيلاً / فريدًا لتسليط الضوء على المخاطر ، مثل NRPE's --dont-blame-nrpe flag).

حالات الاستخدام الخاصة بي:

* **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. ربما يمكن إنشاء مفتاح psuedo-random (بدلاً من عدم وجود مفتاح) وتخزينه هناك؟ هذا لا يساعد المستخدمين الذين يحاولون تجنب عبء التشفير لأسباب تتعلق بالأداء.

• الأعمال: لدينا مستودع موجود في بيئة موثوق بها نحتاج إلى "أي شخص" لاستعادته في حالة الطوارئ / الكوارث دون الحاجة إلى معرفة خاصة (أي كلمة مرور المستودع).

لكن هؤلاء "أي شخص" يحتاجون بالفعل إلى معرفة / تعليمات خاصة. إنهم بحاجة إلى معرفة إما كيفية تشغيل restic لاستعادة البيانات ، بما في ذلك المستودع الذي يجب استخدامه وأشياء أخرى ، وسيكون من السهل جدًا تضمين كلمة مرور وهمية في هذه التعليمات. أو يستخدمون برنامجًا نصيًا أو أتمتة مشابهة تقوم بالاستعادة لهم (وفي هذه الحالة لا يزالون بحاجة إلى معرفة / الحصول على إرشادات حول المكان الذي يتجهون إليه لاستخدام هذه الأداة) ، وفي هذه الحالة سيتم التعامل مع كلمة المرور الوهمية بواسطة البرنامج النصي . بغض النظر عن الطريقة التي تنظر بها إلى هذا ، فإن كلمة المرور الوهمية ليست مشكلة. وعلى محمل الجد ، إذا نسيها الجميع فجأة ، فسيكون بمقدور الناس تخمين 1234 أو إجبارهم على القوة الغاشمة. إنها ليست مشكلة: P

• الصفحة الرئيسية: أرغب في إنشاء نسخة احتياطية ثابتة لأشياء مثل صور العائلة. هذه ليست سرية بشكل خاص ، وفي حالة وفاتي المبكرة ، يجب أن تكون عائلتي قادرة على الوصول إلى هذه البيانات المهمة شخصيًا بأقل قدر من المقاومة (_ على سبيل المثال ، دون الحاجة إلى العثور على عبارة مرور في خزنة ، ربما يكون ذلك خارج- التاريخ أو مختلطة مع آخر_).

انتظر ماذا؟ لماذا تريد ألا يكون لديك كلمة مرور ، وعندما لا يكون ذلك ممكنًا (حاليًا على الأقل) ، استخدم كلمة مرور وهمية فائقة البساطة (على سبيل المثال 1234) ، ثم ضع كلمة المرور الوهمية فائقة البساطة في خزنة ؟ سيكون ذلك بلا فائدة على الإطلاق. ضعه في مكان آخر ، ولأجل ما يستحق ، من المحتمل أن يكون لديك بالفعل مجموعة كاملة من المعلومات الأخرى التي تحتاج عائلتك إلى معرفتها في حالة وفاتك ، لذا ضع كلمة المرور الوهمية جنبًا إلى جنب مع ذلك.

أخيرًا ، يجب أن تكون كلمة المرور الوهمية بسيطة جدًا وواضحة بحيث لا تنتهي صلاحيتها ، ولا داعي لأكثر من كلمة مرور وهمية. لذلك لا ينبغي أن تكون قديمة أو مختلطة مع أخرى.

نعم ، لقد تم تقديم هذه الاقتراحات بالفعل ، لذلك نحن الآن في دوائر. شخصيًا ، فهي ليست حلولًا مناسبة أشعر بالراحة معها لبيئتي وحالات الاستخدام.

ليس لديك حاجة لهذه الميزة ، فلا بأس. هذا لا يعني أن حالات استخدام أي شخص آخر غير صالحة. ليس لدي استخدام للواجهة الخلفية لـ Amazon S3 ، لكنني لا أصرح بأنها غير ضرورية ، فأنا لا أستخدمها. إذا تم تنفيذ هذه الميزة ، فلن يكلفك عدم استخدامها شيئًا.

نعم ، لقد تم تقديم هذه الاقتراحات بالفعل ، لذلك نحن الآن في دوائر.

نعم ، وبصراحة ، ما زلت لم أرَ تفسيرًا فعليًا لسبب صعوبة التعامل مع كلمة المرور الوهمية ، أشعر أنني رأيت في الغالب تعقيدات مفرطة.

شخصيًا ، فهي ليست حلولًا مناسبة أشعر بالراحة معها لبيئتي وحالات الاستخدام.

هذا شيء أحترمه تمامًا. حالة استخدام الجميع فردية ولديك سير عملك :)

أعتقد أننا سنحصل في وقت ما على --no-password أو ما شابه ، ونأمل أن يحل هذا حالة الاستخدام هذه أيضًا. شكرا لمساهمتك!

كتب روتاز

فقط دعني أقول أن restic init -r foo --no-password ربما يكون اسم علم أفضل من restic init -r foo --allow-empty-password ، ببساطة لأن الأول هو أكثر دقة والأخير مطول للغاية.

أخفق في رؤية أي حجج جيدة لماذا لا يعد استخدام كلمة مرور وهمية طريقة قابلة للتطبيق تمامًا للقيام بذلك بدلاً من زيادة قاعدة الكود الثابت في هذا الموضوع. لقد رأيت أحدهم يقول إنه قد ينسى كلمة المرور "أ". في حين أن هذا قد يكون صحيحًا ، فمن الممكن بالتأكيد اختراع كلمة مرور وهمية بسيطة وتذكر ذلك ، أو على الأقل اكتشافها من جديد عند الحاجة. ولكن مهما كان الأمر ، فإن العلم يعمل بشكل جيد أيضًا ، أنا مندهش من حجم المشكلة التي يبدو أنها: د

لست قلقًا بشأن استخدام / معالجة كلمة المرور الوهمية - بدلاً من ذلك أشعر بالقلق أحيانًا بشأن إبطاء استخدام وحدة المعالجة المركزية من عملية النسخ الاحتياطي عن طريق التشفير الإلزامي عند تشغيله على أجهزة منخفضة النهاية.

حل # 1018 (النسخ الاحتياطية غير المشفرة) من شأنه أيضًا حل هذه المشكلة - مثل التبديل --unencrypted بدلاً من التبديل --no-password .

لقد استخدمت بالفعل restic على الأجهزة المنخفضة حيث لا تحتوي وحدة المعالجة المركزية بالتأكيد على AES-NI (أو امتداد مشابه) وحيث كانت النسخة الاحتياطية مرتبطة بوحدة المعالجة المركزية. في حالة أخرى ، كانت وحدة المعالجة المركزية أقوى قليلاً ولكن محرك الأقراص الصلبة الخارجي الوحيد المتاح كان مشفرًا بالفعل LUKS وبالتالي كان مرتبطًا بوحدة المعالجة المركزية لأنه لم يكن قويًا بما يكفي للتعامل مع عمليتي تشفير على التوازي.

أنظر أيضا: https://github.com/restic/restic/issues/1018#issuecomment -307549863

إذا نسيت كيفية استخدام restic ، يمكنك قراءة المستندات. إذا نسيت موقع المستودع يمكنك العثور عليه. أو يمكنك أن تصادف بشكل غير رسمي مستودعًا يتيمًا وتتساءل عما يوجد في الداخل. ولكن إذا نسيت كلمة المرور ، فستفقد بياناتك إلى الأبد. وفي الحياة الواقعية ، يمكنك أن تنسى أي أبسط كلمة مرور وهمية. يمكنك أن تنسى كل شيء لا تستخدمه كثيرًا.

إذا فقدت كلمة مرور الجذر ، يمكنك التمهيد باستخدام خيار init = / bin / bash والحصول على وصول كامل. على الرغم من إمكانية إغلاق هذه الفتحة ، إلا أنها لا تزال موجودة في معظم الأنظمة. لماذا ا؟ لأن الخسارة من عدم التوفر ستكون أكثر من انعدام الأمن في تلك الحالات. وبالتالي فهي مقايضة بين الأمن والتوافر. بالنسبة للأنظمة ذات المتطلبات العالية ، توجد حلول خاصة ، مثل المفاتيح الزائدة عن الحاجة ، بشرط الأمان والتوافر.

resitc ليس أداة أمنية. إنها أداة نسخ احتياطي. وعلى هذا النحو ، يجب أن توفر وظيفة النسخ الاحتياطي نفسها أولاً وقبل كل شيء ، وبعد ذلك فقط الأمان. لذلك يمكن توفير الحماية بكلمة المرور والتشفير كخيارات فقط ويجب ألا يكونا في مكانهما افتراضيًا.

راجع للشغل: الإعدادات الافتراضية هي علامة جودة البرنامج.

vstavrinov يرجى قراءة مقدمة restic قبل القول بأنها ليست أداة أمنية. إنها أداة نسخ احتياطي تتمثل إحدى ميزاتها الأساسية في أنها تحاول تأمين نسخك الاحتياطية. لذا ، فأنت بعيد جدًا عندما تقول إنه لا يهتم بالأمن.

ولكن إذا نسيت كلمة المرور ، فستفقد بياناتك إلى الأبد.

نعم ، ولهذا السبب (في هذه الحالة لديك الخيار البسيط) تستخدم كلمة مرور وهمية حتى تتمكن دائمًا من إدراك كلمة المرور حتى لو نسيتها.

وفي الحياة الواقعية ، يمكنك أن تنسى أي أبسط كلمة مرور وهمية.

إذا قمت بذلك ، فقد اخترت كلمة مرور وهمية معقدة للغاية ، ولم تعد كلمة مرور وهمية بسيطة بعد الآن.

هذا النقاش برمته أصبح سخيفًا بشكل مضحك ، بصراحة. لا أصدق أن الناس يقولون إن كلمة مرور مثل 1234 ، وهي واحدة من أكثرها شيوعًا ووضوحًا ، هي شيء قد ينسونه ثم لا يتمكنون من اكتشافه بسرعة حقيقية (على سبيل المثال ، بمجرد تجربة عدد قليل من الدمية الواضحة كلمات المرور). أود أن أقول إن عليك أن تحاول جاهدًا ألا تكون قادرًا على "تخمين" 1234 عندما تكون في هذا الموقف ، وحتى في هذه الحالة ستفشل على الأرجح في عدم تخمينها.

ولكن إذا نسيت كلمة المرور ، فستفقد بياناتك إلى الأبد.

قد تساعدك ويكيبيديا: فقط جرب كلمات المرور الأكثر شيوعًا من https://en.wikipedia.org/wiki/List_of_the_most_common_passwords#List.

أحد المواقف التي قد يحدث فيها هذا هو عندما لا يتم تصدير متغير البيئة RESTIC_PASSWORD أو تعيينه إلى سلسلة فارغة بطريق الخطأ.

من الممكن أن يتحقق الكود مما إذا تم تعيين كلمة مرور على سلسلة فارغة بشكل صريح أو لم يتم تعيينها فقط (لم يتم تحديد خيار سطر الأوامر ، لم يتم تعيين متغير البيئة -> يختلف عن سلسلة فارغة).

أعتقد أنه يجب إعطاء الخيار للمستخدم الذي يريد اختيار كلمة المرور.

حل # 1018 (النسخ الاحتياطية غير المشفرة) من شأنه أيضًا حل هذه المشكلة - أي باستخدام مفتاح - غير مشفر بدلاً من مفتاح - no-password.

يجب أن يظل التشفير إلزاميًا للحماية من البحث الثنائي على مزود الاستضافة بشكل مستقل عن التنسيق ، والنقل عبر قناة غير مشفرة باستخدام MITM وما إلى ذلك. في حين أن هذا يمنحك نفس القدر من الحماية التي توفرها كلمة المرور الفارغة للهجمات المستهدفة (صفر) ، إلا أنه لا يزال يتجنب الأضرار الجانبية على الهجمات غير المستهدفة.

rawtaz

إنها أداة نسخ احتياطي تتمثل إحدى ميزاتها الأساسية في أنها تحاول تأمين نسخك الاحتياطية. لذا ، فأنت بعيد جدًا عندما تقول إنه لا يهتم بالأمن.

ليس بعيدا. أشر لي حيث أقول "ليس هناك قلق بشأن الأمن". انا لا. أنت تقول الشيء نفسه: "إنها أداة نسخ احتياطي". النسخ الاحتياطي ليس أمنا ، أليس كذلك ؟. لذا فإن restic ليس أداة أمنية. و "... إحدى الميزات الأساسية ...". أنت على حق مرة أخرى: إنها ميزة. أي أن الأمن هو ميزة ، في حين أن النسخ الاحتياطي هو تعيين وظيفي (هدف).

rawtaz

هذا النقاش برمته أصبح سخيفًا بشكل مضحك ، بصراحة. لا أصدق أن الناس يقولون أن كلمة مرور مثل 1234 ...

لا يمكنني فعل أي شيء ، لكنك محق في هذه الحالة أيضًا. ما هو سخيف هو مناقشة كلمة المرور الوهمية. لكني أعتقد أن الأهم هو فهم أن حماية كلمة المرور والتشفير يجب أن يكونا اختياريين. وكذلك لا تفرض على المستخدمين ميزات إضافية غير مرغوب فيها ، مما يترك لهم خيار استخدامها أو عدم استخدامها. وهذه هي علامة جودة البرامج أيضًا.

لكني أعتقد أن الأهم هو فهم أن حماية كلمة المرور والتشفير يجب أن يكونا اختياريين.

لماذا ا؟ لماذا "يجب" ألا تحتوي أداة النسخ الاحتياطي على تشفير افتراضي؟ فقط لأنها أداة "نسخ احتياطي"؟ أنت تقول هذا فقط ولكن لا يوجد سبب لأي من هذا.

لا يوجد قرار تصميم يمكن أن يرضي الجميع. اختيار عشوائي للتركيز بشدة على الأمان ، والمستخدمون مثلي يحبون أن التشفير القوي هو الخيار الافتراضي.

• إذا كنت لا تهتم بالأمان ، فلا يمكنك إساءة استخدام نظام آمن افتراضيًا. في أسوأ الأحوال ، ترى بعض الأخطاء وحاول مرة أخرى باستخدام الأمر المعدل.
• إذا كنت تهتم بالأمان ، فهناك العديد من الطرق لإساءة استخدام نظام غير آمن افتراضيًا لإحداث تأثير كارثي. علامة واحدة مفقودة ، ويتم تسريب بياناتك الحساسة ، ربما _ بشكل غير قابل للعكس_.

يعد طلب العلم الذي يمكنه حذف كلمة المرور أمرًا واحدًا ، ولكن الدفاع عن عدم وجود تشفير افتراضيًا يعد بمثابة "تفكيك" خطير لجميع المستخدمين الحاليين الذين يعتمدون على تشفير restic. إن احتمالية حدوث أخطاء فادحة للمستخدم هائلة.

تضمين التغريدة

لكني أعتقد أن الأهم هو فهم أن حماية كلمة المرور والتشفير يجب أن يكونا اختياريين.

لماذا ا؟ لماذا "يجب" ألا تحتوي أداة النسخ الاحتياطي على تشفير افتراضي؟ فقط لأنها أداة "نسخ احتياطي"؟ أنت تقول هذا فقط ولكن لا يوجد سبب لأي من هذا.

"اختياري" ليس هو نفسه "افتراضي". الافتراضات على هذا النحو قد تكون قابلة للجدل. لكن أن يكون لديك خيارات أكثر أهمية. في حين أنه ليس لدينا خيار ، لا توجد علاقة مع التخلف عن السداد. هذا هو بيت القصيد. قم أولاً بتقديم خيارات ثم من المنطقي مناقشة الافتراضات.

في هذه الحالة (المشكلة) ، الأمر بسيط جدًا - من المحتمل أن يكون هناك علامة --no-password أو علامة مشابهة لـ restic init (مع استمرار أن restic تطلب كلمة مرور عند التهيئة) ، ولكن هذا مجرد رأيي في الرد الأخير على @ fd0 . وليس هناك وقت محدد للوصول في هذه المرحلة ، فلا داعي للسؤال عن ذلك :)

في هذه الأثناء ، استخدم كلمة مرور وهمية :) أعتقد أن التنفيذ المناسب يتضمن القدرة على إزالة / إلغاء تعيين كلمة مرور / مفتاح تم استخدامه مسبقًا لبدء الريبو ، لذلك لا يتعين على المرء إعادة إنشاء المستودع بالكامل.

التشفير شيء آخر ، ومع ذلك ، يتم تعقبه في هذه المشكلة الأخرى.

لا أهتم كثيرًا بخيار عدم وجود كلمة مرور ، لكنك كنت تجادل بشأن عدم وجود تشفير افتراضي:

لذلك يمكن توفير الحماية بكلمة المرور والتشفير كخيارات فقط ويجب ألا يكونا في مكانهما افتراضيًا.

راجع للشغل: الإعدادات الافتراضية هي علامة جودة البرنامج.

التي أجدها خطيرة.

على الرغم من أنني أتفق بشكل عام مع نقاط rawtaz ، إذا كانت المناقشة

تضمين التغريدة

لا أهتم كثيرًا بخيار عدم وجود كلمة مرور ، لكنك كنت تجادل بشأن عدم وجود تشفير افتراضي:

لذلك يمكن توفير الحماية بكلمة المرور والتشفير كخيارات فقط ويجب ألا يكونا في مكانهما افتراضيًا.

يمكنك أن ترى حتى في هذا الاستشهاد "الخيارات" أولاً و "الافتراضي" هو التالي. وهذه هي النقطة مرة أخرى.

في هذه الحالة (المشكلة) ، الأمر بسيط جدًا - من المحتمل أن يكون هناك علامة --no-password أو علامة مشابهة لـ restic init (مع استمرار أن restic تطلب كلمة مرور عند التهيئة) ، ولكن هذا مجرد رأيي في الرد الأخير على @ fd0 . وليس هناك وقت محدد للوصول في هذه المرحلة ، فلا داعي للسؤال عن ذلك :)

في هذه الأثناء ، استخدم كلمة مرور وهمية :) أعتقد أن التنفيذ المناسب يتضمن القدرة على إزالة / إلغاء تعيين كلمة مرور / مفتاح تم استخدامه مسبقًا لبدء الريبو ، لذلك لا يتعين على المرء إعادة إنشاء المستودع بالكامل.

ربما يكون الحل الأبسط هو أن تدعم restic كلمة مرور وهمية ستحاول فتح مستودع موجود إذا لم يحدد المستخدم كلمة مرور.

فيما يتعلق بالتعامل مع كلمات المرور الوهمية: لا توجد كلمة مرور وهمية أفضل مناسبة للجميع. 1234 هي كلمة مرور وهمية مزعجة لأنها تتطلب أربعة أصابع للتحرك لأعلى والكتابة. "asdf" أسرع في الكتابة على سبيل المثال. تقوم بعض الخدمات أيضًا بتقييد اختيارات كلمة المرور ، لذلك قد لا تكون الأرقام أو أربعة أرقام فقط ممكنة. لذلك فإن الحل داخل restic سيكون أكثر سهولة في الاستخدام. وبعد ذلك سيتعين على المستخدمين كتابة كلمة المرور الوهمية مرة واحدة فقط.

من منظور الأمان حسب التصميم ، يعد توفير أي نوع من كلمات المرور الوهمية فكرة سيئة.

IFF شخص ما يريد حقًا التحايل على التشفير أو لا يحتاج إليه ، ما عليك سوى توفير كلمة مرور متسقة. لست مضطرًا إلى كتابته ، يمكنك كتابة برنامج نصي لتغليف الكود الثابت والرابط لمحتوى قلبك هناك. حقًا ، هل هذا عمل أكثر من توفير عنوان المستودع أو خيارات التكوين الأخرى؟

إن محاولة استخدام مجموعة من كلمات المرور المزيفة أو الوهمية المشفرة بشكل ثابت هو مجرد سؤال عن المتاعب. ماذا لو حدث شخص فقير لاختيار إحدى كلمات المرور "السحرية" المقترحة؟ هل نحذرهم من اختيار كلمات مرور التشفير الوهمية الخاصة بنا؟ "لا تيد ، لا يمكنك اختيار SPACECHICKEN ككلمة مرور المستودع ، إنها _ خاصة_." ؛)

أنا بخير مع توفير خيار للمستخدمين لإطلاق النار على أنفسهم باستخدام ("- no-repository-password") ولكن لا أعتقد أن restic يجب أن يذهب إلى أبعد من ذلك لإرضاء شريحة صغيرة جدًا من المستخدمين الذين الرغبة في خفض الأمن.

من منظور الأمان حسب التصميم ، يعد توفير أي نوع من كلمات المرور الوهمية فكرة سيئة.

لماذا هو أسوأ من عدم السماح بكلمة مرور؟

IFF شخص ما يريد حقًا التحايل على التشفير أو لا يحتاج إليه ، ما عليك سوى توفير كلمة مرور متسقة. لست مضطرًا إلى كتابته ، يمكنك كتابة برنامج نصي لتغليف الكود الثابت والرابط لمحتوى قلبك هناك. حقًا ، هل هذا عمل أكثر من توفير عنوان المستودع أو خيارات التكوين الأخرى؟

نعم ، إنه عمل أكثر. سيكون Restic هو حل النسخ الاحتياطي ويكون ناتجه هو المستودع. لذلك ، من الناحية المثالية ، سيحتوي المستودع على كل شيء لاستعادة النسخة الاحتياطية. ولكن عند استخدام برنامج نصي مُغلَّف يتضمن تشفيرًا ثابتًا ، فإن كلمة المرور الوهمية تعني أن هذا البرنامج النصي يحتاج إلى النسخ الاحتياطي بواسطة شيء آخر ، وإلا فسيكون المستودع عديم الفائدة.

إن محاولة استخدام مجموعة من كلمات المرور المزيفة أو الوهمية المشفرة بشكل ثابت هو مجرد سؤال عن المتاعب. ماذا لو حدث شخص فقير لاختيار إحدى كلمات المرور "السحرية" المقترحة؟ هل نحذرهم من اختيار كلمات مرور التشفير الوهمية الخاصة بنا؟ "لا تيد ، لا يمكنك اختيار SPACECHICKEN ككلمة مرور المستودع ، إنها _ خاصة_." ؛)

ما هي المشكلة بالضبط؟ لا يزال بإمكان تيد اختيار كلمة المرور هذه. هذا يعني فقط أن restic سيستخدمه بشكل ملائم إذا لم يحدده. سيظل Restic يقوم بتشفير / فك تشفير المستودع بنفس الطريقة كما لو لم يكن كلمة مرور خاصة.

أنا بخير مع توفير خيار للمستخدمين لإطلاق النار على أنفسهم باستخدام ("- no-repository-password") ولكن لا أعتقد أن restic يجب أن يذهب إلى أبعد من ذلك لإرضاء شريحة صغيرة جدًا من المستخدمين الذين الرغبة في خفض الأمن.

إن تسمية هذا "أطلقوا النار على القدمين" هو حكم قضائي بلا داع ولا يعني أيضًا تقليل الأمان. يجب أن يكون التوفر والمرونة ضد برامج الفدية جزءًا من مفهوم الأمان. قد تؤدي القدرة المفقودة على استعادة نسخة احتياطية بسبب فقدان الوصول إلى كلمة مرور التشفير إلى تقليل الأمان. لن يؤدي تخزين النسخة الاحتياطية بشكل آمن في نظام تخزين ملحق فقط إلى تقليل مستوى الأمان هنا.

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.

اخترت مثالًا ترفيهيًا ، ربما لا ينبغي لي ذلك. لنفترض أن كلمة مرورك الوهمية التي تريد restic أن تجربها سراً وأن تجربها تلقائيًا في حالة فشل فك التشفير هي: "12345". يمكن للمستخدم الساذج أن يختار ذلك ككلمة المرور الخاصة به. الآن لديهم مستودع يعتقدون أنه مشفر (ونوع ما هو) ولكن يمكن فك تشفير _anyones_ restic. تنطبق هذه الوسيطة على أي مجموعة من كلمات المرور التي تختارها في مجموعتك المشفرة. هذا تصميم أمان سيئ بشكل أساسي.

هناك مصطلح لما تقترحه. يطلق عليه باب خلفي للتشفير :) إخفاء هذا الباب الخلفي في المستندات يفترض أن جميع القراء سيقرأون الدليل بالكامل قبل استخدام restic. ألن يخدم المزيد من احتياجات الناس لجعلهم يقرؤون الوثائق لتحديد كيفية التقليل من الأمان إذا كانوا يرغبون في ذلك بشكل غريب؟

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

بهذه الطريقة ، هناك طريقة معروفة لتحقيق النسخ الاحتياطي / الاستعادة مع restic دون الحاجة إلى إدارة أي مفاتيح.

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.

اخترت مثالًا ترفيهيًا ، ربما لا ينبغي لي ذلك. لنفترض أن كلمة مرورك الوهمية التي تريد restic أن تجربها سراً وأن تجربها تلقائيًا في حالة فشل فك التشفير هي: "12345". يمكن للمستخدم الساذج أن يختار ذلك ككلمة المرور الخاصة به. الآن لديهم مستودع يعتقدون أنه مشفر (ونوع ما هو) ولكن يمكن فك تشفير _anyones_ restic. تنطبق هذه الوسيطة على أي مجموعة من كلمات المرور التي تختارها في مجموعتك المشفرة. هذا تصميم أمان سيئ بشكل أساسي.

لم أقترح تجربته عند فشل فك التشفير ولكن عند عدم تحديد كلمة مرور لفك التشفير. إذا اختار شخص ما كلمة مرور غير آمنة ، فهي غير آمنة بغض النظر عما إذا تمت تجربتها عن طريق restic مباشرة أو من قبل شخص ما بكلمات مرور قسرية. "12345" هي كلمة مرور غير آمنة في الوقت الحاضر أيضًا ، ولن تتغير إذا أصبحت كلمة المرور الافتراضية لـ restic.

هناك مصطلح لما تقترحه. يطلق عليه باب خلفي للتشفير :) إخفاء هذا الباب الخلفي في المستندات يفترض أن جميع القراء سيقرأون الدليل بالكامل قبل استخدام restic. ألن يخدم المزيد من احتياجات الناس لجعلهم يقرؤون الوثائق لتحديد كيفية التقليل من الأمان إذا كانوا يرغبون في ذلك بشكل غريب؟

سيكون الباب الخلفي للتشفير في حالة استخدام restic لكلمة مرور افتراضية بالإضافة إلى كلمة المرور التي يوفرها المستخدم عند تشفير البيانات. اقتراحي هو محاولة كلمة مرور واحدة في فك التشفير. سيظل المستخدم يختار كلمة المرور السيئة بنشاط.

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 أو حقًا أي معيار مقبول عالميًا للإرشاد في أفضل الممارسات هنا. نحن لسنا في منطقة جديدة.

لا يعني التشفير في حالة الراحة أن restic يحتاج إلى القيام بذلك. لا يزال من الممكن تشفير وحدة التخزين الملحقة فقط بطريقة أخرى إذا لزم الأمر. ومع ذلك ، سيكون هناك بعض التخزين غير المشفر ، حتى لو كان مخصصًا لكلمة المرور فقط. وإلا فإن مفهوم النسخ الاحتياطي سيعتمد على شخص ما يتذكر كلمة المرور دائمًا.

إلغاء الاشتراك من هذا الموضوع ...

دعنا نترك الأمر عند هذا الحد ، فمن الواضح أن بعض الأشخاص يريدون خيارًا --no-password إلى init ، وهذا كل ما تدور حوله هذه المشكلة. التشفير أم لا هو قضية منفصلة.

فقط تعليق سريع هنا:
أنا مستخدم لا يهتم بالتشفير. لا يوجد شيء حساس بخصوص بياناتي. أنا أهتم بشأن قدرة الأشخاص على استخدام الأشخاص الذين ليسوا أنا في 20-40 عامًا. مجرد استخدام rclone هو بديل آخر أكثر فقراً.

يبدو أن Restic أداة جيدة لذلك ، باستثناء فرض التشفير وكلمة المرور مما يعني أنني بحاجة إلى أخذ ذلك في الاعتبار. ربما يكون التمهيدي في مستودع النسخ الاحتياطي. إنه عمل أكثر وأي حل (من جانبي) يهزم أي تشفير على أي حال.

علامة

شكرًا لمساهماتك ، أعتقد أننا جمعنا معلومات كافية.