Restic: Izinkan kata sandi kosong

Restic harus mengizinkan kata sandi kosong.

Bisakah Anda menguraikan apa kasus penggunaan Anda? Mengapa restic mengizinkan kata sandi kosong?

itu adalah keputusan desain.

Memang itu. Tapi saya ingin tahu apa yang ingin Anda capai.

Masalah terkait mungkin #1018

Saya hanya ingin mencadangkan beberapa direktori sementara di sistem lokal saya sebagai jaring pengaman cepat saat mengubah file dalam direktori. Saya tidak ingin mengingat kata sandi atau repot memasukkan kata sandi setiap kali saya ingin membuat cadangan. Karena saya baru saja menggunakan a sebagai kata sandi, tidak ada manfaat keamanan yang nyata dalam menggunakan kata sandi ini dibandingkan dengan tidak menggunakan kata sandi sama sekali. Oleh karena itu, biaya rendah untuk mengingat atau memasukkan kata sandi yang tidak berguna membuat alat ini kurang sempurna.

Terima kasih atas penjelasannya. Saya ingin menyimpan cek ini, jadi saya menutup masalah ini untuk saat ini. Jangan ragu untuk menambahkan komentar lebih lanjut. Terima kasih!

Ketika kami membicarakan hal ini beberapa waktu lalu Anda mengatakan akan ada diskusi ...
Bisakah Anda menjelaskan mengapa Anda menganggap pemeriksaan ini berguna? Repositori masih harus dienkripsi sehingga kata sandi dapat ditambahkan setelahnya.

Saya menganggap pemeriksaan ini berguna karena menurut pengalaman saya, sebagian besar pengguna ingin menetapkan kata sandi. Menerima kata sandi kosong, atau bahkan memiliki jalur kode yang memungkinkan penerimaan kata sandi kosong, dapat menyebabkan pengguna secara tidak sengaja menyimpan cadangan mereka ke lokasi terpencil tanpa enkripsi yang tepat. Satu situasi di mana hal ini dapat terjadi adalah ketika variabel lingkungan RESTIC_PASSWORD tidak diekspor atau disetel ke string kosong secara tidak sengaja.

Jadi, dalam hal ini, menurut saya melindungi pengguna dari kesalahan lebih baik daripada menghilangkan ketidaknyamanan kecil karena harus mengatur kata sandi :)

Ada solusi mudah untuk ini: Gunakan pengelola kata sandi, gunakan string test , ekspor RESTIC_PASSWORD secara statis melalui file misalnya di /etc/profile.d , gunakan nama direktori yang Anda sedang menyimpan (atau repositori) sebagai kata sandi...

Harap dicatat bahwa pengetahuan tentang kata sandi Anda diperlukan untuk mengakses repositori.
Kehilangan kata sandi Anda berarti data Anda hilang secara permanen.

Bagaimana saya bisa mencegah hal ini terjadi jika saya tidak ingin kehilangan data saya selamanya?

@LexSong Gunakan pengelola kata sandi.

Pada Selasa, 03 Juli 2018 pukul 09:56:56 -0700, Chenfeng Bao menulis:

@LexSong Gunakan pengelola kata sandi.

Bagaimana Anda mengusulkan untuk mencadangkan basis data pengelola kata sandi? Apakah kamu
usulkan di sini untuk menggunakan pengelola kata sandi dengan database tanpa
kata sandi? Pengelola kata sandi mana yang mendukung restic untuk mendapatkan
kata sandi dari?

Manajemen kata sandi adalah topik besar yang tidak ingin saya bahas terlalu banyak di utas ini. Hanya menunjukkan bahwa jika dilakukan dengan benar, kata sandi seharusnya tidak memusingkan. Ada banyak sumber daya online.

Basis data pengelola kata sandi harus sudah dienkripsi dengan benar, sehingga Anda dapat meletakkannya di mana pun Anda suka tanpa lapisan enkripsi lain. Ada juga banyak layanan pengelola kata sandi berbasis cloud, jadi Anda tidak perlu khawatir tentang pencadangan sendiri.

Untuk dukungan restic, Anda cukup memasukkan kata sandi dalam file plaintext secara lokal dan menggunakan opsi --password-file . Maka Anda tidak perlu memasukkan kata sandi secara manual. Kata sandi itu sendiri juga harus dimasukkan ke dalam pengelola kata sandi untuk dicatat.

Pada akhirnya, selalu ada satu kata sandi/frasa sandi yang rumit yang harus Anda hafal agar semuanya benar-benar aman.

Sebenarnya, jika Anda benar-benar tidak menginginkan kata sandi pada repositori restic, mengapa tidak menggunakan kata sandi dummy satu karakter saja?

Menggunakan 'a' sebagai kata sandi sebenarnya adalah solusi saya tetapi rasanya tidak tepat karena saya tidak yakin apakah saya ingat menggunakan ini ketika saya melihat repo ini untuk beberapa alasan lagi dalam beberapa tahun jika saya lupa menghapusnya ketika Saya tidak membutuhkannya lagi. Oleh karena itu saya mungkin harus menerapkan semacam pemaksaan kasar untuk mengetahuinya. Ini semua pekerjaan yang bisa dihindari.

Di masa lalu saya sudah menggunakan kata sandi sementara sederhana dalam situasi yang membuat saya dalam keadaan ini ketika melindungi sementara HD eksternal dengan kata sandi untuk memudahkan menghapusnya setelah itu. Namun saya tidak menghapusnya jadi ketika saya ingin menggunakannya di lain waktu saya ingin memastikan bahwa tidak ada yang penting di drive. Sayangnya kata sandi dari pengelola kata sandi saya tidak berfungsi lagi karena saya lupa memperbarui/menghapusnya dari sana. Oleh karena itu ketika saya memikirkan diri saya di masa depan, tampaknya merupakan ide yang baik untuk membuatnya lebih mudah dengan tidak membuat repositori restic yang tidak dapat saya dekripsi.

Saya punya ide lain, bagaimana restic akan mencoba menggunakan "restic" sebagai kata sandi default ketika tidak ada kata sandi untuk mengakses repositori dan kembali ke pesan kesalahan jika tidak berhasil? Kemudian pengguna dapat menggunakan kata sandi ini untuk menunjukkan bahwa mereka tidak memerlukan enkripsi dan restic akan membukanya tanpa sihir tambahan.

Saya setuju dengan komentar sebelumnya untuk tetap memeriksa perlindungan dari kesalahan pengguna.

Restic perlu mendukung kata sandi kosong untuk alasan yang telah disebutkan. Saya
secara khusus tidak ingin mengenkripsi cadangan lokal saya karena saya tidak mau
kehilangan akses ke mereka. Saya tidak ingin mengambil risiko lupa kata sandi dan
tidak dapat memulihkan data. Ini adalah risiko nyata karena pengguna biasanya
memulihkan sangat jarang, dan sering menjalankan pencadangan tanpa pengawasan yang tidak mereka lakukan
perlu memasukkan kata sandi, sehingga lebih mungkin untuk dilupakan.

Menyimpan kata sandi dalam file atau skrip adalah solusi yang rawan kesalahan untuk a
masalah yang seharusnya tidak ada.

Saya setuju bahwa perawatan harus dilakukan untuk mencegah pengunggahan yang tidak disengaja
data tidak terenkripsi ke repo jarak jauh.

Sepertinya solusi sederhana adalah memiliki opsi baris perintah,
--allow-empty-password . Pengguna dapat mengatur sakelar itu di skrip mereka dan
defaultnya bisa tetap membutuhkan kata sandi.

Ini adalah risiko nyata karena pengguna biasanya sangat jarang memulihkan, dan sering menjalankan pencadangan tanpa pengawasan yang tidak perlu memasukkan kata sandi, sehingga kemungkinan besar akan dilupakan.

Kata sandi cadangan semacam itu tidak dimaksudkan untuk dihafal. Satu-satunya kata sandi enkripsi kompleks yang perlu Anda ingat adalah kata sandi untuk pengelola kata sandi Anda, yang akan sering Anda gunakan. Dan Anda _benar-benar_ harus menggunakan pengelola kata sandi.

