（注：私はセキュリティの専門家ではありません。この分野に関心がありますが、それだけです。覚えておいてください。）
可能であれば、パスワードは一切保存しないでください
それはあなたのニーズが何であるかに大きく依存します。すべての最良のオプションは、双方向暗号化をまったく使用しないことです。 塩漬け
のみを保存できる場合 および
さらに良いことに、クライアントが適切なプロトコルを使用している場合（つまり、一般的に実装されているHTTPではない場合）、チャレンジレスポンス認証メカニズム つまり、アプリは決して ユーザーを認証する場合でも、ユーザーのパスワードを確認する必要があります。悲しいことに、これは、80年代のプログラマーを恥じさせるセキュリティを備えたパブリックWebではめったに不可能です。
パスワードを保存する必要がある場合は、アプリからキーを分離します
パスワードを復号化できる必要がある場合は、理想的には、復号化するためのすべての詳細を1か所にまとめる必要はなく、コピー可能で簡単にアクセスできる1か所にまとめることはできません。
そのため、私は個人的にこの目的でPgCryptoを使用しないことを好みます。これは、秘密鍵と（ある場合は）パスフレーズをサーバーに公開することを強制するためです。サーバーでは、PostgreSQLで公開される可能性があります。ログファイルまたはその他の方法で盗聴される可能性があります。コードがキーにアクセスできなくてもデータを復号化できるPKCS＃11、キーエージェント、またはその他のツールを使用できる暗号クライアント側を実行したいと思います。
安全なキーストレージの問題は、 PKCS＃11 の一部です。 のために発明されました。これは、アプリケーションと暗号化プロバイダーが、キーを明らかにすることなく、特定の署名および復号化サービスを提供できるものと通信するための汎用インターフェースを提供します。 。通常の使用は、スマートカードやハードウェア暗号モジュールなどのハードウェアベースの暗号で行われます。このようなデバイスは、渡されたデータに署名または復号化するように指示でき、キーを公開することなく実行できます。可能であれば、スマートカードまたはHSMの使用を検討してください。私の知る限り、PgCryptoはPKCS＃11やその他のHSM/スマートカードを使用できません。
それができない場合でも、おそらくキー管理エージェントを使用できます。サーバーの起動時にキーをキー管理プログラムに手動でロードし、キー管理プログラムがPKCS＃11（またはその他の）インターフェイスを提供します。ソケットを介した署名と復号化用。そうすれば、Webアプリがキーをまったく知る必要がなくなります。 gpg-agent この目的の対象となる場合があります。繰り返しになりますが、私が知る限り、PgCryptoはキー管理エージェントを使用できませんが、追加するのは素晴らしい機能です。
少しでも改善することができます。キーのパスフレーズがディスクに保存されていない場合に最適です。そのため、キーを復号化できるように、アプリの起動時にパスワードを入力する必要がある場合があります。復号化されたキーはまだメモリに保存されていますが、復号化するためのすべての詳細はディスク上になく、簡単に入手できます。攻撃者がメモリから復号化されたキーを盗むことは、ディスクから「password.txt」を取得することよりもはるかに困難です。
何を選択するかは、セキュリティのニーズの詳細と使用しているデータに大きく依存します。あなたの立場では、可能な限りパスワードを保存しません。必要な場合は、PKCS＃11互換のハードウェアデバイスを使用したいと思います。