50

モバイル コンパニオン (最初は iPhone のみ) を持つ Web サイトを設計しています。Web サイトは ASP.Net MVC 3 アプリケーションになります。また、サービスを iPhone アプリケーションに公開するための ASP.Net Web API サイト (MVC 4) も用意します。iPhone アプリには、ユーザーからユーザー名とパスワードを取得し、それを JSON ヘッダーで Web API に送信するための独自のフォームがあります。

後からではなく、最初からセキュリティを考えたい。私は決してセキュリティの専門家ではありません。私は、Web サービスからのモバイル アプリケーション クライアントの認証を他の人がどのように処理しているかを確認するために、かなりの調査を行いました。サードパーティの oAuth に接続する必要のない適切なソリューションを思いついたと思います。

あらゆる意見、アドバイス、批判、一般的な WTF を提供していただければ幸いです。:)

私の最大の懸念は次のとおりです。

  1. Web API への呼び出しが承認されていることを確認する
  2. リプレイ攻撃のリスクを最小限に抑える (したがって、以下の呼び出しのタイムスタンプ)

iPhone アプリは次のように開発されます:
2 つの文字列が iPhone アプリにハードコードされます (すべてのユーザーに対して同じ値):

  1. アプリケーション ID
    これは、Web API にアクセスしているクライアントのタイプ (iPhone、Android、Windows phone など) を識別するために使用される文字列です。

  2. アプリケーションのハッシュ ソルト
    これは、ユーザーに依存しない要求のハッシュをソルトするために使用される文字列です。

2 つの文字列が iPhone アプリのローカル データベースに保存されます (各ユーザーに固有の値)。

  1. API ユーザー アクセス トークン
    これは、認証の成功時に Web API によってクライアントに提供される文字列 (トークン) であり、クライアントは各要求でユーザー名とパスワードを送信せずに Web API にアクセスできます。
  2. ユーザーのハッシュ ソルト
    これは、確立されたユーザー アカウントに対して行われた要求のハッシュをソルトするために使用される文字列です。



iPhone は次の方法で Web API を呼び出します。

API メソッド: アカウントの作成
クライアントの送信:

  • 新しいアカウント データ (ユーザー名、パスワード、姓、名など)
  • アプリケーションID
  • UTC タイムスタンプ
  • UTC タイムスタンプのハッシュ + アプリケーションのハッシュ ソルトでソルトされたアプリケーション ID

API の戻り値:

  • 新規ユーザーのハッシュ ソルト

    ここでの考え方は、アカウントを作成するときに、アプリケーションのハードコードされたソルトを使用できるということです。ソルトが (逆コンパイルまたはその他の手段によって) 流出したとしても、大きなセキュリティ リスクではないからです。

    ただし、ユーザーのデータにアクセスして変更するメソッドについては、そのユーザーのみが所有するソルトを使用するので、攻撃者が他のユーザーになりすますためにソルトを使用することはできません。


API メソッド: アカウントの取得
(Web サイトで作成されたがまだ iPhone で同期されていないアカウントのユーザーのハッシュ ソルトを取得するために使用されます。そのユーザー名のレコードはありません。)

クライアントは次を送信します。

  • ユーザー名
  • パスワード (アプリケーションのハッシュソルトでハッシュ化)
  • アプリケーションID
  • UTC タイムスタンプ
  • UTC タイムスタンプのハッシュ + アプリケーションのハッシュ ソルトでソルトされたアプリケーション ID

API の戻り値:

  • 既存ユーザーのハッシュソルト


API メソッド: ログイン (認証)
クライアント送信:

  • ユーザー名
  • パスワード (ユーザーのハッシュソルトでハッシュ化)
  • アプリケーションID
  • UTC タイムスタンプ
  • UTC タイムスタンプのハッシュ + ユーザーのハッシュソルトでソルトされたアプリケーション ID

API の戻り値:

  • API ユーザー アクセス トークン


API メソッド: 任意のコマンド (つまり、投稿の作成、プロファイルの更新、メッセージの取得など...)
クライアントが送信するもの:

  • コマンドデータ
  • API ユーザー アクセス トークン
  • アプリケーションID
  • UTC タイムスタンプ
  • UTC タイムスタンプのハッシュ + アプリケーション ID + ユーザーのハッシュ ソルトでソルトされた API ユーザー アクセス トークン
4

3 に答える 3

4

私はasp.net mvc 4.0/web apiの基本メンバーシップを使用してそれを行いました。役に立つかもしれません。

はい、SSL を使用してください。

https://github.com/aamir-poswal/Mobile-Apps-Authentication-Authorization-ASP.NET-WEB-MVC-4.0

于 2013-08-24T10:17:39.913 に答える
4

VS 2013 では、「Asp MVC SPA アプリケーション」テンプレートを使用して、ログイン時に Oauth2 トークン ベアラーを生成し、[Authorize] 属性を使用して WebApi コントローラー呼び出しを承認する実用的な実装を生成できます。これは、Membership と Entity Framework を使用して、ユーザーとハッシュをローカルの SQL Server に格納します。不要な asp mvc 部分を削除し、WebApi の Auth 部分を保持するだけです。詳細はこちら: http://msdnrss.thecoderblogs.com/2013/09/understanding-security-features-in-the-spa-template-for-vs2013-rc/

于 2013-11-20T19:56:30.417 に答える
3

私の提案

  1. 認証と承認。2 つの異なるサーバーでビルドします (一部のプロジェクトでは 3 つも使用しました)。リバース プロキシ サーバーはこれに非常に適しています。一方のサーバーで認証し、もう一方のサーバーで承認します。

これは、Web API を使用するモバイル セキュリティで必要と考えられる最も重要なステップです。

  1. すべてをカプセル化します。

  2. すべての安全な情報に SSL を使用します。私の場合、私はそれをすべてに使用します。

  3. タイムスタンプには、承認できる適切な時間を選択してください。ネットワークスニファーがパケットにアクセスできるため、アプリが遅くなったり、長くなりすぎたりするため、これを非常に短くしないでください。

3 サーバー アーキテクチャが必要な場合 リクエストには、(サーバー 1 から) アクセス キーを生成するために使用するアプリケーション キーもあります。このアクセス キーはリクエストを認証します。認証が成功した後 (サーバー 2 から)、そのキーを使用して別のサーバー (サーバー 3) からのリクエストを承認できます。

あなたが言及した要求は標準的な規範です。本当に問題はありません。

于 2012-08-09T20:33:23.567 に答える