Menyimpan kata sandi dalam file atau skrip adalah solusi yang rawan kesalahan untuk masalah yang seharusnya tidak ada.

Maaf, saya hanya tidak melihat bagaimana ini merupakan solusi yang rawan kesalahan. Sepertinya cara yang sepenuhnya valid untuk mengotomatisasi enkripsi bagi saya. Masalahnya diselesaikan dengan, sekali lagi, menggunakan pengelola kata sandi.

Sepertinya solusi sederhana adalah memiliki opsi baris perintah, --allow-empty-password . Pengguna dapat mengatur sakelar itu dalam skrip mereka dan defaultnya tetap memerlukan kata sandi.

Ini sepertinya cara yang masuk akal untuk menghindari kesalahan pengguna. Namun, masih ada kekhawatiran mengenai peningkatan permukaan serangan, dan perlu ditangani dengan sangat hati-hati.

Kata sandi cadangan semacam itu tidak dimaksudkan untuk dihafal. Satu-satunya kata sandi enkripsi kompleks yang perlu Anda ingat adalah kata sandi untuk pengelola kata sandi Anda, yang akan sering Anda gunakan. Dan Anda benar-benar harus menggunakan pengelola kata sandi.

Pengelola kata sandi sama sekali bukan solusi yang valid untuk masalah ini. Inti dari membuat cadangan adalah untuk membuat cadangan file Anda, yang mencakup database pengelola kata sandi ! Lalu, bagaimana Anda memulihkan kata sandi ke kumpulan cadangan ketika kata sandi disimpan di dalam kumpulan cadangan terenkripsi?

Saat merancang sistem pencadangan, Anda harus merencanakan skenario terburuk, yang mencakup pemulihan ketika Anda tidak memiliki apa pun yang tersedia kecuali cadangan Anda. Apa yang Anda lakukan adalah membuat cadangan basis data pengelola kata sandi Anda secara terpisah dari cadangan Restic Anda. Itu bagus untuk Anda , tetapi Anda tidak boleh memaksakan sistem itu pada pengguna lain. Dan tidak masuk akal untuk mengatakan bahwa pengelola kata sandi diperlukan untuk menggunakan Restic, terutama ketika itu bahkan tidak dirancang untuk berintegrasi dengannya. Jika ya, tolong tunjukkan saya dokumentasi untuk efek itu.

Restic, seperti banyak perangkat lunak lainnya, dimaksudkan untuk memungkinkan pengguna memenuhi kebutuhan mereka. Kebutuhan Anda tidak termasuk skenario pemulihan cadangan bare-metal, tidak ada apa-apa selain-Anda-Restic-backup. kebutuhan pengguna lain lakukan. Tolong jangan mendikte kebutuhan orang lain kepada mereka.

Ini sepertinya cara yang masuk akal untuk menghindari kesalahan pengguna. Namun, masih ada kekhawatiran mengenai peningkatan permukaan serangan, dan perlu ditangani dengan sangat hati-hati.

Kekhawatiran spesifik apa yang Anda lihat terkait peningkatan permukaan serangan yang disebabkan oleh opsi --allow-empty-password diusulkan?

Ini sepertinya cara yang masuk akal untuk menghindari kesalahan pengguna. Namun, masih ada kekhawatiran mengenai peningkatan permukaan serangan, dan perlu ditangani dengan sangat hati-hati.

Ide saya yang lain adalah restic menggunakan kata sandi default untuk mengakses repositori ketika tidak ada kata sandi yang ditentukan, misalnya restic . Kemudian UI untuk membuat repositori baru tidak berubah dan hanya ketika pengguna menggunakan default password restic maka secara otomatis dapat mengakses repositori dan pengguna tidak perlu mengingat password.

Maaf, saya hanya tidak melihat bagaimana ini merupakan solusi yang rawan kesalahan. Sepertinya cara yang sepenuhnya valid untuk mengotomatisasi enkripsi bagi saya. Masalahnya diselesaikan dengan, sekali lagi, menggunakan pengelola kata sandi.

Selama tidak ada integrasi dengan pengelola kata sandi, masih ada bahaya bahwa nilai di pengelola kata sandi salah, ketinggalan zaman atau tidak sengaja terhapus karena akan ada salinan kata sandi di luar pengelola kata sandi.

Saya juga ingin melihat opsi untuk mengizinkan kata sandi kosong (melalui penggunaan flag --allow-empty-password , atau mungkin sesuatu yang lebih verbose/unik untuk menyoroti risikonya, seperti flag --dont-blame-nrpe NRPE).

Kasus penggunaan saya:

• Bisnis: kami memiliki repositori yang terdapat dalam lingkungan tepercaya yang kami perlukan "siapa saja" untuk dapat memulihkan dari keadaan darurat/bencana tanpa harus memiliki pengetahuan khusus (yaitu, kata sandi repositori).
• Beranda: Saya ingin membuat cadangan restic dari hal-hal seperti foto keluarga. Ini tidak terlalu rahasia, dan dalam kasus kematian saya sebelum waktunya, keluarga saya harus dapat mengakses data penting pribadi ini dengan resistensi minimum (_misalnya, tanpa harus menemukan frasa sandi di brankas, itu mungkin di luar tanggal atau bercampur dengan yang lain_).

Saya memahami perlunya frasa sandi untuk memastikan integritas data serta enkripsi. Saya melihat file di direktori keys tampak seperti objek JSON. Mungkin kunci psuedo-random dapat dibuat (daripada tidak ada kunci) dan disimpan di sana? Ini tidak membantu pengguna yang mencoba menghindari overhead enkripsi karena alasan kinerja.

@fd0 Apa pendapat Anda tentang opsi baris perintah --allow-empty-password diusulkan? Ini akan membutuhkan frasa sandi secara default, tetapi memungkinkan pengguna untuk menimpanya bila perlu.

Dan tolong pertimbangkan untuk membuka kembali masalah ini. Banyak kebutuhan pengguna termasuk mencadangkan file non-rahasia tanpa risiko kehilangan akses karena lupa atau salah menempatkan frasa sandi.

Pengguna restic baru di sini -- bahkan belum membuat repositori pertama saya -- tetapi pengalaman bertahun-tahun dengan alat lain -- favorit saya adalah "pembuangan" lama yang bagus. Dengan hormat, ini tidak perlu dipikirkan -- tentu saja kata sandi kosong harus diizinkan. Dengan segala cara, tambahkan tanda untuk meminimalkan risiko kesalahan yang tidak disengaja, tetapi harap jangan mendiktekan kasus penggunaan kepada pengguna berpengalaman (potensial) yang telah dengan jelas menunjukkan kebutuhan lain.
Yang saya coba lakukan hanyalah membuat cadangan lokal untuk keamanan; keamanan tidak menjadi masalah, dan saya jauh lebih mungkin kehilangan jejak kata sandi daripada membutuhkan cadangan. Dan saya benci pengelola kata sandi...

Memiliki persyaratan kata sandi menyulitkan untuk mengotomatisasi pencadangan, dan perlu memberikan kata sandi dalam file env atau skrip membuat seluruh hal keamanan tidak berguna sejak awal.

perlu memberikan kata sandi dalam env atau file skrip membuat seluruh hal keamanan tidak berguna sejak awal.

Itu belum tentu benar. Ada cara yang baik untuk melakukan itu.

Itu belum tentu benar. Ada cara yang baik untuk melakukan itu.

Tolong jangan ulangi argumen ini di sini. Banyak pengguna perlu membuat cadangan kata sandi yang tidak terenkripsi atau kosong. Jika Anda bukan salah satu dari mereka, bagus untuk Anda.

@mholt , ada rekomendasi? Saya akan dengan senang hati mencadangkan server saya tanpa gangguan dengan keamanan maksimum.

Banyak pengguna perlu membuat cadangan kata sandi yang tidak terenkripsi atau kosong.

Ini biasanya merupakan masalah XY .

