3

最近セキュリティ監査を実施したところ、ここにあるシステムのいくつかの弱点が明らかになりました。その結果生じたタスクの 1 つは、パートナー資格情報システムを更新してより安全にする必要があるということです。

「古い」やり方では、(悪い) パスワードを生成し、それを ID とともにパートナーに渡し、パートナーはその ID とそのパスワードの Base 64 でエンコードされたコピーを、すべての XML 要求と共に https 経由で送信していました。 . 次に、それらをデコードして検証します。

これらのパスワードは変更されません (その場合、パートナーはそれらを変更するためにコーディング/構成の変更を行う必要があり、複数の環境で何百ものパートナーとパスワードの有効期限を調整するのは悪夢になるため)、人間がパスワードを入力する必要はありません。または人間が読める形式。私たちのパートナーにとってより良いが比較的単純な実装があれば、私はこれを変更することにオープンです.

基本的には、Java パスワード生成システムをより安全にする必要があることと、それらが安全な方法で送信されるようにすることの 2 つに帰着します。

手巻きのパスワードジェネレーターをいくつか見つけましたが、これを行うための標準的な方法として本当に目立ったものはありませんでした (おそらく正当な理由による)。また、https を介した単純な Base 64 エンコーディングよりも安全な方法で送信することもできます。

パスワードジェネレーターに対して何をしますか? また、現在の送信方法は十分に安全だと思いますか?

編集: XML は SOAP メッセージに含まれており、資格情報は XML 自体ではなくヘッダーにあります。また、パスワードは設定時にパートナーごとに 1 回限りの操作であるため、ジェネレーターの効率についてはあまり心配していません。

4

3 に答える 3

6

パスワード生成

送信用のパスワードをエンコードする限り、真にセキュリティを強化する唯一のエンコードは暗号化です。Base-64 または 16 進数を使用するのはセキュリティのためではなく、XML のようなテキスト形式に含めることができるようにするためです。

エントロピーは、パスワードの品質を測定するために使用されます。そのため、ランダムな「コイン フリップ」で各ビットを選択すると、最高品質のパスワードが得られます。パスワードを他の暗号化キーと同じくらい強力にする必要があるため、最低でも 128 ビットのエントロピーをお勧めします。

パスワードをテキストとしてエンコードする方法に応じて、2 つの簡単な方法があります (これは、セキュリティの観点からは重要ではありません)。

Base-64の場合、次のようなものを使用します。

  SecureRandom rnd = new SecureRandom();
  /* Byte array length is multiple of LCM(log2(64), 8) / 8 = 3. */
  byte[] password = new byte[18];
  rnd.nextBytes(password);
  String encoded = Base64.encode(password);

以下では、Base-64 エンコーダを用意する必要はありません。結果のエンコーディングはそれほどコンパクトではなく (24 文字ではなく 26 文字)、パスワードのエントロピーはそれほど多くありません。(しかし、130 ビットは既に大量であり、人間が選択した少なくとも 30 文字のパスワードに匹敵します。)

SecureRandom rnd = new SecureRandom();
/* Bit length is multiple of log2(32) = 5. */
String encoded = new BigInteger(130, rnd).toString(32);

新しい SecureRandom オブジェクトの作成には計算コストがかかるため、パスワードを頻繁に生成する場合は、インスタンスを 1 つ作成して保持することをお勧めします。

より良いアプローチ

XML 自体にパスワードを埋め込むのは間違いのようです。

まず第一に、送信されたドキュメントを処理する前に、送信者を認証したいようです。私があなたの根性を嫌い、サービス拒否攻撃を実行するために巨大な XML ファイルを送信し始めたとします。私が正当なパートナーではないことを確認するためだけに XML を解析する必要がありますか? サーブレットが認証されていないユーザーからの要求を最初から拒否した方がよいのではないでしょうか?

第 2 に、正当なパートナーのパスワードは、送信中は HTTPS によって保護されていましたが、現在はシステムのどこかに「平文で」保存されている可能性があります。それは治安が悪い。

より良いアプローチは、パートナーが HTTP 要求ヘッダーに資格情報を含むドキュメントを送信するときにパートナーを認証することです。HTTPS のみを許可する場合は、ドキュメントからパスワードを完全に取り除き、代わりにHTTP の「基本」認証ヘッダーに入れることができます。送信中は SSL によって保護され、システムに平文で保存されることはありません (認証のために一方向ハッシュのみを保存します)。

HTTP 基本認証はシンプルで広くサポートされており、SSL クライアント証明書よりも実装がはるかに簡単です。

ドキュメント コンテンツの保護

ドキュメント自体の内容が機密性の高いものである場合は、送信者が暗号化し、暗号化された形式で保存する必要があります。これを行う最善の方法は、公開鍵暗号を使用することですが、それは別の質問の主題になります。

于 2008-09-19T17:11:02.067 に答える
0

パスワードのアプローチ全体を放棄し、クライアント証明書の使用を開始して、両面認証 SSL 接続を許可します。

クライアントごとに個別の証明書を生成して署名する必要があります。SSL ハンドシェイクでは、クライアントの証明書を要求して検証します。失敗した場合、接続は 401 ステータス コードで終了します。

証明書はいつでも取り消すことができるため、以前の顧客との関係を簡単に断ち切ることができます。

これはすべて通信前のハンドシェイクで発生するため、サーバーにデータをあふれさせることはできません。

于 2008-09-24T15:24:23.983 に答える
0

SSL 経由 (HTTPS 経由) でパスワードを送信することが、監査チームによって「安全ではない」と見なされている理由がわかりません。したがって、2 つのことを要求すると、2 つ目 (パスワードが安全な方法で送信されるようにすること) は、既に問題なく処理されているように見えます。

1つ目として、監査でパスワードが安全でないと暴露された理由を知る必要があります...

于 2008-09-19T16:51:54.267 に答える