Restic: 空のパスワードを許可する

Resticは空のパスワードを許可する必要があります。

ユースケースについて詳しく教えてください。 なぜresticは空のパスワードを許可する必要があるのですか？

それは設計上の決定です。

確かにそうです。 しかし、私はあなたが何を達成しようとしているのか興味があります。

関連する問題はおそらく＃1018です

ディレクトリ内のファイルを変更するときのクイックセーフティネットとして、ローカルシステムに一時的にいくつかのディレクトリをバックアップしたかっただけです。 バックアップを作成するたびに、パスフレーズを覚えたり、わざわざパスフレーズを入力したりしたくありませんでした。 aをパスワードとして使用したばかりなので、パスワードをまったく使用しない場合と比較して、このパスワードを使用しても実際のセキュリティ上の利点はありません。 したがって、覚えたり、役に立たないパスワードを入力したりするオーバーヘッドが少ないと、ツールの完成度が低くなります。

説明してくれてありがとう。 このチェックを続けたいので、今のところこの問題を閉じます。 コメントを追加してください。 ありがとう！

少し前にこれについて話したとき、あなたは議論があるだろうと言いました...
このチェックが役立つと思う理由を説明していただけますか？ 後でパスワードを追加できるように、リポジトリは引き続き暗号化する必要があります。

私の経験では、ほとんどのユーザーがパスワードを設定したいと思うので、このチェックは便利だと思います。 空のパスワードを受け入れるか、空のパスワードを受け入れることを可能にするコードパスを持っていると、ユーザーが適切な暗号化なしで誤ってバックアップをリモートの場所に保存する可能性があります。 これが発生する可能性のある状況の1つは、環境変数RESTIC_PASSWORDが誤ってエクスポートされていないか、空の文字列に設定されていない場合です。

したがって、この場合、パスワードを設定する必要があるという小さな不便さを取り除くよりも、ユーザーを間違いから保護する方が良いと私は感じています:)

ただし、これには簡単な回避策があります。パスワードマネージャーを使用し、文字列test使用し、 /etc/profile.dなどのファイルを介して静的にRESTIC_PASSWORDエクスポートし、ディレクトリの名前を使用します。 'パスワードとして（またはリポジトリ）を再保存しています...

リポジトリにアクセスするには、パスワードの知識が必要であることに注意してください。
パスワードを紛失すると、データが回復不能に失われます。

データを永久に失いたくない場合、どうすればこれを防ぐことができますか？

@LexSongパスワードマネージャーを使用します。

2018年7月3日火曜日09:56:56 AM -0700に、ChenfengBaoは次のように書いています。

@LexSongパスワードマネージャーを使用します。

パスワードマネージャーデータベースのバックアップをどのように提案しますか？ あなたは
ここで、データベースなしでパスワードマネージャーを使用することを提案します。
パスワード？ どのパスワードマネージャーが、
からのパスワード？

パスワード管理は大きなトピックであり、このスレッドではあまり詳しく説明したくありません。 適切に行われれば、パスワードは頭痛の種にはならないことを指摘するだけです。 オンラインには多数のリソースがあります。

パスワードマネージャーのデータベースはすでに適切に暗号化されている必要があるため、別の暗号化レイヤーなしで好きな場所に配置できます。 クラウドベースのパスワードマネージャーサービスもたくさんあるので、自分でバックアップについて心配する必要はありません。

resticのサポートについては、パスワードをローカルのプレーンテキストファイルに入れて、 --password-fileオプションを使用するだけです。 そうすれば、パスワードを手動で入力する必要はありません。 パスワード自体も、記録のためにパスワードマネージャーに配置する必要があります。

結局のところ、物事を本当に安全に保つために覚えておかなければならない複雑なパスワード/パスフレーズが常に1つあります。

実際、resticリポジトリにパスワードが本当に必要ない場合は、1文字のダミーパスワードを使用してみませんか？

パスワードとして「a」を使用することは実際には私の回避策でしたが、数年後にこのリポジトリをもう一度見たときに、削除するのを忘れた場合に備えて、これを使用したことを覚えているかどうかわからないため、適切ではないと感じています。もう必要ありません。 したがって、それを理解するために、ある種のブルートフォースを実装する必要があるかもしれません。 これはすべて回避できる作業です。

以前は、後で削除しやすくするために外部HDをパスワードで一時的に保護したときに、この状態のままになる状況で、すでに単純な一時パスワードを使用していました。 ただし、削除しなかったので、次回使用したいときに、ドライブに重要なものがないことを確認したいと思いました。 残念ながら、パスワードマネージャーからのパスワードは、そこから更新/削除するのを忘れたため、機能しなくなりました。 ですから、自分の将来を考えるとき、解読できないような休息のレポシトリーを作らないことで、彼が楽になるようにするのは良い考えのようです。

別の考えがあります。リポジトリにアクセスするためのパスワードがない場合、resticはデフォルトのパスワードとして「restic」を使用し、機能しない場合はエラーメッセージにフォールバックするのはどうでしょうか。 次に、ユーザーはこのパスワードを使用して、暗号化の必要がないことを示し、resticは余分な魔法を使わずにパスワードを開くことができます。

ユーザーのミスから保護するためのチェックを続けるために、以前のコメントに同意します。

Resticは、すでに述べた理由により、空のパスワードをサポートする必要があります。 私
特に、ローカルバックアップを暗号化したくないのは
それらへのアクセスを失います。 パスワードを忘れるリスクを冒したくない
データを復元できません。 ユーザーは通常、これは実際のリスクです。
復元することはめったになく、多くの場合、無人バックアップを実行します。
パスワードを入力する必要があり、忘れやすくなります。

パスワードをファイルまたはスクリプトに保存することは、エラーが発生しやすい回避策です。
存在してはならない問題。