@mholt , ada rekomendasi? Saya akan dengan senang hati mencadangkan server saya tanpa gangguan dengan keamanan maksimum.

Ini sangat tergantung pada situasi spesifik Anda, model ancaman, lingkungan, risiko yang dapat diterima, dan tujuan teknis dan kegunaan. Jadi tidak, saya tidak memiliki serangkaian rekomendasi untuk siapa pun.

Ini biasanya masalah XY.

Jadi tidak, saya tidak memiliki serangkaian rekomendasi untuk siapa pun.

Sikap merendahkan itu tidak membantu. Jauh lebih buruk bahwa setelah memberi tahu kami bahwa kebutuhan kami salah, Anda kemudian menolak untuk memberikan saran apa pun. Ini adalah proyek FOSS, bukan Apple, Inc.

Misalnya, saya tidak perlu atau tidak ingin mengenkripsi cadangan lokal saya dari data saya yang sudah tidak terenkripsi. Jika disk utama saya gagal dan saya perlu memulihkan cadangan saya, frasa sandi disimpan di dalam repositori cadangan dengan skrip cadangan dan file konfigurasi saya. Perhatian utama saya adalah untuk tidak mencegah orang lain mengakses data yang tidak sensitif ini -- perhatian utama saya adalah pemulihan yang mudah dan tidak terkunci dari data saya.

Ini adalah kasus umum bagi banyak pengguna, dan bukan Anda yang memutuskan apa kebutuhan pengguna.

Perangkat lunak ada untuk melayani pengguna, bukan untuk memaksa pengguna menyetujui tuntutannya.

Terima kasih telah menjelaskan kasus penggunaan Anda dan kekhawatiran Anda lagi. Sebagai catatan, saya pikir mereka valid, terutama yang "hilang kata sandi". Saya juga berpikir bahwa bendera khusus untuk restic init seperti --allow-empty-password akan berfungsi (Saya memiliki beberapa pertimbangan untuk kasus sudut, tetapi saya yakin itu dapat diselesaikan). Karena itu saya akan membuka kembali masalah ini.

Perlu diketahui bahwa mengizinkan kata sandi kosong akan mengatasi masalah keamanan untuk "kata sandi yang hilang", tetapi akan tetap mengenkripsi semua data seperti biasa.

Pada catatan yang berbeda, saya tidak suka nada di utas ini sama sekali. Anda bebas untuk tidak menggunakan restic, tidak apa-apa. Sebagian besar dari kita mengerjakan istirahat di waktu luang kita. Beberapa komentar di utas ini terlihat sangat berjudul, diparafrasekan: "Anda harus mengimplementasikan fitur ini, ada pengguna yang membutuhkannya!". Bukan itu masalahnya. Kami dapat mempertimbangkan dan menerapkannya, tetapi kami juga dapat memutuskan untuk tidak melakukan apa pun.

Jadi, tolong, semuanya, biarkan diskusi ini tetap produktif, bahkan jika Anda tidak setuju. :)

@fd0 Maafkan saya karena tidak jelas. Saya tidak menuntut atau mengharapkan apa pun dari Anda atau pengembang Restic mana pun. Ini proyek Anda dan waktu Anda, dan Anda dapat mengerjakan apa pun yang Anda inginkan.

Yang saya minta adalah Anda mempertimbangkan fitur dan kasus penggunaan ini. Jika Anda tidak tertarik untuk menerapkannya sendiri, tidak apa-apa, dan saya meminta Anda membiarkan masalah ini terbuka sehingga orang lain dapat mendiskusikannya, dan Anda mempertimbangkan PR yang mungkin menerapkannya.

Yang saya keberatan adalah komentar (bukan milik Anda) yang menunjukkan bahwa pengguna yang menginginkan fitur ini tidak memahami kebutuhan mereka sendiri, terutama bila diikuti dengan penolakan untuk menyarankan alternatif. Itu suara kasar dan tidak membantu.

Bagi saya, saya menggunakan git-annex dengan remote khusus bup. Lampiran sudah mendukung file enkripsi (yang saya matikan, untuk menggunakan fitur deduping bup). Dan kemudian saya mencadangkan bup repo (yang hanya merupakan repo git mewah) ke server jarak jauh. Saya kemudian dapat menghapus repo bup, karena itu hanya cache, dan melakukan pemulihan melalui restic, sesuai kebutuhan.

Jadi, pada dasarnya, saya menggabungkan banyak alat sekali pakai, di Unix Way(tm), karena masing-masing melakukan tugasnya dengan baik. Restic (Saat ini saya beralih dari bermuka dua) tidak sliding-window-blok deduplication, untuk awan terpencil, dan itu semua harus saya untuk melakukan. Enkripsi dan deduplikasi blok lokal terjadi pada lapisan yang berbeda. Jadi, saya tidak ingin memiliki kata sandi yang ditentukan, atau enkripsi apa pun (yang sebenarnya menghemat penggunaan CPU).

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

Ini hanya setengah dari yang saya inginkan, karena masih mengenkripsi, tetapi dengan kata sandi kosong. Saya ingin memulihkan penggunaan cpu itu, jika saya bisa.

Perlu diketahui bahwa mengizinkan kata sandi kosong akan mengatasi masalah keamanan untuk "kata sandi yang hilang", tetapi akan tetap mengenkripsi semua data seperti biasa.

Hm, apa motivasi di balik masih mengenkripsi dengan kata sandi kosong?

Maksud saya, ketika menjalankan restic pada perangkat keras berdaya rendah, enkripsi menambahkan beberapa overhead runtime yang nyata.

Sunting: Oke, https://github.com/restic/restic/issues/1018#issuecomment -307549863 - terutama poin ke-2 menjawab pertanyaan saya.

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

Masalah utama dengan saran ini adalah: Itu tidak berfungsi, restic meminta kata sandi secara interaktif lalu:

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

Terima kasih, @fd0 , untuk membuka kembali masalah ini. Saya setuju dengan @alphapapa , niat saya bukan untuk mendorong pengembang waktu luang untuk menghabiskan waktu mereka pada apa pun yang tidak mereka sukai .

Kami hanya tidak suka diberitahu oleh orang lain bahwa kami tidak mengerti kebutuhan kami sendiri.

Menurut pandangan saya, fitur terpenting dari alat pencadangan adalah kemampuan untuk melakukan pemulihan dalam hal apa pun. Meskipun keamanan memiliki kepentingan yang sangat, sangat tinggi, itu tergantung pada situasi spesifik apakah keamanan data (kemampuan untuk memulihkan) atau keamanan data (melindungi dari akses yang tidak sah) memiliki prioritas yang lebih tinggi.

Tentu saja, Anda dapat dengan bebas memutuskan untuk mengembangkan alat hanya untuk situasi di mana keamanan lebih penting daripada keselamatan.

Seperti yang disebutkan @mholt "XY-Problem": Permintaannya adalah untuk dapat melakukan pemulihan bencana tanpa sepengetahuan apa pun di luar dokumentasi umum umum yang tersedia dan tentu saja akses ke repositori itu sendiri.
"Tanpa sepengetahuan" tidak termasuk kebutuhan atau penggunaan pengelola kata sandi.

Alasan saya menemukan masalah ini adalah: _Saya membantu beberapa orang dengan PC mereka secara pribadi. Penanganan kata sandi mereka berantakan, mencoba mengajari mereka penanganan kata sandi yang tepat saat menyiapkan cadangan pada drive USB hanya akan mengakibatkan tidak membuat cadangan sama sekali atau tidak menyediakan kata sandi saat dibutuhkan. Mereka mungkin mendapatkan bantuan oleh orang lain saat membutuhkan pemulihan, jadi apa pun yang saya buat untuk mengurangi situasi mungkin batal._

Saat ini, saya menyimpan kata sandi dalam file teks pada drive USB yang sama dengan repositori cadangan restic, yang merusak keamanan memiliki kata sandi sepenuhnya.
Dan saya tidak suka solusi ini karena menggunakan kata sandi yang tidak memberikan lapisan keamanan tambahan memberikan imajinasi keamanan yang sangat salah.

