3

ストレートHTML5とWebAPIRESTfulサービスを使用して新しいasp.netWebAPIアプリケーションを構築しています。すでにフォーム認証と[Authorize]属性を使用して、WebAPI呼び出しを保護しています。私は、安らかな原則にできる限り忠実であり続けようとしています。

2要素認証を使用し、asp.netWebフォームを使用する既存のアプリの機能を模倣しています。二要素認証は、ログインには使用されませんが、サイトとプラグインを介して別のマシンにリモート接続するという追加のタスクに使用されます。

既存のWebアプリケーションは、セッション状態を使用して、生成されてユーザーに電子メールで送信されるピンを格納します。次に、ユーザーがPINを入力すると、セッション状態のPINと照合されます。

だから私の選択肢は...

  1. サーバーで生成されたピンを暗号化し、JavaScriptでクライアントに送り返します。このオプションはセキュリティリスクのようです。これは、より安らかなオプションになります。
  2. 同僚は、AmazonS3が公開鍵と秘密鍵のペアを使用して行うようなものを使用することを提案しました。
  3. Web APIを使用しているにもかかわらず、セッション状態を使用します。

では、これらのオプションのうち、最良のオプションは何ですか？他の可能性はありますか？

4

2 に答える 2

1

私はあなたのアーキテクチャを 100% 理解しているとは言えませんが、セキュリティが決してクライアントに依存してはならないということは非常に重要なようです。

ユーザーのブラウザーに JavaScript デバッガーがあり (ほとんどの人は実際には気づかずに行っています)、プラグインのカスタム ビルドを使用しているとします。

したがって、セカンダリ PIN チャレンジは、サーバー側で「リモーティング」プロトコルに埋め込む必要があります。RDP または VNC に基づくものであれば、特定のユーザーの接続パスワードをオンザフライで 1 回限り生成される PIN に変更できるはずです。

于 2013-01-08T11:46:35.463 に答える
0

私は信じています、あなたはRESTfulの原則にあまり注意を払うべきではありません（待ってください、私はそれを言いましたか？:)）...ほら、一方は理論であり、もう一方は実践です。実際には、セキュリティのためにRESTfulの原則を破る必要があることがよくあります。考えてみましょうnonce。これは、リクエストごとに生成される大きな乱数であり、nonce以前に送信されたことがない場合は、サーバーでチェックされます。これには、状態（ナンス）の保存が含まれます。つまり、ステートレスではありませんが、セキュリティにとって重要な場合があります。また、ちなみに、よく使われるOAuthはRESTfulではありません。

PINを暗号化するには、JavaScriptクライアントを使用しないでください。ただし、JavaScriptクライアントが使用されているドメインにある種の暗号化エンドポイントを実装できます。

  1. を使用XMLHTTPRequestして、エンドポイントURLへのリクエストを生成します（例：）/api/encrypt。
  2. サーバーはこの要求を受け取り、サーバー上のPINを暗号化します。つまり、PINはクリアな状態でブラウザーに入りません。
  3. サーバーは暗号化されたPINをJavaScriptクライアントに返します。
  4. クライアントは暗号化されたPINを顧客に送信します。

あなたの同僚は良い推薦をしました！Amazonは最高のRESTAPI実装の1つです。

また、私のアイデアを確認してください： https ://stackoverflow.com/questions/15418764/looking-for-feedback-on-my-rest-style-api-authentication-design-and-two-factor-a 。

于 2013-03-15T12:57:59.753 に答える