誤ってアップロードしないように注意する必要があることに同意します
暗号化されていないデータをリモートリポジトリに送信します。

簡単な解決策は、コマンドラインオプションを使用することだと思われます。
--allow-empty-password 。 ユーザーはスクリプトでそのスイッチを設定でき、
デフォルトのままにして、パスワードを要求することができます。

通常、ユーザーが復元することはめったになく、パスワードを入力する必要のない無人バックアップを実行することが多く、パスワードを忘れてしまう可能性が高いため、これは実際のリスクです。

このようなバックアップパスワードは、記憶されることを意図したものではありません。 覚えておく必要のある複雑な暗号化パスワードは、頻繁に使用するパスワードマネージャー用のパスワードだけです。 そして、あなたは_本当に_パスワードマネージャーを使うべきです。

パスワードをファイルまたはスクリプトに保存することは、存在してはならない問題のエラーが発生しやすい回避策です。

申し訳ありませんが、エラーが発生しやすい回避策がわかりません。 私には、暗号化を自動化するための完全に有効な方法のようです。 この問題は、パスワードマネージャーを使用することで解決されます。

簡単な解決策は、コマンドラインオプション--allow-empty-passwordです。 ユーザーはスクリプトでそのスイッチを設定でき、デフォルトのままでパスワードを要求できます。

これは、ユーザーエラーを回避するための合理的な方法のように思われます。 ただし、攻撃対象領域の増加に関する懸念は依然としてあり、細心の注意を払って対処する必要があります。

このようなバックアップパスワードは、記憶されることを意図したものではありません。 覚えておく必要のある複雑な暗号化パスワードは、頻繁に使用するパスワードマネージャー用のパスワードだけです。 そして、あなたは本当にパスワードマネージャーを使うべきです。

パスワードマネージャーは、この問題に対する有効な解決策ではありません。 バックアップを作成することの全体的なポイントは、パスワードマネージャーのデータベースを含むファイルをバックアップすることです。 では、パスワードが暗号化されたバックアップセット内に保存され

バックアップシステムを設計するときは、最悪のシナリオを計画する必要があります。これには、バックアップ以外に利用できるものがない場合の復元が含まれます。 明らかに行うことは、Resticバックアップとは別にパスワードマネージャーデータベースをバックアップすることです。 それはあなたにとっては問題ありませんが、そのシステムを他のユーザーに押し付けることはあなたにとってではありません。 また、Resticを使用するには、パスワードマネージャーが必要であると言うのはばかげています。特に、Resticと統合するように設計されていない場合はなおさらです。 もしそうなら、その趣旨の文書を見せてください。

Resticは、多くのソフトウェアと同様に、ユーザーがニーズを満たすことができるようにすることを目的としています。 ニーズには、ベアメタルのResticバックアップの復元シナリオは含まれていません。 他のユーザーのニーズはそうです。 他の人のニーズを彼らに口述しないでください。

これは、ユーザーエラーを回避するための合理的な方法のように思われます。 ただし、攻撃対象領域の増加に関する懸念は依然としてあり、細心の注意を払って対処する必要があります。

提案された--allow-empty-passwordオプションによって引き起こされる攻撃対象領域の増加に関して、具体的にどのような懸念がありますか？

これは、ユーザーエラーを回避するための合理的な方法のように思われます。 ただし、攻撃対象領域の増加に関する懸念は依然としてあり、細心の注意を払って対処する必要があります。

私の他のアイデアは、パスワードが指定されていない場合に、デフォルトのパスワードを使用してリポジトリにアクセスすることrestic 。たとえば、

申し訳ありませんが、エラーが発生しやすい回避策がわかりません。 私には、暗号化を自動化するための完全に有効な方法のようです。 この問題は、パスワードマネージャーを使用することで解決されます。

パスワードマネージャーとの統合がない限り、パスワードマネージャーの外部にパスワードのコピーが存在するため、パスワードマネージャーの値が間違っていたり、古くなっていたり、誤って削除されたりする危険性があります。

また、空のパスワードを許可するオプションも必要です（ --allow-empty-passwordフラグ、またはNRPEの--dont-blame-nrpeフラグなど、リスクを強調するためのより冗長で一意のフラグを使用することにより）。

私のユースケース：

• ビジネス：信頼できる環境にリポジトリが含まれているため、特別な知識（リポジトリのパスワードなど）がなくても、緊急/災害時に「誰でも」復元できる必要があります。
• ホーム：家族の写真などの復元バックアップを作成したいと思います。 これらは特に機密ではなく、私の早すぎる死の場合、私の家族は最小限の抵抗でこの個人的に重要なデータにアクセスできる必要があります（たとえば、金庫の中でパスフレーズを見つける必要なしに、それはおそらく外れています-日付またはanother_）と混同。

データの整合性と暗号化を確保するためのパスフレーズの必要性を理解しています。 keysディレクトリ内のファイルがJSONオブジェクトのように見えます。 おそらく、疑似ランダムキーが（キーなしではなく）生成され、そこに保存される可能性がありますか？ ただし、これは、パフォーマンス上の理由から暗号化のオーバーヘッドを回避しようとしているユーザーには役立ちません。

@ fd0提案された--allow-empty-passwordコマンドラインオプションについてどう思いますか？ デフォルトではパスフレーズが必要ですが、ユーザーは必要に応じてパスフレーズを上書きできます。

そして、この問題を再開することを検討してください。 多くのユーザーのニーズには、パスフレーズを忘れたり置き忘れたりしてアクセスを失うリスクなしに、機密でないファイルをバックアップすることが含まれます。