Tentu saja saya hanya berbicara tentang cadangan lokal pribadi di sini. Untuk server, saya sarankan kata sandi yang kuat disalin ke beberapa penyimpanan offline terpisah.

Saya pikir masalah lain di sini adalah; jika beberapa kerangka kerja/API mengizinkan kata sandi kosong dan beberapa tidak. Dan kita harus mendekripsi input yang dienkripsi oleh API lain dengan kata sandi kosong. Saat ini masalah saya dengan https://github.com/RNCryptor/JNCryptor

Jadi, tolong, semuanya, biarkan diskusi ini tetap produktif, bahkan jika Anda tidak setuju. :)

Setelah membaca utas ini, saya menemukan percakapan yang produktif, karena hasilnya positif.

Saya ingin mengingatkan semua orang bahwa ini adalah Github - jika Anda merasa kuat tentang sesuatu dan pengelola proyek tidak mau menerima, jangan ragu untuk membuat garpu - ini benar-benar membutuhkan beberapa detik. Jika Anda tidak memiliki keterampilan untuk membuat perubahan sendiri, mintalah orang lain untuk membantu Anda. Anda akan menemukan bahwa pengelola dapat lebih terbuka untuk menerima patch yang mengimplementasikan sesuatu yang mereka sendiri tidak akan termotivasi untuk mengimplementasikannya.

Secara pribadi, dalam hal ini, saya berpikir bahwa memaksakan prakonsepsi tentang apa yang "seharusnya" menjadi keamanan bagi semua orang, adalah sebuah kesalahan. Aturan pertama keamanan data adalah bahwa data harus dapat diakses oleh mereka yang berhak memilikinya. Aturan apa pun yang mengkompromikan aturan #1 harus dipertimbangkan dengan hati-hati.

Keamanan adalah topik yang penuh dengan FUD dan kebijakan yang didorong oleh rasa takut, menghasilkan implementasi yang naif, tergesa-gesa, dan sering kali munafik, karena hanya sedikit di antara kita yang benar-benar suka memikirkan semua hal yang bisa salah. Apalagi mau menghadapi kritik orang lain ketika kita terlihat membiarkan hal-hal yang tidak beres.

Beberapa kesalahan umum yang kita lihat setiap hari:

1) Bersikeras bahwa data yang ditulis ke media yang dienkripsi saat diam, harus dienkripsi dengan sendirinya, bahkan di lingkungan yang tepercaya. Di mana ketakutan akan intersepsi berakhir? Di mana kita mulai percaya bahwa pengguna berpotensi menjadi kompeten, dan bahwa menambahkan lapisan yang berlebihan hanya meningkatkan risiko kehilangan data?

2) Bersikeras kata sandi dengan format tertentu, yaitu 8 karakter dengan setidaknya satu huruf besar, satu angka, dan satu non-alfanumerik - ini adalah praktik umum selama 20 tahun dan sekarang telah dibantah karena rasa sakitnya melebihi keuntungan. Alih-alih, kita harus bersikeras pada kata sandi entropi tinggi yang mudah diingat seperti xkcdpassword , atau berintegrasi dengan pengelola kata sandi (yang secara efektif membuat semua konsumen utama bergantung pada kata sandi master SPOF keamanan bersama yang dapat di-spamp - tanyakan saja COMMODO) atau integrasikan 2FA (berpotensi lebih baik tergantung pada keamanan fisik faktor kedua, termasuk redundansi kunci N+1).

3) Dengan kata sandi utama - gagal men-cache-nya dalam satu sesi sehingga pengguna dipaksa untuk memasukkannya berkali-kali sepanjang hari sehingga tindakan mereka yang memasukkannya menjadi vektor serangan yang mencolok.

4) Dengan kata sandi utama - gagal untuk memeriksa kebijakan dan secara membabi buta menanyakan kata sandi utama sehingga pengguna menjadi terbiasa untuk menyajikannya ketika itu sebenarnya tidak diperlukan, mengakibatkan mereka berhenti menganalisis secara kritis apakah mereka harus menyediakannya atau tidak. contoh ini.

5) Menegakkan kebijakan dengan hak istimewa paling rendah ke titik di mana pengguna tidak menyukainya dan menghindari ikut serta, atau menemukan cara untuk mengatasinya, membiarkan pintu terbuka jauh lebih lama daripada jika ada skema yang lebih permisif.

6) Menegakkan kebijakan dengan hak istimewa paling rendah tanpa redundansi N+1, alias kurangnya pertimbangan 'kesinambungan bisnis / "kebijakan orang kunci". yaitu alih-alih mengunci sumber daya bersama di belakang 2 kunci pribadi sehingga hanya dapat diakses ketika keduanya setuju (kuorum 2), kuncilah di belakang 2 dari 3 kunci pribadi. Tidak ada yang hidup selamanya.

Setiap kali kita sebagai pemrogram menerapkan skema enkripsi kunci tunggal, kita perlu mempertimbangkan pentingnya aksesibilitas, dan mendengar kekhawatiran mereka yang sangat menyadari konsekuensi kehilangan kunci untuk skema enkripsi kunci tunggal.

Mari kita juga mencoba untuk mengingat dengan baik bahwa mengambil sesuatu dari pengguna semata-mata karena takut disalahgunakan, pada dasarnya salah - seperti hampir semua keputusan yang dibuat karena rasa takut. Menghukum semua orang karena seseorang mungkin melakukan hal yang salah, merendahkan masyarakat secara keseluruhan.

Jika saat ini Anda merasa tidak setuju dengan konsep tersebut, tarik napas dalam-dalam, hitung sampai sepuluh, lalu pertimbangkan ini: Apa yang harus kita sebagai masyarakat lakukan ketika seseorang melakukan bunuh diri dengan memasukkan kepalanya ke dalam kantong sampah dengan kaleng berisi air? semprot whip cream dan menghirup seluruh kaleng Nitrous Oxide? Haruskah kita mengambil krim cambuk semprot dari semua orang? Kantong plastik? Pernafasan? Semua hal ini dapat disalahgunakan dengan cara yang menyebabkan kematian pengguna.

Alih-alih dorongan spontan untuk mengambil barang-barang, seperti yang kita lakukan dengan seorang anak bermain korek api, kita malah harus berbuat salah dalam mendidik orang untuk menggunakan barang-barang ini dengan benar. Atau naikkan standar masuk sehingga hanya mereka yang RTFM yang akan menemukannya.

Itulah yang terjadi pada akhirnya di sini, dan keputusan untuk menerima hasil itu tidak datang sampai semua masalah dan pendapat sudah diungkapkan. Saya sarankan menonton sesi Debat Parlemen di stasiun TV publik untuk contoh seperti apa debat yang tidak produktif terdengar, lol. Para peserta di sini sangat menghormati satu sama lain sebagai perbandingan.

Ingat utilitas arsip lama yang bagus di mana enkripsi dan perlindungan kata sandi tersedia hanya sebagai opsi eksplisit tetapi tidak secara default. Dan ini adalah logika yang tepat karena keamanan mungkin memiliki banyak solusi eksternal di luar cakupan utilitas ini dan karena perawatan ini terserah pengguna. Apa yang Anda lakukan hanyalah menyediakan alat keamanan pilihan pengguna. Tetapi penulis lebih memilih untuk menjaga apa yang tidak diminta pengguna untuk mencegah penyalahgunaan.

Dan lagi tentang nada. Ini biasa untuk dunia open-source. Dan itu didukung oleh beberapa mekanisme psikologis. Kritik yang tidak disetujui penulis diperlakukan sebagai klaim untuk menghabiskan waktu luang mereka. Dan setiap kali kami harus mengingatkan: kami tidak membahas waktu luang Anda di sini, tetapi kami menjelajahi makhluk jenius Anda, fungsinya, dan logika di baliknya. Kami tidak pernah lupa bahwa Anda tidak memiliki kewajiban untuk memenuhi permintaan kami dan Anda memiliki hak penuh untuk tidak melakukan apa pun. Tetapi jika Anda menyukai apa yang Anda lakukan, itu mungkin (mungkin) karena orang lain menyukainya. Jadi mungkin ada beberapa harapan bahwa Anda tertarik untuk memenuhi permintaan setidaknya sebagian besar.

