16

私たちは新しいプロジェクトに取り組んでおり、私たちは 2 人の主任開発者であり、トークンを使用してサーバーとクライアント間の通信を保護する方法について岐路に立っています。

最初の提案:

ステップ 1) クライアントは、ユーザー名とパスワード、および current_time (この変数はサーバーのデータベースとクライアント側にも保存されます) を API に送信することにより、プライマリ トークンを要求し、サーバーは入力を解釈し、ハッシュされたトークンをレンダリングします。 (例: 58f52c075aca5d3e07869598c4d66648) データベースに保存し、クライアントに返します。

ステップ 2) クライアントはプライマリ トークンを保存し、プライマリ トークン + 認証要求で送信された current_time 変数を使用して新しいハッシュ トークンを作成します (この新しいトークンを main_token と呼びます)。サーバーも同じことを行い、次を使用して同じトークンを作成します。同じアルゴリズム。

ステップ 3) クライアントがサーバー API にクエリを実行するたびに、main_token がサーバーに送信されます。サーバーは、生成されたトークンとクライアントから送信された main_token を比較し、一致する場合、ユーザーが本物であることを意味します。

2番目の提案:

ステップ 1) クライアントは 2 つのランダム キーを生成します ($key1 = rand(10000,90000); $key2 = rand(10000,90000);) API での各リクエストで、クライアントはクエリ タイプを使用してハッシュを作成し、複雑なアルゴリズムを使用して 2 つのキーを作成し、これら 2 つのキー + ハッシュをサーバーに送信します。

ステップ 2) サーバーは、クライアントで使用されているものと同じアルゴリズムを使用してハッシュを作成し、クライアントから送信されたものと比較します。一致する場合、サーバーはクエリの処理に進みます。

さて、問題は、API リクエストを保護するために使用する最も論理的で安全な方法はどれかということです

よろしくお願いします

4

4 に答える 4

12

どちらのソリューションもセキュリティには何のメリットもありません。

最初の提案

main_token を取得したら、任意のハッシュ (main_token + タイムスタンプ) を計算できます。API にアクセスするために必要なのは main_token だけです。

2番目の提案

各リクエストとクエリ タイプで 2 つの乱数を送信する場合、私が同じことをして API を使用するのを妨げているのは何ですか? アルゴリズム？暗号化アルゴリズムのルールは、自分でロールすると、誰かが解読するというものです。2番目のルールは、あいまいさによるセキュリティが機能しないことです。

認証プロセスが API よりも安全である場合は、別の方法で呼び出しを保護できます。

認証フェーズ (SSL)

  1. クライアントはユーザー/パスワードを送信し、ランダムな文字列である「Secret_token」を取得します。
  2. Secret_token は、クライアント側とサーバー側に保存されます。
  3. Secret_token が再びネットワーク経由で転送されることはありません。

API リクエスト フェーズ

  1. クライアントがリクエストを作成します
  2. クライアントはリクエストを正規化します
  3. クライアントは、Secret_token を使用して正規化されたリクエストの署名* を計算します
  4. クライアントはリクエストと署名をサーバーに送信します
  5. サーバーはリクエストを正規化します
  6. サーバーは Secret_token を使用して正規化されたリクエストの署名を計算します
  7. 署名が一致する場合、サーバーはリクエストを続行します

署名を計算する

まず、リクエストを正規化します。これは、メソッド (post、get、action、timestamp) を含む重要なパラメーターを抽出し、それらを整理することを意味する場合があります。次に、Secret_token をパラメーターとして受け取る HMAC アルゴリズムを介してその文字列を実行します。

分析

Secret_token は、認証が発生したときに 1 回だけネットワーク経由で転送されます。認証プロセスは非常に安全であると想定されています (このプロセス中にパスワードが転送されるため、安全な想定です)。

注: 平文で送信するのはまだ安全ではありません。SSL を使用してください。

HMAC はよく知られたソリューションです。見る：

于 2013-07-28T19:13:02.110 に答える
7

すべてのリクエストで標準のHTTP Authを使用しないのはなぜですか。そのため、毎回ユーザー名とパスワードを通過することになります。次に、サーバーは、トークンではなく、そのユーザー名とパスワードの組み合わせに対して検証しています。

接続に SSL/TLS を使用しているため、ユーザー名/パスワードが公開されるリスクはありません。また、SSL ではリプレイ攻撃の可能性がないため、期限切れにする必要はありません。

シンプルに保ち、すでに開発されている既存のプロトコルを使用することをお勧めします。セキュリティに関して言えば、やむを得ない理由がない限り、一からやり直そうとするべきではありません。

于 2013-07-21T22:57:23.470 に答える
5

最初のいくつかの観察

  1. 最初のアプローチでは、トークンは本質的に長寿命のパスワードになります。すべてのリクエストで再利用されます。したがって、このトークンが侵害された場合は、完了です。OAuth 2 はまさにそれを行うので、それはお勧めできませんが、ここでは SSL が絶対に必須です。また、これを行う場合は、トークンに有効期限があり、妥協があった場合にトークンを迅速に取り消すメカニズムを確保する必要があります。

  2. あなたが説明する2番目のオプションは、AWSが使用するものに似ていますが、秘密鍵はありません. ここでの利点は、クエリを使用してハッシュを生成するため、リクエストごとにハッシュが変化することです。したがって、1 つのトークンが侵害された場合、他の要求では機能しないため、心配する必要はありません。さらに、このアプローチでは、コンテンツが変更された場合にアルゴリズムが不一致のハッシュを生成するため、中間者攻撃を常に検出できます。

どちらのアプローチも有効で、広く使用されています。そのため、SSL が必要ない場合は 2 が適しています。SSL に問題がなければ、OAuth も別のオプションです。私がお勧めするのは、どちらかで確立された手法を実際に使用することです。1) を使用している場合は Oauth2 を調べ、2) を使用している場合は AWS スキームを使用してください (厳密に言えば、これは標準ではありませんが、広く文書化されています)。

役立つと思われるいくつかのリンク

http://www.wolfe.id.au/2012/10/20/what-is-hmac-and-why-is-it-useful/

http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

http://blog.cloudfoundry.com/2012/10/09/securing-restful-web-services-with-oauth2/

于 2013-07-22T16:31:43.427 に答える
0

クライアントは最初の提案で 2 番目のトークンを計算するために必要なすべての情報を持っているため、2 番目のトークンは最初のトークンより優れている (より安全で安全である) わけではありません。2 番目の提案は、事前共有キーのバリエーションのようです。これらのいずれかが適切なセキュリティ対策になる可能性があります。個人的には、最初のアプローチに似たアプローチを好み、常に SSL を使用します。トークンはユーザー名とパスワードの代わりのようなものだと考えてください。リクエストごとにトークンのクリアテキストを送信しますか? (多くのサイトはまさにこれを行っています。)

于 2013-07-18T22:59:02.070 に答える