ここの真新しいresticユーザーは-私の最初のリポジトリをまだ作成していません-しかし他のツールでの長年の経験-私のお気に入りは古き良き「ダンプ」です。 ちなみに、これは簡単です。もちろん、空のパスワードを許可する必要があります。 不注意によるエラーのリスクを最小限に抑えるために、必ずフラグを追加してください。ただし、他のニーズを明確に示した経験豊富な（潜在的な）ユーザーにユースケースを指示しないでください。
私がやろうとしているのは、安全のためにローカルバックアップを作成することだけです。 セキュリティは問題ではなく、バックアップが必要になるよりも、パスワードを見失う可能性がはるかに高くなります。 そして、私はパスワードマネージャーが嫌いです...

パスワード要件があると、バックアップを自動化するのが難しくなり、envまたはスクリプトファイルでパスワードを提供する必要があると、そもそもセキュリティ全体が役に立たなくなります。

envまたはスクリプトファイルでパスワードを提供する必要があると、そもそもセキュリティ全体が役に立たなくなります。

それは必ずしも真実ではありません。 それを行うには良い方法があります。

それは必ずしも真実ではありません。 それを行うには良い方法があります。

ここでこの議論を再ハッシュしないでください。 多くのユーザーは、暗号化されていない、または空のパスワードのバックアップを作成する必要があります。 あなたがそれらの一人でないなら、あなたにとって良いことです。

@mholt 、推奨事項はありますか？ 最大限のセキュリティを確保しながら、干渉なしでサーバーをバックアップできれば幸いです。

多くのユーザーは、暗号化されていない、または空のパスワードのバックアップを作成する必要があります。

これは通常、 XY問題です。

@mholt 、推奨事項はありますか？ 最大限のセキュリティを確保しながら、干渉なしでサーバーをバックアップできれば幸いです。

それは、特定の状況、脅威モデル、環境、許容可能なリスク、および技術的および使いやすさの目標に大きく依存します。 ですから、私は誰に対しても包括的な推奨事項を持っていません。

これは通常、XY問題です。

ですから、私は誰に対しても包括的な推奨事項を持っていません。

その見下すような態度は役に立ちません。 さらに悪いことに、私たちのニーズが間違っていると言った後、あなたはアドバイスを提供することを拒否します。 これはFOSSプロジェクトであり、Apple、Incではありません。

たとえば、暗号化されていないデータのローカルバックアップを暗号化する必要はありません。 プライマリディスクに障害が発生し、バックアップを回復する必要がある場合、パスフレーズはバックアップスクリプトと構成ファイルとともにバックアップリポジトリ内に保存さ

これは多くのユーザーによくあるケースであり、ユーザーのニーズを決めるのはあなたではありません。

ソフトウェアは、ユーザーにサービスを提供するために存在し、ユーザーにその要求に同意するように強制するためではありません。

ユースケースを説明していただきありがとうございます。また懸念があります。 記録としては、特に「パスワードを紛失した」ものは有効だと思います。 私はまたのための特別なフラグと思いますrestic initのように--allow-empty-password （私はコーナーケースのためのいくつかの注意事項がありますが、私は彼らが解決できることを確信している）に働くだろう。 したがって、この問題を再開します。

空のパスワードを許可すると、「パスワードを紛失した」という安全上の懸念に対処できますが、通常どおりすべてのデータが暗号化されることに注意してください。

別の言い方をすれば、私はこのスレッドのトーンがまったく好きではありません。 あなたはresticを自由に使用しないでください、それは完全に問題ありません。 私たちのほとんどは、暇なときに休憩に取り組んでいます。 このスレッドのいくつかのコメントは、「この機能を実装する必要があります。それを必要とするユーザーがいます！」という非常に権利のある言い換えで出くわします。 そうではありません。 それを検討して実装することはできますが、何もしないことを決定することもできます。

ですから、皆さん、同意できない場合でも、この議論を生産的にしていきましょう。 :)

@ fd0不明な点があることをお許しください。 私はあなたやRestic開発者に何も要求したり期待したりしません。 それはあなたのプロジェクトとあなたの時間であり、あなたはあなたが望むものに取り組むことができます。

私がお願いするのは、この機能とユースケースを検討していただくことです。 自分で実装することに興味がない場合は問題ありません。他の人が話し合うことができるように問題を開いたままにして、実装する可能性のあるPRを検討してください。

私が反対するのは、この機能を必要とするユーザーが自分のニーズを理解していないことを示唆するコメント（あなたのコメントではない）です。特に、代替案の提案を拒否した場合はそうです。 それは失礼で役に立たないノイズです。

私の場合、bupの特別なリモートでgit-annexを使用しています。 Annexは、ファイルの暗号化をすでにサポートしています（bupの重複排除機能を利用するためにオフにしました）。 次に、bupレポジトリ（これは単なる派手なgitレポジトリです）をリモートサーバーにバックアップします。 次に、bupリポジトリは単なるキャッシュであるため削除し、必要に応じてresticを介して復元を実行できます。

つまり、基本的には、Unix Way（tm）で、それぞれが独自の機能を十分に発揮するように、多数の使い捨てツールをつなぎ合わせています。 Resticは（私は現在、二枚舌から切り替えています）リモートクラウドに、重複排除ウィンドウブロックスライディングんし、それは私がそれを行うために必要なすべてです。 暗号化とローカルブロックの重複排除は、別のレイヤーで行われます。 したがって、パスワードを指定したり、暗号化したりする必要はありません（実際にはCPUの使用量を節約できます）。

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

これはまだ暗号化されているので、私が望むものの半分にすぎませんが、パスワードは空白です。 可能であれば、そのCPU使用率を回復したいと思います。

空のパスワードを許可すると、「パスワードを紛失した」という安全上の懸念に対処できますが、通常どおりすべてのデータが暗号化されることに注意してください。

うーん、空のパスワードで暗号化する動機は何ですか？

つまり、低電力のハードウェアでresticを実行すると、暗号化によって実行時のオーバーヘッドが顕著になります。