PS Semua ini hanya mengomel abstrak dan tidak ada tindakan praktik yang dimaksudkan.

Ada satu hal yang saya tidak pernah mengerti dengan diskusi tentang mengizinkan tidak ada kata sandi untuk repositori (dengan asumsi konteks @ fd0 menulis sebelumnya, bahwa data akan tetap dienkripsi); Mengapa mereka yang "tidak menginginkan" kata sandi hanya menggunakan kata sandi palsu seperti "1234" atau apa pun? Apa gunanya menulis kode di restic yang menghapus kata sandi, ketika Anda tidak peduli tentang memiliki kata sandi, Anda bisa menggunakan kata sandi dummy? Ini adalah satu variabel lingkungan atau file kata sandi, jika menurut Anda sulit untuk mengetiknya di baris perintah saat menjalankan restic.

@rawtaz Ini telah dijawab di komentar sebelumnya di utas ini.

Izinkan saya mengatakan bahwa restic init -r foo --no-password mungkin adalah nama flag yang lebih baik daripada restic init -r foo --allow-empty-password , hanya karena yang pertama lebih tepat sasaran dan yang terakhir terlalu bertele-tele.

Saya gagal melihat argumen yang bagus mengapa hanya menggunakan kata sandi tiruan bukanlah cara yang tepat untuk melakukan ini alih-alih meningkatkan basis kode restic pada topik ini. Saya pernah melihat seseorang mengatakan bahwa mereka mungkin lupa kata sandi "a". Meskipun itu mungkin benar, tentu saja mungkin untuk membuat kata sandi tiruan sederhana dan mengingatnya, atau setidaknya mencari tahu lagi saat dibutuhkan. Tapi apa pun, sebuah bendera juga berfungsi dengan baik, saya hanya kagum pada seberapa besar masalah ini: D

Nah, inilah contohnya. Membuat cadangan restic setahun yang lalu. Ditulis sebagai
kata sandi palsu, baca dari file. Tidak menuliskan kata sandi
di tempat lain. Setelah setahun tidak menggunakan mesin itu, saya sepenuhnya
lupa proses dan kata sandinya -- dan membuang waktu satu jam untuk mencoba
tebak kata sandi sebelum akhirnya menemukan (dan rekayasa balik)
naskah. Salahku sepenuhnya, tapi tetap -- aku tidak butuh keamanan,
dan tidak ingin dipaksa untuk mengingat password dummy. Dan jika saya
tidak memiliki akses ke file asli, saya akan terkunci.

TD

Bukankah itu masalah membuatnya terlalu rumit? Salah satu kata sandi yang paling umum adalah 1234. Gunakan itu dan Anda tidak perlu mencoba dan menemukannya di suatu tempat (dengan asumsi Anda tidak berpikir bahwa Anda menggunakan yang lebih rumit) karena ketika Anda perlu memasukkan kata sandi palsu, Anda tahu itu 1234. Tapi tentu saja, saya mengerti maksud Anda.

Saya juga ingin melihat opsi untuk mengizinkan kata sandi kosong (melalui penggunaan flag --allow-empty-password , atau mungkin sesuatu yang lebih verbose/unik untuk menyoroti risikonya, seperti flag --dont-blame-nrpe NRPE).

Kasus penggunaan saya:

* **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_).

Saya memahami perlunya frasa sandi untuk memastikan integritas data serta enkripsi. Saya melihat file di direktori keys tampak seperti objek JSON. Mungkin kunci psuedo-random dapat dibuat (daripada tidak ada kunci) dan disimpan di sana? Ini tidak membantu pengguna yang mencoba menghindari overhead enkripsi karena alasan kinerja.

• Bisnis: kami memiliki repositori yang terdapat dalam lingkungan tepercaya yang kami perlukan "siapa saja" untuk dapat memulihkan dari keadaan darurat/bencana tanpa harus memiliki pengetahuan khusus (yaitu, kata sandi repositori).

Tapi "siapa saja" itu sudah membutuhkan pengetahuan/petunjuk khusus. Mereka perlu tahu cara menjalankan restic untuk memulihkan data, termasuk repositori mana yang akan digunakan dan hal-hal lain, dan kemudian akan sangat mudah untuk memasukkan kata sandi tiruan dalam instruksi tersebut. Atau mereka akan menggunakan skrip atau otomatisasi serupa yang melakukan pemulihan untuk mereka (dalam hal ini mereka masih perlu mengetahui/mendapatkan instruksi ke mana harus pergi untuk menggunakan alat itu), dalam hal ini kata sandi dummy akan ditangani oleh skrip . Tidak peduli bagaimana Anda melihatnya, kata sandi palsu bukanlah masalah. Dan serius, jika semua orang tiba-tiba melupakannya, orang akan dapat menebak 1234 atau memaksanya dengan kasar. Bukan masalah :P

• Beranda: Saya ingin membuat cadangan restic dari hal-hal seperti foto keluarga. Ini tidak terlalu rahasia, dan dalam kasus kematian saya sebelum waktunya, keluarga saya harus dapat mengakses data penting pribadi ini dengan resistensi minimum (_misalnya, tanpa harus menemukan frasa sandi di brankas, itu mungkin di luar tanggal atau bercampur dengan yang lain_).

Tunggu apa? Mengapa Anda tidak ingin memiliki kata sandi, dan ketika itu tidak mungkin (setidaknya saat ini) gunakan kata sandi tiruan yang sangat sederhana (misalnya 1234), dan kemudian masukkan kata sandi tiruan yang sangat sederhana itu ke dalam brankas ? Itu sama sekali tidak ada gunanya. Letakkan di tempat lain, dan untuk apa nilainya, Anda mungkin sudah memiliki banyak informasi lain yang perlu diketahui keluarga Anda jika Anda meninggal, jadi masukkan saja kata sandi palsu Anda bersama itu.

Terakhir, kata sandi tiruan harus sangat sederhana dan jelas sehingga tidak akan ketinggalan zaman, dan tidak perlu lebih dari satu kata sandi tiruan. Jadi tidak boleh ketinggalan zaman atau dicampur dengan yang lain.

Ya, saran-saran itu sudah dibuat, jadi kami akan berputar-putar sekarang. Secara pribadi, mereka bukan solusi yang cocok yang saya rasa nyaman untuk lingkungan dan kasus penggunaan saya.

Anda tidak memerlukan fitur ini, tidak apa-apa. Itu tidak berarti kasus penggunaan orang lain tidak valid. Saya tidak menggunakan backend Amazon S3, tetapi saya tidak menyatakannya tidak diperlukan, saya hanya tidak menggunakannya. Jika fitur ini diterapkan, Anda tidak dikenakan biaya apa pun untuk tidak menggunakannya.

Ya, saran-saran itu sudah dibuat, jadi kami akan berputar-putar sekarang.

Ya, dan sejujurnya saya masih belum melihat penjelasan sebenarnya mengapa kata sandi palsu sangat sulit untuk ditangani, saya merasa saya sering melihat komplikasi yang berlebihan.

Secara pribadi, mereka bukan solusi yang cocok yang saya rasa nyaman untuk lingkungan dan kasus penggunaan saya.

Ini adalah sesuatu yang saya sangat hormati. Kasus penggunaan setiap orang bersifat individual dan Anda memiliki alur kerja Anda :)

Saya kira di beberapa titik kita akan mendapatkan --no-password atau serupa, semoga itu akan menyelesaikan kasus penggunaan ini juga. Terima kasih atas masukan Anda!

rawtaz menulis

Izinkan saya mengatakan bahwa restic init -r foo --no-password mungkin adalah nama flag yang lebih baik daripada restic init -r foo --allow-empty-password , hanya karena yang pertama lebih tepat sasaran dan yang terakhir terlalu bertele-tele.

