0

Webサービスを実装しようとしていますが、サービスへのアクセスを制限するために、いくつかの（非常に）単純な認証が必要です。

私はHMACについて知り、それを実装する方法を理解していると思います。しかし、私はいくつかの質問を念頭に置いています。

消費者側にこのHTMLフォームがあるとしましょう。サーバーにGET/POSTリクエストを送信するとき。

  1. public_keyのハッシュを作成するには十分secret_keyですか？
  2. POSTまたは、変数/配列全体のハッシュを作成する必要がありますか？

唯一のハッシュを送信するだけで十分だと思いますが、public_key確認して皆さんに聞いてみたかっただけです。

私はこれを行うことを計画しています：

  1. のハッシュを作成しますpublic_key
  2. ハッシュを非表示フィールドまたはURLに、public_key（またはclient_id）およびその他のPOST/GET変数と一緒にパラメーターとして配置します。
  3. public_keyサーバーで受信し、を使用してのハッシュを再作成することにより、データベースに対してハッシュを検証しますsecret_key。
  4. ハッシュが一致する場合、POST/GETリクエストを受け入れます。

あなたの考え？

明確化： サーバー上でハッシュを生成するために何を使用するかを識別するために使用できる場所public_keyのようなものです。client unique idsecret key

4

2 に答える 2

6

公開鍵は、ユーザーを認識するための代替手段としてのみ使用されます。ところで、ユーザー データをプログラマー (または潜在的な盗聴者) に公開したくない可能性が高いため、ユーザーごとに一意の識別子を作成します。それが意味するすべてです。次に、ハッシュに署名するための秘密鍵が必要です。

もちろん、価値のあるものにするためには、すべての一意のリクエスト データに署名する必要があります。そうしないと、誰かがリクエストの本文を変更して、それを検出できなくなります (MITM 攻撃)。

また、HMAC 自体に含める必要があるタイムスタンプを作成し、それをリクエストと一緒に渡す必要があります。このようにして、署名を期限切れにすることができるため、リプレイ攻撃にさらされることはありません（誰かがリクエストを盗み、変更せずにサーバーに対して返信し、同じアクションを複数回実行します...あなたのサービスにお金を払えば、あなたのユーザーはあなたに非常に腹を立てるでしょう）。

また、RESTful Web サービスを使用している場合は、HMAC 自体と HTTP メソッド (別名動詞) 内の Request-URI も暗号化することを忘れないでください (誰もしません)。そうしないと、悪意のあるユーザーが他の URI に要求を送信したり ( RESTful サービスを使用すると) リクエストの意味が変わるため、有効な GET が潜在的な DELETE になる可能性があります。例としては、ユーザーがすべてのデータを表示する必要があり、GET 要求を行い、中間者が要求を読み取り、GET を DELETE で変更します。チェックできる HMAC 内にない場合、何かが変更されたことを検出する機会が与えられないため、DELETE 要求を受け取り、ブームが発生します。すべてのユーザー データを破棄します。

したがって、常に覚えておいてください: リクエストに不可欠なものはすべて有効である必要があります。 また、HMAC に依存している場合は、リクエストを信頼するために必要なものすべてを暗号化する必要があります。

また、すべてのリクエストを拒否することからシステムの設計を開始することを常に忘れないでください。その後、それらを検証できる場合は、リクエストされたアクションを実行してください。このようにして、拒否されたリクエストに常にフォールバックします。あなたのユーザーデータがネット上に広がるようなことはできないということを、ユーザーにメールで知らせてもらう方がよいでしょう。

于 2012-10-15T21:30:42.260 に答える
2

TLSを使用します。これと、まだ考えもしなかった多くの問題を修正します。

于 2012-07-12T03:43:08.683 に答える