編集：わかりました、 https： //github.com/restic/restic/issues/1018#issuecomment-307549863-特に2番目のポイントが私の質問に答えます。

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問題」について述べたように、要求は、公開されている一般的な復元ドキュメントと、もちろんリポジトリ自体へのアクセス以外の知識がなくても、ディザスタリカバリを実行できるようにすることです。
「知識なし」は、パスワードマネージャーの必要性または使用を除外します。

私がこの問題を見つけた理由は次のとおりです。_私は一部の人々のPCをプライベートで支援しています。 彼らのパスワードの取り扱いはめちゃくちゃです。USBドライブにバックアップを設定する際に適切なパスワードの取り扱いを教えようとすると、バックアップがまったく作成されないか、必要なときに利用できるパスワードが保持されなくなります。 復元が必要なときに他の誰かの助けを借りる可能性があるため、状況を緩和するために私が思いついたものはすべて無効になる可能性があります。_

現在、パスワードをresticバックアップリポジトリと同じUSBドライブ上のテキストファイルに保存しているため、パスワードを完全に保持するセキュリティが損なわれています。
また、セキュリティの追加レイヤーを提供しないパスワードを使用すると、セキュリティの想像が非常に間違ってしまうため、このソリューションは好きではありません。

もちろん、ここでは個人的なローカルバックアップについてのみ話します。 サーバーの場合は、強力なパスワードを別のオフラインストレージにコピーすることをお勧めします。

ここでのもう1つの問題は次のとおりです。 一部のフレームワーク/ APIが空のパスワードを許可し、一部が許可しない場合。 また、空のパスワードを使用して別のAPIによって暗号化された入力を復号化する必要があります。 これは現在、 https：//github.com/RNCryptor/JNCryptorに関する私の問題です

ですから、皆さん、同意できない場合でも、この議論を生産的にしていきましょう。 :)

このスレッドを読んだ後、結果がポジティブだったので、会話は生産的だと思います。

これはGithubであることを皆さんに思い出させたいと思います。何かについて強く感じていて、プロジェクトメンテナが受け入れられない場合は、気軽にフォークを作成してください。文字通り数秒かかります。 自分で変更を加えるスキルが不足している場合は、他の人に助けを求めてください。 メンテナは、自分自身を実装する動機がなかったであろう何かを実装するパッチを受け入れることに、よりオープンになり得ることがわかります。

個人的には、この場合、セキュリティがすべての人に「あるべき」という先入観を強制することは間違いだと思います。 データセキュリティの最初のルールは、データを所有する資格のある人がデータにアクセスできる必要があるということです。 ルール1に違反するルールは、慎重に検討する必要があります。

セキュリティはFUDと恐怖に駆り立てられたポリシーに満ちたトピックであり、その結果、素朴で、急いで、しばしば偽善的な実装になります。 私たちが物事がうまくいかないことを許していると見られるとき、他人の批判に直面したいと思うことはさらに少なくなります。

私たちが毎日目にするいくつかのよくある間違い：

1）保存時に暗号化されたメディアに書き込まれるデータは、信頼できる環境であっても、それ自体が暗号化されている必要があることを主張します。 傍受の恐れはどこで終わりますか？ ユーザーが有能である可能性があり、冗長レイヤーを追加するだけでデータ損失のリスクが高まると、どこから信頼し始めるのでしょうか。

2）特定の形式のパスワード、つまり、少なくとも1つの大文字、1つの数字、および1つの英数字以外の8文字を主張する-これは20年間の一般的な慣習であり、痛みが利益を超えているため、現在は非難されています。 代わりに、 xkcdpasswordのような記憶に残る高エントロピーのパスワードを主張するか、パスワードマネージャーと統合するか（すべての主要な消費者を、スピアフィッシュ可能な共有セキュリティSPOFマスターパスワードに効果的に依存させる-COMMODOに問い合わせるだけです）、2FAを統合する必要があります（より良い可能性があります） N + 1キーの冗長性を含む、2番目の要素の物理的セキュリティによって異なります）。

3）マスターパスワードを使用する-セッションでパスワードをキャッシュできないため、ユーザーは1日を通して何度もパスワードを入力する必要があり、パスワードを入力するアクション自体が目立つ攻撃ベクトルになります。

4）マスターパスワードを使用する-ポリシーの確認に失敗し、ユーザーが実際には必要のないときにマスターパスワードを提示することに慣れるように、盲目的にマスターパスワードを照会すると、ユーザーはマスターパスワードを提供する必要があるかどうかの分析を批判的に停止します。このインスタンス。

5）最小特権のポリシーを適用して、ユーザーがそれを憤慨し、オプトインを回避するか、回避する方法を見つけて、より寛容なスキームがある場合よりもはるかに長くドアを開いたままにします。

6）N + 1冗長性のない最小特権のポリシーの実施、別名「ビジネス継続性/「キーマンポリシー」の考慮事項の欠如。 つまり、共有リソースを2つの秘密鍵の背後にロックして、両方が同意した場合にのみアクセスできるようにする（2のクォーラム）代わりに、3つの秘密鍵のいずれか2つの背後にロックします。 誰も永遠に生きません。

私たちプログラマーが単一鍵暗号化スキームを実装するときはいつでも、アクセシビリティの重要性を考慮し、単一鍵暗号化スキームの鍵損失の結果を痛感している人々の懸念を聞く必要があります。

また、純粋に誤用を恐れてユーザーから物事を奪うことは根本的に間違っていることを覚えておいてください-ほとんどすべての決定が恐れからなされたように。 誰かが間違ったことをするかもしれないという理由でみんなを罰することは、社会全体を弱体化させます。

この瞬間にあなたがその概念に同意しないと感じたら、深呼吸をして、10まで数え、そしてこれを考慮してください：誰かが缶の入ったゴミ袋に頭を入れて自殺したとき、私たちは社会として何をすべきかホイップクリームをスプレーして、亜酸化窒素の缶全体を吸入しますか？ スプレーホイップクリームをみんなから奪うべきですか？ ビニール袋？ 呼吸？ これらすべてのものは、ユーザーを死に至らしめるような方法で悪用される可能性があります。