Saya gagal melihat argumen yang bagus mengapa hanya menggunakan kata sandi tiruan bukanlah cara yang tepat untuk melakukan ini alih-alih meningkatkan basis kode restic pada topik ini. Saya pernah melihat seseorang mengatakan bahwa mereka mungkin lupa kata sandi "a". Meskipun itu mungkin benar, tentu saja mungkin untuk membuat kata sandi tiruan sederhana dan mengingatnya, atau setidaknya mencari tahu lagi saat dibutuhkan. Tapi apa pun, sebuah bendera juga berfungsi dengan baik, saya hanya kagum pada seberapa besar masalah ini: D

Saya tidak khawatir tentang penggunaan/penanganan kata sandi dummy - alih-alih saya terkadang khawatir tentang penggunaan CPU yang memperlambat proses pencadangan oleh enkripsi wajib ketika dijalankan pada perangkat keras kelas bawah.

Menyelesaikan #1018 (Cadangan tidak terenkripsi) juga akan menyelesaikan masalah ini - misalnya dengan sakelar --unencrypted alih-alih sakelar --no-password .

Saya sebenarnya menggunakan restic pada perangkat keras kelas bawah di mana CPU pasti tidak memiliki AES-NI (atau ekstensi serupa) dan di mana cadangannya terikat dengan CPU. Dalam kasus lain CPU sedikit lebih kuat tetapi satu-satunya hard drive eksternal yang tersedia sudah dienkripsi LUKS dan dengan demikian CPU terikat karena tidak cukup kuat untuk menangani dua proses enkripsi secara paralel.

Lihat juga: https://github.com/restic/restic/issues/1018#issuecomment -307549863

Jika Anda lupa cara menggunakan restic Anda dapat membaca dokumen. Jika Anda lupa lokasi repositori Anda dapat menemukannya. Atau Anda dapat dengan santai menemukan repositori yatim piatu dan bertanya-tanya apa yang ada di dalam cadangan. Tetapi jika Anda lupa kata sandi Anda kehilangan data Anda selamanya. Dan dalam kehidupan nyata Anda bisa melupakan kata sandi palsu yang paling sederhana. Anda bisa melupakan semua yang tidak sering Anda gunakan.

Jika Anda kehilangan kata sandi root, Anda dapat boot dengan opsi init=/bin/bash dan mendapatkan akses penuh. Meskipun lubang ini dapat ditutup, lubang ini masih ada di sebagian besar sistem. Mengapa? Karena kerugian dari ketidaktersediaan akan lebih dari dari ketidakamanan dalam kasus tersebut. Jadi ini adalah trade-off antara keamanan dan ketersediaan. Untuk sistem dengan kebutuhan yang lebih tinggi, ada solusi khusus, seperti kunci yang berlebihan, dengan menyediakan keamanan dan ketersediaan.

resitc bukan alat keamanan. Ini adalah alat cadangan. Dan dengan demikian, itu harus menyediakan fungsionalitas cadangan itu sendiri pertama-tama, dan baru kemudian keamanan. Jadi perlindungan kata sandi dan enkripsi dapat diberikan sebagai opsi saja dan tidak boleh ada secara default.

BTW: default adalah tanda kualitas perangkat lunak.

@vstavrinov Silakan baca pengantar restic sebelum mengatakan itu bukan alat keamanan. Ini adalah alat pencadangan yang salah satu fitur utamanya adalah mencoba membuat cadangan Anda aman. Jadi, Anda cukup jauh ketika Anda mengatakan bahwa itu tidak peduli dengan keamanan.

Tetapi jika Anda lupa kata sandi Anda kehilangan data Anda selamanya.

Ya, dan itulah mengapa Anda (dalam hal ini memiliki opsi sederhana untuk) menggunakan kata sandi palsu sehingga Anda akan selalu dapat menyadari kata sandi itu bahkan jika Anda lupa.

Dan dalam kehidupan nyata Anda bisa melupakan kata sandi palsu yang paling sederhana.

Jika ya, Anda memilih kata sandi tiruan yang terlalu rumit, dan itu bukan lagi kata sandi tiruan yang sederhana.

Seluruh diskusi ini menjadi sangat konyol, terus terang. Saya tidak percaya orang mengatakan bahwa kata sandi seperti 1234, yang merupakan salah satu yang paling umum dan jelas, adalah sesuatu yang mereka mungkin lupa dan kemudian tidak dapat mengetahuinya dengan sangat cepat (misalnya dengan hanya mencoba beberapa dummy yang jelas kata sandi). Saya akan mengatakan Anda harus berusaha sangat keras untuk tidak dapat "menebak" 1234 ketika Anda berada dalam situasi itu, dan bahkan kemudian Anda kemungkinan besar akan gagal untuk tidak menebaknya.

Tetapi jika Anda lupa kata sandi Anda kehilangan data Anda selamanya.

Wikipedia mungkin bisa membantu Anda: Coba saja kata sandi yang paling umum dari https://en.wikipedia.org/wiki/List_of_the_most_common_passwords#List.

Satu situasi di mana hal ini dapat terjadi adalah ketika variabel lingkungan RESTIC_PASSWORD tidak diekspor atau disetel ke string kosong secara tidak sengaja.

Dimungkinkan bagi kode untuk memeriksa apakah kata sandi disetel ke string kosong secara eksplisit atau tidak disetel (tidak ada opsi baris perintah yang ditentukan, variabel lingkungan tidak disetel -> berbeda dari string kosong).

Saya pikir pilihan harus diberikan kepada pengguna kata sandi mana yang ingin dipilih.

Menyelesaikan #1018 (Cadangan tidak terenkripsi) juga akan menyelesaikan masalah ini - misalnya dengan sakelar --unencrypted alih-alih --no-password switch.

Enkripsi masih harus wajib untuk melindungi dari pencarian biner pada penyedia hosting secara independen dari format, transmisi melalui saluran tidak terenkripsi dengan MITM dan sebagainya. Meskipun ini memberi Anda perlindungan sebanyak kata sandi kosong untuk serangan yang ditargetkan (nol), itu tetap menghindari kerusakan jaminan pada serangan yang tidak ditargetkan.

@rawtaz

Ini adalah alat pencadangan yang salah satu fitur utamanya adalah mencoba membuat cadangan Anda aman. Jadi, Anda cukup jauh ketika Anda mengatakan bahwa itu tidak peduli dengan keamanan.

Tidak jauh. Tunjuk saya di mana saya mengatakan "itu tidak peduli tentang keamanan". Bukan saya. Anda mengatakan hal yang sama: "Ini adalah alat cadangan". Cadangan bukan keamanan, kan?. Jadi restic bukanlah alat keamanan. Dan "... salah satu fitur utama ...". Anda benar lagi: ini adalah fitur. yaitu keamanan adalah fitur, sedangkan cadangan adalah penunjukan fungsional (target).

@rawtaz

Seluruh diskusi ini menjadi sangat konyol, terus terang. Saya tidak percaya orang mengatakan bahwa kata sandi seperti 1234 ...

Saya tidak dapat melakukan apa-apa, tetapi Anda juga benar dalam hal ini. Yang konyol adalah diskusi tentang kata sandi dummy. Tetapi saya pikir yang lebih penting adalah memahami bahwa perlindungan kata sandi dan enkripsi harus opsional. Serta tidak memaksakan fitur tambahan yang tidak diinginkan kepada pengguna, memberi mereka pilihan untuk menggunakan atau tidak menggunakannya. Dan ini juga merupakan tanda kualitas perangkat lunak.

Tetapi saya pikir yang lebih penting adalah memahami bahwa perlindungan kata sandi dan enkripsi harus opsional.

Mengapa? Mengapa "harus" alat cadangan tidak memiliki enkripsi default? Hanya karena itu adalah alat "cadangan"? Anda hanya mengatakan ini tetapi tidak ada alasan untuk semua ini.

Tidak ada keputusan desain yang bisa menyenangkan semua orang. Restic _chooses_ untuk menekankan keamanan, dan pengguna seperti saya _menyukai_ enkripsi yang kuat adalah defaultnya.

