GPG暗号化ファイルにパスワードを保存するリスクは何ですか？
現在、パスワードはGPG -eを使用して暗号化されたテキストファイルに保存しています（自分の公開キーを指定）。パスワードを検索したいときは、次のようにします
gpg -d passwords.gpg | grep <sitename> | less
新しいパスワードを追加する場合は、ファイルを復号化し、ファイルを編集してから、もう一度暗号化します。
この戦略の潜在的なリスクは何ですか？ Password Safe のようなものを使用する場合と比較して、これを行うことにはセキュリティ上の問題がありますか？
最大の問題はシステムの侵害です。強力なパスフレーズで暗号化されたキーを保存する場合、これはパスワードマネージャーのリスクに相当します（実際には this が何らかの兆候である場合、多くのパスワードマネージャーは暗号化キーをマスターパスワードを正しく設定するため、おそらくgpgを使用するほうがよいでしょう）。したがって、誰かがあなたのシステムをルートし、あなたがあなたのキーをアンロックした場合、彼らはあなたのすべてのパスワードを持っています。これは、システムで実行されているパスワードマネージャと同じです。
ただし、gpgキーを暗号化しない場合、システムにアクセスできれば（たとえそれを盗んだとしても）誰でもあなたのキーを読み取ったり、ファイルを復号化したり、パスワードを取得したりできます。これは、優れたパスワードマネージャー（LastPass、KeePass、OSXキーチェーンなど）よりも劣ります。
2番目に大きなリスクは、Shellコマンドがtmpファイルを削除してもシステムに書き込むことです（ファイルを削除してもデータは上書きされず、ソフトウェアで復元できるため）。 GPGは一時ファイルを書き込み、grepは一時ファイルを書き込み、lessは一時ファイルを書き込みます。シェルのように。さらに、これらの最後の3つは安全であることを意図していないため、将来のある時点でそうしないと決定する理由はありません。一方、まともなパスワードマネージャーは、ディスクにクリアテキストを決して書き込まないようにするための措置を講じます。ディスクにスワップされないロックされたページにのみデータを保存することもできます。
純粋に暗号化の側面では、gpgでの最大キーサイズはおそらく2048ビットです。これにより、最大112ビットのセキュリティが得られます。 AES256と同等のものを取得するには、 15360ビットキー が必要です。これはあなたの心配事の少なくともですが、それでも1つです。パスワードマネージャーは通常、対称暗号を使用するため、AES128またはAES256を使用できます。
他の回答の警告に加えて、復号化-編集-暗号化サイクルは、編集が完了した後もプレーンテキストのトレースを残すことができます。専用のパスワードセーフソフトウェアと他のユーザーによるファイルの安全な編集の試みは、多くの潜在的なリスクを指摘しています。
- エディターの一時/保存/バックアップファイル
- エディターの最近のファイル履歴、コマンド履歴、カットアンドペースト履歴
- 暗号化されていないスワップパーティションに、または休止状態中に書き出されたエディターまたはその他のメモリ
- データの安全でない削除（shred（1）などで上書きされない）
- 「削除された」データを保持するジャーナリングまたはコピーオンライトファイルシステム
- 転送中にデータをキャッチするバックアップ
- クリップボードがクリアされていないか、履歴が保持されています
- 編集後の画面クリア
- tmux/screen/remote desktop/x/over-shoulder security
- SSDのデータ処理は複雑です
他の多くの潜在的な懸念があることは間違いありません。私はまだそれらを通常の不格好なパスワードセーフソフトウェアと比較して比較検討しています。プレーンテキストファイルをディスクに書き込まないgpg-vimの組み合わせは有望なようです。または、編集中にプレーンテキストファイルの下の暗号化されたファイルシステムレイヤーを使用するだけでも十分な場合があります。
私はこの正確な手法を何年も使ってきました。 1つの大きなリスクは、復号化>編集>暗号化の後にクリアテキストファイルを削除し忘れた場合です。 GPGを使用すると、暗号化によってクリアテキストファイルがそのまま残ります。さらに悪いのは、自動バックアップ中にクリアテキストファイルをそこに残しておくことです。次に、バックアップされたファイルを見つけて削除する必要があります。