web-dev-qa-db-ja.com

モバイル(iPhone)アプリからASP.Net Web APIへのリクエストの認証(設計でフィードバックがリクエストされました)

私はモバイルコンパニオン(最初は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で同期されていないアカウントのユーザーのハッシュソルトを取得するために使用されます。これは、ユーザーがiPhoneでログインを試み、iPhoneがそのユーザー名のレコードはありません。)

クライアントからの送信:

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

APIの戻り値:

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


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

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

APIの戻り値:

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


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

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

私の提案

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

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

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

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

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

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

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

3
S.P.

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

うん、確かにSSLを使う

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

4
aamir sajjad

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

4
Johan O