• Jika Anda tidak peduli dengan keamanan, Anda _tidak_ dapat menyalahgunakan sistem yang aman secara default. Paling buruk, Anda melihat beberapa kesalahan dan coba lagi dengan perintah yang disesuaikan.
• Jika Anda peduli dengan keamanan, ada banyak cara untuk menyalahgunakan sistem bawaan yang tidak aman hingga menimbulkan bencana. Satu bendera hilang, dan data sensitif Anda bocor, mungkin _tidak dapat diubah_.

Meminta tanda yang dapat menghilangkan kata sandi adalah satu hal, tetapi berdebat tanpa enkripsi secara default adalah "persetan" yang berbahaya bagi semua pengguna yang ada yang mengandalkan enkripsi restic. Potensi kesalahan pengguna bencana sangat besar.

@cfbao

Tetapi saya pikir yang lebih penting adalah memahami bahwa perlindungan kata sandi dan enkripsi harus opsional.

Mengapa? Mengapa "harus" alat cadangan tidak memiliki enkripsi default? Hanya karena itu adalah alat "cadangan"? Anda hanya mengatakan ini tetapi tidak ada alasan untuk semua ini.

"opsional" tidak sama dengan "default". Default seperti itu mungkin bisa diperdebatkan. Tetapi memiliki pilihan lebih penting. Meskipun kami tidak punya pilihan, tidak ada hubungannya dengan default. Itulah intinya. Pertama berikan opsi, lalu masuk akal untuk membahas default.

Dalam hal ini (masalah) cukup sederhana - kemungkinan akan ada --no-password atau flag serupa dengan restic init (dengan default masih bahwa restic meminta kata sandi saat init), tetapi ini hanya tanggapan saya tentang tanggapan terakhir @ fd0 . Dan tidak ada ETA pada saat ini, tidak perlu bertanya tentang itu :)

Sementara itu, gunakan kata sandi dummy :) Saya kira implementasi yang tepat mencakup kemampuan untuk menghapus/menghapus kata sandi/kunci yang sebelumnya digunakan untuk init repo, jadi seseorang tidak perlu membuat ulang seluruh repositori.

Enkripsi adalah hal lain, dan dilacak dalam masalah lain itu.

Saya tidak terlalu peduli tentang opsi tanpa kata sandi, tetapi Anda berdebat untuk default tanpa enkripsi:

Jadi perlindungan kata sandi dan enkripsi dapat diberikan sebagai opsi saja dan tidak boleh ada secara default.

BTW: default adalah tanda kualitas perangkat lunak.

yang menurut saya berbahaya.

Meskipun saya biasanya setuju dengan poin @rawtaz , jika diskusinya hanya tentang opsi tanpa kata sandi (tidak mengubah default), saya tidak memiliki terlalu banyak kepentingan di dalamnya.

@cfbao

Saya tidak terlalu peduli tentang opsi tanpa kata sandi, tetapi Anda berdebat untuk default tanpa enkripsi:

Jadi perlindungan kata sandi dan enkripsi dapat diberikan sebagai opsi saja dan tidak boleh ada secara default.

Anda dapat melihat bahkan dalam kutipan ini "opsi" adalah yang pertama dan "default" adalah yang berikutnya. Dan itu intinya lagi.

Dalam hal ini (masalah) cukup sederhana - kemungkinan akan ada --no-password atau flag serupa dengan restic init (dengan default masih bahwa restic meminta kata sandi saat init), tetapi ini hanya tanggapan saya tentang tanggapan terakhir @ fd0 . Dan tidak ada ETA pada saat ini, tidak perlu bertanya tentang itu :)

Sementara itu, gunakan kata sandi dummy :) Saya kira implementasi yang tepat mencakup kemampuan untuk menghapus/menghapus kata sandi/kunci yang sebelumnya digunakan untuk init repo, jadi seseorang tidak perlu membuat ulang seluruh repositori.

Solusi yang mungkin lebih sederhana adalah restic untuk mendukung kata sandi tiruan yang akan mencoba membuka repositori yang ada jika tidak ada kata sandi yang ditentukan oleh pengguna.

Mengenai penanganan kata sandi tiruan: Tidak ada kata sandi tiruan terbaik yang jelas yang berfungsi untuk semua orang. 1234 adalah kata sandi tiruan yang menjengkelkan karena memerlukan empat jari untuk naik dan mengetik. "asdf" jauh lebih cepat untuk mengetik misalnya. Juga beberapa layanan membatasi pilihan kata sandi, jadi hanya angka atau hanya empat digit yang mungkin tidak dapat dilakukan. Oleh karena itu solusi di dalam restic akan paling ramah pengguna. Maka pengguna hanya perlu mengetikkan kata sandi tiruan sekali.

Dari sudut pandang keamanan berdasarkan desain, memberikan segala jenis kata sandi palsu adalah ide yang buruk.

Jika seseorang benar-benar ingin menghindari enkripsi atau tidak membutuhkannya, cukup berikan kata sandi yang konsisten. Anda tidak perlu mengetiknya, Anda dapat menulis skrip untuk membungkus kode restic dan hard sepuasnya di sana. Sungguh, apakah itu lebih berfungsi daripada memasok alamat repositori atau opsi konfigurasi lainnya?

Memiliki restic mencoba satu set hardcoded password palsu atau dummy hanya meminta masalah. Bagaimana jika beberapa jiwa malang kebetulan memilih salah satu dari kata sandi "ajaib" yang Anda usulkan? Apakah kami memperingatkan mereka untuk tidak memilih sandi enkripsi palsu dan tiruan khusus kami? "Tidak Ted, Anda tidak dapat memilih SPACECHICKEN sebagai kata sandi repositori Anda, ini _khusus_." ;)

Saya baik-baik saja dengan memberikan opsi bagi pengguna untuk menembak diri mereka sendiri dengan ("--no-repository-password") tetapi saya tidak berpikir restic harus melangkah lebih jauh dari itu untuk menenangkan segmen pengguna yang sangat kecil yang keinginan REDUCED keamanan.

Dari sudut pandang keamanan berdasarkan desain, memberikan segala jenis kata sandi palsu adalah ide yang buruk.

Mengapa ini lebih buruk daripada tidak mengizinkan kata sandi?

Jika seseorang benar-benar ingin menghindari enkripsi atau tidak membutuhkannya, cukup berikan kata sandi yang konsisten. Anda tidak perlu mengetiknya, Anda dapat menulis skrip untuk membungkus kode restic dan hard sepuasnya di sana. Sungguh, apakah itu lebih berfungsi daripada memasok alamat repositori atau opsi konfigurasi lainnya?

Ya, itu lebih banyak pekerjaan. Restic akan menjadi solusi cadangan dan outputnya adalah repositori. Jadi, idealnya, repositori akan berisi segalanya untuk memulihkan cadangan. Tetapi ketika menggunakan skrip pembungkus yang meng-hardcode kata sandi tiruan berarti skrip ini perlu dicadangkan oleh sesuatu yang lain, jika tidak, repositori tidak akan berguna.

Memiliki restic mencoba satu set hardcoded password palsu atau dummy hanya meminta masalah. Bagaimana jika beberapa jiwa malang kebetulan memilih salah satu dari kata sandi "ajaib" yang Anda usulkan? Apakah kami memperingatkan mereka untuk tidak memilih sandi enkripsi palsu dan tiruan khusus kami? "Tidak Ted, Anda tidak dapat memilih SPACECHICKEN sebagai kata sandi repositori Anda, ini _khusus_." ;)

Apa sebenarnya masalahnya? Ted masih dapat memilih kata sandi ini. Itu hanya berarti restic akan menggunakannya jika mereka tidak menentukannya. Restic masih akan mengenkripsi/mendekripsi repositori dengan cara yang sama seolah-olah bukan kata sandi khusus.

Saya baik-baik saja dengan memberikan opsi bagi pengguna untuk menembak diri mereka sendiri dengan ("--no-repository-password") tetapi saya tidak berpikir restic harus melangkah lebih jauh dari itu untuk menenangkan segmen pengguna yang sangat kecil yang keinginan REDUCED keamanan.