マッチで遊んでいる子供と同じように、物事を奪おうとするひざまずく衝動の代わりに、私たちは人々にこれらのものを正しく使用するように教育する側で誤りを犯すべきです。 または、RTFMを使用する人だけが見つけられるように、エントリのバーを上げます。

それが最終的にここで起こったことであり、その結果を受け入れるという決定は、すべての問題と意見がすでに表明されるまで来ませんでした。 非生産的な討論がどのように聞こえるかの例については、公共テレビ局で議会討論会を見るのをお勧めします、笑。 ここの参加者は、比較するとお互いに非常に敬意を表していた。

暗号化とパスワード保護が明示的なオプションとしてのみ利用可能であり、デフォルトでは利用できなかった古い優れたアーカイブユーティリティを覚えておいてください。 そして、これは正しい論理です。なぜなら、セキュリティにはこのユーティリティの範囲外の多くの外部ソリューションがある可能性があり、この注意はユーザー次第だからです。 ユーザーが選択したセキュリティツールを提供するだけです。 しかし、作者は、誤用を防ぐためにユーザーが求めていないことに注意を払うことを好みます。

そして再びトーンについて。 これはオープンソースの世界では普通のことです。 そして、それはいくつかの心理的メカニズムに支えられています。 著者が同意しない批判は、余暇を過ごすという主張として扱われます。 そして、私たちが思い出さなければならないたびに：私たちはここであなたの暇な時間を議論しません、代わりに私たちはあなたの天才の生き物、その機能、そしてその背後にある論理を探求します。 私たちはあなたが私たちの要求を満たす義務がなく、あなたには何もしない完全な権利があることを決して忘れません。 しかし、あなたが自分のしていることが好きなら、それは（多分）他の人がそれを好きだからかもしれません。 したがって、少なくとも大多数の需要を満たすことに関心があるという希望が存在する可能性があります。

PSこれらはすべて抽象的な暴言であり、実践的な行動を意味するものではありません。

リポジトリにパスワードを許可しないことについての議論で私が理解したことがないことが1つあります（ @ fd0が以前に書いたコンテキストを想定すると、データはまだ暗号化されます）。 パスワードを「望まない」人は、「1234」などのダミーパスワードを使用しないのはなぜですか。 パスワードを気にしない場合はダミーのパスワードを使用できるのに、パスワードを削除するコードをresticで記述することのポイントは何ですか？ resticを実行しているときにコマンドラインで入力するのが面倒だと思われる場合は、1つの環境変数またはパスワードファイルを使用します。

@rawtazこれは、このスレッドに関する以前のコメントで回答されています。

restic init -r foo --no-passwordは、おそらくrestic init -r foo --allow-empty-passwordよりも優れたフラグ名であると言わせてください。これは、前者の方が要点が多く、後者が冗長すぎるためです。

このトピックの残りのコードベースを増やす代わりに、ダミーのパスワードを使用するだけではこれを行うのに完全に実行可能な方法ではない理由について、私は良い議論を見ることができません。 パスワード「a」を忘れてしまうかもしれないと誰かが言うのを見たことがあります。 それは本当かもしれませんが、確かに簡単なダミーのパスワードを発明してそれを覚えておくか、少なくとも必要なときにそれを新たに理解することは可能です。 しかし、いずれにせよ、フラグも正常に機能します。これがどれほど大きな問題であるかに驚いています：D

さて、ここに例があります。 1年前に復元バックアップを作成しました。 スクリプト化された
ダミーパスワード、ファイルから読み取ります。 パスワードを書き留めていませんでした
どこか他の。 その機械を使わなかった1年後、私は完全に
プロセスとパスワードの両方を忘れてしまい、1時間も無駄になりました
最終的に見つける（およびリバースエンジニアリング）前にパスワードを推測する
スクリプト。 私のせいですが、それでも-私はセキュリティを必要としません、
ダミーのパスワードを覚えることを余儀なくされたくありません。 そして私が
元のファイルにアクセスできなかったら、私はロックアウトされていたでしょう。

TD

それはそれを過度に複雑にしたことの問題ではありませんか？ 最も一般的なパスワードの1つは1234です。これを使用すると、ダミーのパスワードを入力する必要があるときにそれがわかっているので、どこかでそれを探す必要はありません（より複雑なパスワードを使用したとは思わない場合）。 1234.しかし、確かに、私はあなたが何を意味するのかわかります。

また、空のパスワードを許可するオプションも必要です（ --allow-empty-passwordフラグ、またはNRPEの--dont-blame-nrpeフラグなど、リスクを強調するためのより冗長で一意のフラグを使用することにより）。

私のユースケース：

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

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

データの整合性と暗号化を確保するためのパスフレーズの必要性を理解しています。 keysディレクトリ内のファイルがJSONオブジェクトのように見えます。 おそらく、疑似ランダムキーが（キーなしではなく）生成され、そこに保存される可能性がありますか？ ただし、これは、パフォーマンス上の理由から暗号化のオーバーヘッドを回避しようとしているユーザーには役立ちません。

• ビジネス：信頼できる環境にリポジトリが含まれているため、特別な知識（リポジトリのパスワードなど）がなくても、緊急/災害時に「誰でも」復元できる必要があります。

しかし、それらの「誰でも」はすでに特別な知識/指示を必要としています。 使用するリポジトリなど、データを復元するためにresticを実行する方法を知っている必要があります。そうすれば、それらの命令にダミーのパスワードを含めるのは非常に簡単です。 または、復元を行うスクリプトまたは同様の自動化を使用します（この場合でも、そのツールを使用する場所についての指示を知っている/取得する必要があります）。この場合、ダミーパスワードはスクリプトによって処理されます。 。 これをどのように見ても、ダミーのパスワードは問題になりません。 そして真剣に、誰もが突然それを忘れた場合、人々は単純に1234を推測するか、ブルートフォース攻撃を行うことができます。 それは問題ではありません：P

