この署名ベースの携帯端末向け認証のセキュリティーは

Question

です。ユーザー名とパスワードが必要なシステムがないアプリを実装しています。私が必要とするのは名前と電話番号です。

シナリオは、このようなものです：

1）ユーザーは、今からユニークUSERキー

3）

2）アプリは私のサーバーに要求を行う初めてのアプリを開いて取得しますアプリが自分のRESTサービスに行うリクエストにも署名が付いています。署名は、実際にはSHA（USERキー：要求Base64Encodedに提供されたデータ）である：

4）サーバも署名

を確認するために、同じハッシュを実行し、私はSSHを使用しない理由

• ない証明書
• のために支払うことを喜んで、私は、パスワードなどの機密データを送信する必要はありませんので、私は、私はちょうど私の自身のWCFのRESTを呼び出すための簡単な方法を必要とする
• それを使用することの利点が表示されません自社アプリからのサービス

私は、ステップ2でUserKeyがクリアテキストになるとセキュリティの流れがあることを理解していますが、これはアプリを最初に開いたときに一度だけ発生します。これはどれくらい危険だと思いますか？

お勧めですか？私に役立つ.NETライブラリがありますか？

Answer 1

実際、このアプローチにはいくつかの問題があります。あなたがサーバーにリクエストを行うたびに中間者がいるとします。たとえば、送信された100パケットを分析することによって、彼はあなたの要求に署名して同様のパターンを認識します。それから彼は自分の要求を偽造し、あなたの署名を追加するでしょう。サーバーはハッシュをチェックします。すべてが問題なく、あなたとあなたの一意のユーザーキーです。しかし、そうではありません。

暗号化には現在、非常に人気があり、厳しいセキュリティサービスを提供する非対称キーという概念があります。主なコンセプトは次のとおりです。サーバーはパブリックとプライベートの2つのキーを生成します。公開鍵はテキストをエンコードするために使用されます。秘密鍵の使用によってのみデコードすることができます。秘密鍵はサーバーが安全な場所に保管します。したがって、サーバーはクライアントにメッセージをエンコードする公開鍵を与えます。二重にすることもできます：クライアントは公開鍵を生成し、それをサーバに渡します。次に、サーバーは鍵を生成し、クライアントの公開鍵で公開鍵を暗号化します。このようにして、中間者が攻撃を行うことはほとんど不可能です。

問題は本当に一般的なので、OAuthを使用してウェブサイトのユーザーを認証することができます。それは安全で、広く使用されています（facebook、g +、twitter、あなたの名前を付けます）。そして既にさまざまな言語で実装されています。

Answer 2

アプリケーション自体とWebサービスの両方を制御するので、何もせずにSSLでこれを行うことができます（現在の方法で問題を解決します）。自己署名入りの証明書を作成してWebサーバーにインストールすることができます。その1つの証明書だけを信頼するようにクライアントアプリケーションのSSLコンテキストを構成します。次に、クライアント側の自己署名証明書を作成し、アプリケーション内にインストールします。相互認証されたSSLを要求するようにサーバーを設定し、自己署名証明書のみがアクセスできるようにします。

完了。あなたのクライアントはあなたの正当なサーバーと話すだけなので、誰もあなたのサーバーを偽装してクライアントと話をすることはできません。サーバーはあなたの正当なクライアントと話します（誰も情報、IDなどを盗むことはできません）。 SSL内で使用されている強力な暗号化技術で保護されています。