Menyebut ini "tembak diri mereka sendiri di kaki" tidak perlu menghakimi dan juga tidak berarti mengurangi keamanan. Ketersediaan dan ketahanan terhadap ransomware harus menjadi bagian dari konsep keamanan. Kemampuan yang hilang untuk memulihkan cadangan karena kehilangan akses ke kata sandi enkripsi akan mengurangi keamanan. Menyimpan cadangan dengan aman ke sistem penyimpanan tambahan tidak akan menurunkan tingkat keamanan, di sini.

Why is it worse than allowing no password?

Saya tidak yakin bagaimana saya akan meyakinkan seseorang bahwa hardcoded, tersembunyi, diam-diam mencoba melawan kata sandi repositori akan menjadi ide yang buruk. Jika Anda berpikir demikian, kemungkinan tidak ada argumen yang berfokus pada keamanan yang akan meyakinkan Anda.

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.

Saya memilih contoh yang menghibur, mungkin seharusnya tidak. Mari kita asumsikan bahwa sandi tiruan Anda yang Anda inginkan untuk disimpan secara diam-diam dan dicoba secara otomatis jika dekripsi gagal adalah: "12345". Pengguna yang naif dapat memilih itu sebagai kata sandi mereka. Sekarang mereka memiliki repositori yang mereka yakini dienkripsi (dan semacamnya) tetapi _anyones_ restic dapat mendekripsi. Argumen ini berlaku untuk setiap set kata sandi yang Anda pilih di set hardcoded Anda. Ini pada dasarnya adalah desain keamanan yang buruk.

Ada istilah untuk apa yang Anda usulkan. Ini disebut pintu belakang enkripsi :) Menyembunyikan pintu belakang itu di dokumen mengasumsikan bahwa semua pembaca akan membaca manual sepenuhnya sebelum menggunakan restic. Bukankah itu akan memenuhi kebutuhan lebih banyak orang untuk membuat mereka membaca dokumen untuk menentukan bagaimana mengurangi rasa aman jika mereka secara aneh menginginkan itu?

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.

Jika Anda tidak berpikir bahwa enkripsi saat istirahat adalah kebijakan keamanan yang solid dan akan memilih sesuatu yang lain, Anda pasti minoritas. Default tidak aman semacam ini tidak melayani siapa pun dan harus dihindari di setiap titik. Seseorang hanya perlu melihat referensi keamanan APAPUN untuk saran dalam kasus ini. Maksud saya bukan yang diperdebatkan - saya memperdebatkan praktik standar industri.

Bahkan contoh Anda hanya menambahkan media penyimpanan akan sangat diuntungkan dari enkripsi saat istirahat. Saya sangat merekomendasikan untuk membaca set terbaru NIST, ISO 27002, NERC, IEC 62443 atau standar yang diterima secara global untuk panduan dalam praktik terbaik di sini. Kami tidak berada di wilayah baru.

Saya juga harus menunjukkan bahwa kami secara efektif menggabungkan dua masalah di utas ini: manajemen kunci dan enkripsi.

Mungkin di situlah kebingungan muncul.

Mungkin masalah ini dapat diselesaikan dengan dokumentasi yang mengatakan sesuatu seperti:

Jika Anda tidak ingin mengamankan repositori Anda dengan kata sandi, cukup gunakan string: password

Dengan begitu ada cara terkenal untuk mencapai pencadangan/pemulihan dengan restic tanpa harus mengelola kunci apa pun.

Why is it worse than allowing no password?

Saya tidak yakin bagaimana saya akan meyakinkan seseorang bahwa hardcoded, tersembunyi, diam-diam mencoba melawan kata sandi repositori akan menjadi ide yang buruk. Jika Anda berpikir demikian, kemungkinan tidak ada argumen yang berfokus pada keamanan yang akan meyakinkan Anda.

Saya kira Anda kehilangan "tidak" di sana ...

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.

Saya memilih contoh yang menghibur, mungkin seharusnya tidak. Mari kita asumsikan bahwa sandi tiruan Anda yang Anda inginkan untuk disimpan secara diam-diam dan dicoba secara otomatis jika dekripsi gagal adalah: "12345". Pengguna yang naif dapat memilih itu sebagai kata sandi mereka. Sekarang mereka memiliki repositori yang mereka yakini dienkripsi (dan semacamnya) tetapi _anyones_ restic dapat mendekripsi. Argumen ini berlaku untuk setiap set kata sandi yang Anda pilih di set hardcoded Anda. Ini pada dasarnya adalah desain keamanan yang buruk.

Saya tidak mengusulkan untuk mencobanya ketika dekripsi gagal tetapi ketika tidak ada kata sandi yang ditentukan untuk dekripsi. Jika seseorang memilih kata sandi yang tidak aman, itu tidak aman terlepas dari itu dicoba oleh restic secara langsung atau oleh seseorang yang memaksa kata sandi. "12345" juga merupakan kata sandi yang tidak aman saat ini, dan tidak akan berubah jika itu menjadi kata sandi default untuk restic.

Ada istilah untuk apa yang Anda usulkan. Ini disebut pintu belakang enkripsi :) Menyembunyikan pintu belakang itu di dokumen mengasumsikan bahwa semua pembaca akan membaca manual sepenuhnya sebelum menggunakan restic. Bukankah itu akan memenuhi kebutuhan lebih banyak orang untuk membuat mereka membaca dokumen untuk menentukan bagaimana mengurangi rasa aman jika mereka secara aneh menginginkan itu?

Pintu belakang enkripsi adalah jika restic menggunakan kata sandi default selain kata sandi yang diberikan pengguna saat mengenkripsi data. Proposal saya adalah tentang mencoba satu kata sandi saat dekripsi. Pengguna akan tetap aktif memilih sandi buruk ini.

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.

Jika Anda tidak berpikir bahwa enkripsi saat istirahat adalah kebijakan keamanan yang solid dan akan memilih sesuatu yang lain, Anda pasti minoritas. Default tidak aman semacam ini tidak melayani siapa pun dan harus dihindari di setiap titik. Seseorang hanya perlu melihat referensi keamanan APAPUN untuk saran dalam kasus ini. Maksud saya bukan yang diperdebatkan - saya memperdebatkan praktik standar industri.

Apa default tidak aman menurut Anda?

Bahkan contoh Anda hanya menambahkan media penyimpanan akan sangat diuntungkan dari enkripsi saat istirahat. Saya sangat merekomendasikan untuk membaca set terbaru NIST, ISO 27002, NERC, IEC 62443 atau standar yang diterima secara global untuk panduan dalam praktik terbaik di sini. Kami tidak berada di wilayah baru.

Enkripsi saat istirahat tidak berarti bahwa restic perlu melakukannya. Penyimpanan tambahan saja masih dapat dienkripsi dengan cara lain jika perlu. Namun demikian, akan ada beberapa penyimpanan yang tidak terenkripsi, meskipun hanya untuk kata sandi. Kalau tidak, konsep cadangan akan bergantung pada seseorang yang selalu mengingat kata sandi.

berhenti berlangganan dari utas ini ...

Biarkan saja di sini, jelas bahwa beberapa orang menginginkan opsi --no-password ke init , dan hanya itu yang menjadi topik masalah ini. Enkripsi atau tidak adalah masalah yang terpisah.

Hanya komentar singkat di sini:
Saya pengguna yang tidak peduli dengan enkripsi. Tidak ada yang sensitif tentang data saya. Saya peduli tentang orang yang dapat menggunakan dalam 20-40 tahun yang bukan saya. Hanya menggunakan rclone adalah alternatif lain yang lebih buruk.

Restic terlihat seperti alat yang bagus untuk ini, kecuali mengamanatkan enkripsi dan kata sandi berarti saya harus mempertimbangkannya. Mungkin README di repositori cadangan. Ini lebih berfungsi dan solusi apa pun (dari pihak saya) mengalahkan enkripsi apa pun.

tanda

Terima kasih atas kontribusi Anda, saya pikir kami telah mengumpulkan informasi yang cukup.