• ホーム：家族の写真などの復元バックアップを作成したいと思います。 これらは特に機密ではなく、私の早すぎる死の場合、私の家族は最小限の抵抗でこの個人的に重要なデータにアクセスできる必要があります（たとえば、金庫の中でパスフレーズを見つける必要なしに、それはおそらく外れています-日付またはanother_）と混同。

待って、何？ いったいなぜパスワードを使わないようにしたいのでしょうか。それが不可能な場合（現在は少なくとも）、超単純なダミーパスワード（1234など）を使用して、その超単純なダミーパスワードを金庫に入れてください。 それは完全に無意味でしょう。 それを別の場所に置いてください。その価値については、家族が亡くなった場合に知っておく必要のある他の情報がすでにたくさんあるので、ダミーのパスワードを一緒に置いてください。

最後に、ダミーパスワードは非常にシンプルでわかりやすく、古くならないようにする必要があります。また、複数のダミーパスワードは必要ありません。 したがって、古くなったり、別のものと混合したりしないでください。

はい、それらの提案はすでに行われているので、私たちは今、輪になって行きます。 個人的には、これらは私の環境やユースケースに適したソリューションではありません。

この機能は必要ありません。問題ありません。 これは、他のすべてのユースケースが無効であることを意味するわけではありません。 私はAmazonS3バックエンドを使用していませんが、不要であるとは宣言していません。使用していません。 この機能が実装されている場合、それを使用しないことはあなたに何の費用もかかりません。

はい、それらの提案はすでに行われているので、私たちは今、輪になって行きます。

ええ、そして正直なところ、ダミーのパスワードを処理するのが非常に難しい理由についての実際の説明はまだ見ていません。私はそれの過度の複雑さをほとんど見たと感じています。

個人的には、これらは私の環境やユースケースに適したソリューションではありません。

これは私が完全に尊敬していることです。 すべてのユースケースは個別であり、ワークフローがあります:)

ある時点で--no-passwordなどが得られると思いますが、これでこのユースケースも解決されることを願っています。 ご入力いただきありがとうございます。

rawtazは書いた

restic init -r foo --no-passwordは、おそらくrestic init -r foo --allow-empty-passwordよりも優れたフラグ名であると言わせてください。これは、前者の方が要点が多く、後者が冗長すぎるためです。

このトピックの残りのコードベースを増やす代わりに、ダミーのパスワードを使用するだけではこれを行うのに完全に実行可能な方法ではない理由について、私は良い議論を見ることができません。 パスワード「a」を忘れてしまうかもしれないと誰かが言うのを見たことがあります。 それは本当かもしれませんが、確かに簡単なダミーのパスワードを発明してそれを覚えておくか、少なくとも必要なときにそれを新たに理解することは可能です。 しかし、いずれにせよ、フラグも正常に機能します。これがどれほど大きな問題であるかに驚いています：D

ダミーのパスワードの使用/処理については心配していません。代わりに、CPU使用率が、ローエンドのハードウェアで実行されている場合に必須の暗号化によってバックアッププロセスが遅くなることを心配しています。

＃1018（暗号化されていないバックアップ）を解決すると、この問題も解決されます。たとえば、 --unencryptedスイッチの代わりに--no-passwordスイッチを使用します。

私は実際に、CPUにAES-NI（または同様の拡張機能）がまったくなく、バックアップがCPUにバインドされているローエンドのハードウェアでresticを使用しました。 別のケースでは、CPUはもう少し強力でしたが、使用可能な外付けハードドライブはすでにLUKSで暗号化されていたため、2つの暗号化プロセスを並行して処理するほど強力ではなかったためCPUにバインドされていました。

参照： https ：

Resticの使い方を忘れた場合はドキュメントを読むことができます。 リポジトリの場所を忘れた場合は見つけることができます。 または、孤立したリポジトリに偶然遭遇して、内部に何がバックアップされているのか疑問に思うことがあります。 しかし、パスワードを忘れた場合、データは永久に失われます。 そして実際には、最も単純なダミーパスワードを忘れることができます。 あまり使わないものはすべて忘れてしまいます。

rootパスワードを紛失した場合は、init = / bin / bashオプションを使用して起動し、フルアクセスを取得できます。 この穴は閉じることができますが、ほとんどのシステムにまだ存在しています。 どうして？ なぜなら、そのような場合、利用できないことによる損失は、不安による損失以上のものになるからです。 したがって、これはセキュリティと可用性の間のトレードオフです。 より高い要件を持つシステムの場合、セキュリティと可用性の両方を提供する冗長キーなどの特別なソリューションが存在します。

resitcはセキュリティツールではありません。 これはバックアップツールです。 そのため、まずバックアップ機能自体を提供し、次にセキュリティを提供する必要があります。 したがって、パスワード保護と暗号化はオプションとしてのみ提供でき、デフォルトでは実施しないでください。

ところで：デフォルトはソフトウェア品質の印です。

@vstavrinovセキュリティツールではないと言う前に、resticの紹介を読んでください。 これはバックアップツールであり、その主な機能の1つは、バックアップを安全にしようとすることです。 ですから、セキュリティについては心配していないと言うと、かなり遠いです。

しかし、パスワードを忘れた場合、データは永久に失われます。

はい。そのため、ダミーのパスワードを使用すると（この場合は簡単なオプションがあります）、パスワードを忘れた場合でも常にパスワードを認識できるようになります。

そして実際には、最も単純なダミーパスワードを忘れることができます。

もしそうなら、あなたはあまりにも複雑なダミーパスワードを選びました、そしてそれはもはや実際には単純なダミーパスワードではありません。

