状況 1 - サーバーをデータベースに接続する
ここには簡単な答えはありません。接続するために、サーバーはパスワード (または対称鍵、秘密鍵など) を必要とします。ディスクまたは何らかの外部手段 (管理者が起動時に入力するなど) から取得する必要があります。すべての機密情報をマスター パスワードで暗号化するなど、何らかの間接化を追加すると、利便性が向上しますが、状況は変わりません。
通常、サーバー上のファイルにパスワードまたはキーを配置しても問題ありません。これを行う場合は、必要なユーザーのみがアクセスできるように、ファイルのアクセス許可を設定してください。これは、システム上のさまざまなプロセスをさまざまなユーザーとして実行し、それぞれに個別の役割/アカウントとパスワードを設定する優れた理由です。
状況 2 - ユーザーがリモート コンピューターからサーバーにログインしている
あなたはここで正しい方向に向かっていると思います。あなたが求めているように聞こえるのは、安全な認証プロトコルです。相互認証を提供し、中間者攻撃が試みられた場合に失敗することで中間者攻撃を防ぐものが必要です。もちろん、たくさんの選択肢があります。
また、認証が「知っていること」(パスワード) に基づいて動作するか、「持っているもの」(公開鍵/秘密鍵) に基づいて動作するかを検討する価値があります。あなたの質問に基づいて、私たちが探しているのはパスワードであると仮定すると、私が気に入っているのは SRP と Kerberos の 2 つです。
SRP については前述しましたが、十分な注目を集めていません。SRP には、サーバーがパスワード、キー、または攻撃者がアクセスするために使用できるものを知る必要がないという利点があります。SRP を使用して正しく構成されたサーバーに侵入し、すべてのデータを盗んだ場合でも、ユーザーになりすますために使用できるものを得る前に、各キーに対して個別に辞書攻撃のようなことを行う必要があります。
また、Kerberos は多くのソフトウェアでサポートされているため (Postgres がサポートしていることは知っていますが、mysql が適切な認証テクノロジをサポートしていないという言及しか見つかりませんでした)、シングル サインオン機能を提供する「チケット」のシステムを備えているため、Kerberos も気に入っています。Kerberos には、最初の認証交換を強化するのに役立つ他のテクノロジが必要であり、SRP はそのために最適ですが、まだそれを行っているかどうかはわかりません。KDC（キーサーバー）をステートフルにすることについての何かだと思います。
Kerberos の弱点は、サーバーが鍵を保管することにもっと注意を払わなければならないことです。パスワードはプレーンテキストで保存されませんが、基本的にパスワードのハッシュ バージョンであるキーが保存されます。また、クライアントは認証時にパスワードまたはキーのいずれかを正確に送信するわけではありませんが (これは結局のところ、本物の認証プロトコルです)、ハッシュ化されたパスワードをキーとして使用するため、アルゴリズムを知っていて知っている人なら誰でもキーも同じことができます。サーバーは「同等のパスワード」を保存すると言います。その結果、すべてのマニュアルは、管理者に kerberos サービスを個別のロックダウンされたボックスに配置して、コンテンツが危険にさらされる可能性を最小限に抑えるように指示しています.
良い点は、一度強力な認証交換に落ち着くと、通常、他の良いことが無料でなくなることです. 最終的には、セッション中に一度だけ使用でき、ネットワーク経由で送信されることはなく、第三者に知られることのない相互の「秘密」を共有することになります。暗号化が必要ですか? 鍵があります。準備万端です。これは、SRP で保護された SSL が RFC 5054 で定義されている方法とまったく同じです。