4

多くの外部システム API と対話するシステムに取り組んでいます。それらのほとんどは、何らかの認証を必要とします。使いやすさのために、構成情報と外部システムの資格情報を格納する「アプリケーション全体で到達可能な」AppConfig があります。

私の質問は、ユーザー名とパスワードを (平文で) 外部システムのアプリケーション構成ファイルに保存するのは悪い考えかということです。もしそうなら、どうやってそれを避けますか？

構成ファイルにアクセスするには、サーバーのファイル システムを侵害するか、別のサーバー (またはもちろん開発者のシステム) の git リポジトリを侵害する必要があります。暗号化キーもどこかに保存する必要があるため、構成ファイルでパスワードを暗号化してもセキュリティレベルは向上しないと考えています。私はこれについて間違っていますか？

この問題をどのように解決したかを説明する回答をいただければ幸いです。

解決

わかりましたので、これが私の最終的な解決策です。OpenSSL を使用して機密データを暗号化および復号化する単純なライブラリを作成しました。キーは、構成が読み込まれるときにユーザーから取得されます。ただし、キーがファイルに格納されている運用サーバーは除きます。それはまだ最適な解決策ではありませんが、私が以前に持っていた「解決策」よりもはるかに優れています.

回答ありがとうございます。それが最も有益だったので、ウェインの答えを受け入れます。

4

3 に答える 3

5

優れたセキュリティは難しいです。

Bruce Schneier が言うように、「セキュリティはトレードオフです」。この情報をどの程度安全にするか、およびその情報を保護するためにどれだけの時間を費やすかを決定する必要があります。また、パスワードを平文のままにしておくのは絶対に避けたいことです。それが問題ない状況にある場合は、ユーザー認証を行うべきではない状況にあります。

セキュリティは難しいですが、できることはいくつかあります。

1) ある種のコンパイル済みプログラムを使用して、暗号化/復号化を行います。誰かが Python/perl スクリプトを開いて「ああ、これは単純な XYZ 暗号化です」と言うのは望ましくありませんが、理想的には単純な暗号化は必要ありません。

2) 隠蔽によるセキュリティは本当のセキュリティではありませんが、カジュアルな詮索を防ぐのに役立ちます。たとえば、ファイルに「passwords.txt」という名前を付けることはあまり良い考えではありませんが、パスワードを暗号化し、ステガノグラフィーを使用して画像ファイルのユーザー/パスを非表示にすることをお勧めします。

3) 強力な暗号化/復号化アルゴリズムを調べます。それらのいくつかは、ほとんどの言語で既に実装されており、ライブラリをインポートするだけで済みます。これは、どれだけ安全だと思うかによって、良くも悪くもなります。

しかし、正直なところ、このシステムはセキュリティ面で非常に悪いです。理想的には、二者認証を行い、信頼できる仲介者がすべての操作と取引を行います。たとえば、コンピューターにログオンするときは、自分が承認されたユーザーであることをコンピューターに伝えていることになります。そこからすべてのプログラムを実行できるようになり、ユーザーとパスの組み合わせを尋ねたり気にしたりすることはありません。あなたが許可されたユーザーであるというだけです。この情報は OS (仲介者) から取得します。SO でさえ openID を使用して、あなたが信頼できるユーザーであるかどうかを判断します。彼らは、他のサイトであなたの資格情報が何であるかを気にしません。他のサイトが「はい、これは有効なユーザーです」と言うだけです。

オプションがある場合は、認証モデルを切り替えることを真剣に検討します. そうでない場合は、頑張ってください。

于 2010-06-23T13:14:39.637 に答える
1

実際の例について言えば、Web サーバーはデータベース ログインの詳細をサーバー上にプレーン テキストで保存します。誰かがあなたのサーバーにアクセスした場合、とにかくあなたはめちゃくちゃです。しかし、これらのパスワードを望ましくない日和見的な侵入者から保護することは、個人的には、より安全に感じるために余分なレイヤーが好きです. 申し訳ありませんが安全ですよね？

これらのパスワードは外部システム用であるため、別のレイヤーである暗号化で保護することが賢明です。はい、あいまいさによるセキュリティは悪いですが、誰かがそれらに出くわした場合、それは優れた抑止力として機能するとは思いませんか.

1024 ビットの暗号化を使用することをお勧めします。いくつかの優れたアルゴリズムがあります。また、暗号化するすべてのエントリに64/128 ビットのランダム ソルトを使用することをお勧めします。これにより、1 つのエントリのパスワードがブルート フォースされたとしても、ソリューションは他のエントリでは機能しません。ランダム ソルティングは、クラッカーがブルート フォースを使用することを強いるレインボー テーブル攻撃を防ぎ、はるかに時間がかかります。

はい、これらの予防措置は偏執狂のように見えますが、自分のパスワードをクラックしようとすると (もちろん、研究目的で)、悪意のある人が何を試みるか想像できます。

編集： 暗号化キーがわかっている場合でも、ソルトが暗号化をより安全にする方法の例。

于 2010-06-23T13:57:14.427 に答える