この議論全体は、率直に言って、陽気にばかげています。 最も一般的で明白なパスワードの1つである1234のようなパスワードは、忘れてしまい、すぐに理解できない可能性があると人々が言っ​​ているとは信じられません（たとえば、いくつかの明白なダミーを試してみるだけでは）パスワード）。 そのような状況にあるときに1234を「推測」できないように、真剣に努力する必要があると思います。それでも、推測できない可能性があります。

しかし、パスワードを忘れた場合、データは永久に失われます。

ウィキペディアが役立つかもしれません： https：//en.wikipedia.org/wiki/List_of_the_most_common_passwords#Listから最も一般的なパスワードを試してみて

これが発生する可能性のある状況の1つは、環境変数RESTIC_PASSWORDが誤ってエクスポートされていないか、空の文字列に設定されていない場合です。

パスワードが空の文字列に明示的に設定されているか、設定されていないかをコードで確認できます（コマンドラインオプションが指定されていない、環境変数が設定されていない->空の文字列とは異なります）。

どのパスワードを選択したいかをユーザーに選択させるべきだと思います。

＃1018（暗号化されていないバックアップ）を解決すると、この問題も解決されます。たとえば、-no-passwordスイッチの代わりに--unencryptedスイッチを使用します。

フォーマット、MITMを使用した暗号化されていないチャネルを介した送信などとは関係なく、ホスティングプロバイダーでのバイナリ検索から保護するために、暗号化は引き続き必須です。 これにより、標的型攻撃（ゼロ）に対して空のパスワードが提供するのと同じくらいの保護が提供されますが、それでも非標的型攻撃の巻き添え被害は回避されます。

@rawtaz

これはバックアップツールであり、その主な機能の1つは、バックアップを安全にしようとすることです。 ですから、セキュリティについては心配していないと言うと、かなり遠いです。

それほど遠くない。 「セキュリティは気にしない」と言っているところを教えてください。 私はしません。 あなたは同じことを言います：「それはバックアップツールです」。 バックアップはセキュリティではありませんよね？ したがって、resticはセキュリティツールではありません。 そして「...主要な機能の1つ...」。 あなたは再び正しいです：それは機能です。 つまり、セキュリティは機能ですが、バックアップは機能（ターゲット）の指定です。

@rawtaz

この議論全体は、率直に言って、陽気にばかげています。 人々が1234のようなパスワードを言っているとは信じられません...

私は何もできませんが、この場合もあなたは正しいです。 ばかげているのは、ダミーのパスワードについての議論です。 しかし、もっと重要なのは、パスワードの保護と暗号化はオプションであるべきだということを理解することだと思います。 また、ユーザーに不要な機能を追加しないようにして、使用するかどうかを選択できるようにします。 そして、これはソフトウェア品質の証でもあります。

しかし、もっと重要なのは、パスワードの保護と暗号化はオプションであるべきだということを理解することだと思います。

どうして？ バックアップツールにデフォルトの暗号化がないのはなぜですか？ 「バックアップ」ツールだからといって？ あなたはこれを言っているだけですが、これには理由がありません。

設計上の決定は誰もが喜ぶことはできません。 Resticはセキュリティを重視することを_選択_し、私のようなユーザーは強力な暗号化がデフォルトであると_love_します。

• セキュリティを気にしない場合は、デフォルトで保護されたシステムを誤用することはできません。 最悪の場合、いくつかのエラーが表示され、調整されたコマンドで再試行します。
• セキュリティに関心がある場合、デフォルトで安全でないシステムを悪用して壊滅的な影響を与える方法はたくさんあります。 フラグが1つ欠落していると、機密データが漏洩します。おそらく_不可逆的に_です。

パスワードを省略できるフラグを要求することは1つのことですが、デフォルトで暗号化を行わないと主張することは、resticの暗号化に依存しているすべての既存のユーザーにとって危険な「ねじ込み」です。 壊滅的なユーザーエラーの可能性は非常に大きいです。

@cfbao

しかし、もっと重要なのは、パスワードの保護と暗号化はオプションであるべきだということを理解することだと思います。

どうして？ バックアップツールにデフォルトの暗号化がないのはなぜですか？ 「バックアップ」ツールだからといって？ あなたはこれを言っているだけですが、これには理由がありません。

「オプション」は「デフォルト」と同じではありません。 デフォルト自体は議論の余地があるかもしれません。 しかし、オプションを持つことはより重要です。 選択の余地はありませんが、デフォルトとは何の関係もありません。 それがポイントです。 最初にオプションを提供してから、デフォルトについて説明するのが理にかなっています。

この場合（問題）は非常に単純です- --no-passwordまたはrestic initと同様のフラグが存在する可能性があります（デフォルトでは、初期化時にresticがパスワードを要求します）が、これは単なる@ fd0の最後の応答についての私の

一方、ダミーのパスワードを使用してください:)適切な実装には、以前にリポジトリの初期化に使用されたパスワード/キーを削除/設定解除する機能が含まれていると思います。したがって、リポジトリ全体を再作成する必要はありません。

ただし、暗号化は別のことであり、その別の問題で追跡されます。

パスワードなしのオプションについてはあまり気にしませんが、デフォルトで暗号化なしを主張していました。

したがって、パスワード保護と暗号化はオプションとしてのみ提供でき、デフォルトでは実施しないでください。

ところで：デフォルトはソフトウェア品質の印です。

危険だと思います。

私は@rawtazの意見に概ね同意しますが、パスワードなしのオプション（デフォルトを変更しない）について厳密に議論している場合は、

@cfbao

パスワードなしのオプションについてはあまり気にしませんが、デフォルトで暗号化なしを主張していました。

したがって、パスワード保護と暗号化はオプションとしてのみ提供でき、デフォルトでは実施しないでください。

