SMTP が認証を必要としないことを指摘するコメントは正しいです。とはいえ、指定した3 つのオプションはすべて、サーバーがコモディティ ハードウェアとソフトウェアを使用していると仮定すると、安全ではありません。元の命令には従いませんが、それぞれが安全でない理由を示します。
2) パスワードを読み取ることができるサーバー上のファイル
3) MySQL データベースのどこか。
誰かがサーバーを盗んだ場合はどうなりますか? 次に、ファイルまたはデータベースを開いてパスワードを読み取るだけで、社内のすべての重要な情報にすぐにアクセスできます。そのため、昼夜を問わずサーバーを武装した警備員が取り囲んでいない限り、これはすでにかなり安全ではありません.
しかし、それは悪化します。攻撃に対して完全に無防備なコンピューター システムはありません。過去数年間に広く公表されたいくつかの攻撃 (たとえば、Sony の PlayStation Network) では、攻撃者が物理的なアクセスなしにディスク ファイルやデータベースの内容にアクセスできることが示されています。さらに、あなたの質問から、問題のサーバーは外界からのパケット (HTTP 要求、受信メールなど) を受け入れるように意図されているように思われ、それが攻撃面を後押しします。
1) パスワードをプログラムのメモリ、つまり非公開の最終文字列フィールドに保存します。
これは魅力的ですが、オプション 2 やオプション 3 よりもさらに悪質です。たとえば、Java コンパイラによって生成された .class ファイルにプライベートの最終文字列フィールドが格納されるため、このオプションを使用すると、暗号化されていないパスワードが既に格納されています。サーバーのハードドライブ上。オプション 2 または 3 のようにサーバーを侵害した後、攻撃者javapは .class ファイルからプレーンテキストのパスワードを取得するために実行できます。
ただし、このアプローチにより、攻撃対象領域がさらに広がります。パスワードがソース コードの一部として保存されている場合、コードに取り組んでいるすべての開発者が突然パスワードを利用できるようになります。最小特権の原則の下では、開発者は余分なパスワードを知ってはいけません。これには非常に正当な理由があります。開発者のマシンのいずれかが外部から盗まれたり侵害されたりした場合、攻撃者は侵害されたマシンのハード ドライブを調べて、平文のパスワードを取得できます。次に、ソース管理です。ソース管理の非常に重要な利点の 1 つは、コードの以前のバージョンを検査できることです。したがって、将来的に安全な方法に切り替えたとしても、パスワードがソース管理に入ったことがある場合、ソース管理サーバーは潜在的な攻撃ポイントになります。
これらすべての要因を総合すると、たとえ HTTP/メール サーバーのセキュリティが一流であっても、オプション 1 では攻撃面が非常に大きくなり、HTTP/メール サーバーのセキュリティは実際には役に立たないことがわかります。
追加の詳細: 冒頭で、「サーバーが市販のハードウェアとソフトウェアを使用していると仮定して」指定しました。市販のハードウェアとソフトウェアを使用していない場合は、読み取り専用ストレージから起動し、暗号化されたデータベースのみを使用して、起動のたびに復号化キーを提供する必要があるなどのことを行うことができます。その後、復号化された情報はメモリにのみ存在し、ディスクに書き込まれることはありません。このようにして、サーバーが盗まれた場合、攻撃者はサーバーのプラグを抜く必要があるため、これまでメモリにしか存在しなかった復号化された情報がすべて失われます。この種のセットアップは、Kerberos KDC (セキュリティを強化するためにサーバーをロックされたボックスに入れる) に使用されることがありますが、それ以外ではめったに使用されません。費用。