この引用でも、「オプション」が最初で「デフォルト」が次にあることがわかります。 そして、それが再びポイントです。

この場合（問題）は非常に単純です- --no-passwordまたはrestic initと同様のフラグが存在する可能性があります（デフォルトでは、初期化時にresticがパスワードを要求します）が、これは単なる@ fd0の最後の応答についての私の

一方、ダミーのパスワードを使用してください:)適切な実装には、以前にリポジトリの初期化に使用されたパスワード/キーを削除/設定解除する機能が含まれていると思います。したがって、リポジトリ全体を再作成する必要はありません。

おそらくもっと簡単な解決策は、ユーザーがパスワードを指定しない場合に既存のリポジトリを開こうとするダミーのパスワードをサポートすることです。

ダミーパスワードの処理について：すべての人に有効な明確な最良のダミーパスワードはありません。 1234は、上に移動して入力するのに4本の指が必要なため、煩わしいダミーパスワードです。 たとえば、「asdf」は入力がはるかに高速です。 また、一部のサービスではパスワードの選択が制限されているため、数字または4桁のみが使用できない場合があります。 したがって、restic内のソリューションが最もユーザーフレンドリーになります。 そうすれば、ユーザーはダミーのパスワードを1回入力するだけで済みます。

設計によるセキュリティの観点から、あらゆる種類のダミーパスワードを提供することは悪い考えです。

IFF誰かが本当に暗号化を回避したい、またはそれを必要としない場合は、一貫したパスワードを提供するだけです。 入力する必要はありません。そこにある心ゆくまで、残りのコードとハードコードをラップするスクリプトを書くことができます。 本当に、それはリポジトリアドレスや他の設定オプションを提供するよりも多くの作業ですか？

偽のまたはダミーのハードコードされたパスワードのセットをresticに試してもらうことは、問題を引き起こしているだけです。 貧しい人々があなたの提案した「魔法の」パスワードの1つをたまたま選んだ場合はどうなりますか？ 特別なダミーの偽の暗号化パスワードを選択するように警告しますか？ 「テッドではありません。リポジトリのパスワードとしてSPACECHICKENを選択することはできません。それは_special_です。」 ;）

ユーザーが（ "--no-repository-password"）を使って自分の足を撃つオプションを提供することは問題ありませんが、resticは、ユーザーのごく一部のユーザーをなだめるために、それ以上のことを行うべきではないと思います。削減されたセキュリティを望んでいます。

設計によるセキュリティの観点から、あらゆる種類のダミーパスワードを提供することは悪い考えです。

パスワードを許可しないよりも悪いのはなぜですか？

IFF誰かが本当に暗号化を回避したい、またはそれを必要としない場合は、一貫したパスワードを提供するだけです。 入力する必要はありません。そこにある心ゆくまで、残りのコードとハードコードをラップするスクリプトを書くことができます。 本当に、それはリポジトリアドレスや他の設定オプションを提供するよりも多くの作業ですか？

はい、それはより多くの仕事です。 Resticはバックアップソリューションであり、その出力はリポジトリです。 したがって、理想的には、リポジトリにはバックアップを復元するためのすべてのものが含まれます。 ただし、ダミーパスワードをハードコードするラッパースクリプトを使用する場合は、このスクリプトを他の何かでバックアップする必要があることを意味します。そうしないと、リポジトリが役に立たなくなります。

偽のまたはダミーのハードコードされたパスワードのセットをresticに試してもらうことは、問題を引き起こしているだけです。 貧しい人々があなたの提案した「魔法の」パスワードの1つをたまたま選んだ場合はどうなりますか？ 特別なダミーの偽の暗号化パスワードを選択するように警告しますか？ 「テッドではありません。リポジトリのパスワードとしてSPACECHICKENを選択することはできません。それは_special_です。」 ;）

正確には何が問題ですか？ テッドは引き続きこのパスワードを選択できます。 それは、彼らがそれを指定しなければ、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、または実際に世界的に認められている標準のセットを読むことを強くお勧めします。 私たちは新しい領域にいません。

また、このスレッドでは、キー管理と暗号化という2つの問題を効果的に混同していることも指摘しておく必要があります。

おそらく、そこで混乱が生じます。

たぶん、この問題は次のようなドキュメントで解決できます。

パスワードでリポジトリを保護したくない場合は、次の文字列を使用してください： 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がユーザー提供のパスワードに加えてデフォルトのパスワードを使用した場合に発生します。 私の提案は、復号化時に1つのパスワードを試すことです。 ユーザーは引き続きこの不正なパスワードを積極的に選択します。

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、または実際に世界的に認められている標準のセットを読むことを強くお勧めします。 私たちは新しい領域にいません。

At-rest-encryptionは、resticがそれを行う必要があることを意味するものではありません。 追加専用ストレージは、必要に応じて他の方法で暗号化できます。 それでも、パスワード専用であっても、暗号化されていないストレージがいくつかあります。 そうでなければ、バックアップの概念は、誰かが常にパスワードを覚えていることに依存するでしょう。

このスレッドからの退会...

これのままにしておきましょう。 --no-passwordオプションをinitにしたいと思う人がいることは明らかです。これが、この問題のすべてです。 暗号化かどうかは別の問題です。

ここに簡単なコメント：
私は暗号化を気にしないユーザーです。 私のデータには何の機密もありません。 私ではない人が20〜40年で使えるようになることを気にしています。 rcloneを使用するだけでも、もう1つの方法は不十分です。

Resticは、暗号化とパスワードを義務付けることはそれを考慮に入れる必要があることを意味することを除いて、これには良いツールのように見えます。 たぶん、バックアップリポジトリのREADME。 それはより多くの作業であり、（私の側からの）どんな解決策もとにかくどんな暗号化も打ち負かします。

マーク

たくさんのご協力ありがとうございました。十分な情報を収集できたと思います。