2012-04-30 21 views
2

私は、Jquery POSTや他のアプリケーション(IPad、Androidなど)を介してWebアプリケーションで消費されるサービスを公開するアプリケーションを持っています。私は非常に安全だがまだ十分に速い認証システムを作らなければならない。安らかなWCFサービス認証

私は、ログイン時にアプリケーションに渡されるトークンを作成することを考えました。それは、セッションを期限切れにすることなく、リフレッシュしなければならない特定の時間(例えば30分)の間使用されます。だから私は、トークンをサービスに送り、トークンを生成することを考えました。これは、サーバーが秘密鍵で要求を復号化し、生成されます

  1. ユーザーID

  2. パスワード(両方が公開鍵で暗号化された)

  3. のAppID

を受け付けます特定の時間に有効となるトークン。これは私が秘密鍵を特定の時間(例えば2時間)後にリフレッシュすることを望むので、これは秘密鍵(これは同じで、したがってシステム内の誰かがそれを漏らして誤用する可能性がある)に大きく依存するからです。

質問 - プライベートキーを更新し、現在はトークンが拒否されることはありません発行していることを確認するにはどうすればよい

  1. それ

+0

、それを使用している最後のセッションが期限切れになるまで、古い鍵を保存することができます - キーを意味します最大で約4時間です。 – Jeff

+0

これは秘密鍵(これは同じで、したがってシステム内の誰かがそれを漏らしてそれを悪用する可能性がある)に大きく依存するため、「今すぐどういう意味ですか? –

答えて

5

を行うためのより良い方法は、それを行うための良い方法はありますがありますか?

はい、SSL/HTTPSと呼ばれています。すでにHTTPSを使用している場合、この暗号マジックは必要ありません。 HTTPSを使用していない場合は、すでに設計上安全ではないので、何も思い付きませんが、SSLを再発明するのに手間がかかりません。トランスポートが(HTTPS)

  1. クライアントはプレーンテキストでのユーザ名+パスワードを送信し、認証を要求する安全である場合

    は、だからあなたは何をすべき。

  2. サーバーは、アカウントに格納されている(うまくいけば)ハッシュされたパスワードとユーザー名とパスワードのペアを確認します。
  3. サーバは、静的なAESキーを使用してトークン(暗号化されたアカウントID、有効期限など)で応答します。
  4. クライアントは、認証されたすべての要求に対してトークンを使用します。

簡単です。あなたがGoogleや他の人からページを取るべきである非セキュアデバイス上で使用する資格情報の損失を防ぐために...

を行うことができ

一つ。ユーザーがWebサイトのパスワードを入力するのではなく、Webサーバーにアクセスしてログインさせるようにします。そこから、「デバイスのアクセストークンを生成する」をクリックします。固有のデータ文字列(20文字以上)が生成され、アカウントとともに記録されます。この「代替パスワード」は、あなたのウェブサイトからユーザーが取り消すことができます。

これをより安全にする方法を教えてください。あなたが本当にここに、はるかに良いことができません

はなぜ...

があなたの秘密鍵への攻撃者のアクセスを想定しています。その後、攻撃者はサーバを置き換えたり、ユーザ名とパスワードを盗んでいる途中の人をプレイすることができます。

これを防ぐために、サーバーが公開鍵で暗号化したパスワードを送信するようにPKI交換を検討します。私は中間者のように自分の公開鍵を与えてユーザー名とパスワードにアクセスし、それを選択すればそれを実サーバーに転送することができます。

- または -

あなたはクリアテキストでパスワードの代わりにサーバーに送信されますいくつかの塩+パスワードハッシュを使用し、これを防ぐために試みること。私は中間者として、あなたに塩の固定値を与えて、その塩値の完全な虹のテーブルをあらかじめ計算することができます。今私は再びクリアテキストのすべてのパスワード(よく)を持っています。

- または -

あなたには、いくつかの秘密セッションキーを確立して、すべての通信を署名し、暗号化するためにPKIを使用し、これを防ぐためにしようとします。さて、おなじみの音色... SSL on Wikipediaを参照してください。 ONLY SSLを安全にするものがその秘密鍵の保護であることを理解してください。秘密鍵が失われると、すべてのセキュリティと信頼が失われます。

決勝ノート:

あなたが安全な通信を構築することはできませんいくつかの暗号化キーを保護できずに。

SSLのソフトウェア実装(OpenSSLなど)には何千もの工数が費やされており、実装では脆弱性が絶えず見つかっていることにも注意してください。これを自分で実装し、IISやOpenSSLと同じように安全にするというあなたの希望は、ほぼNILです。それはあなたにDiggではない、それはただの現実です、私はそれをやり遂げることができませんでした。

最後に、私の最終的なアドバイスは、「システム内の誰かがそれを漏らして誤用する可能性がある」という記述についてです。これが本当の問題です。それを修正すると、他のすべてがはるかに簡単になります。サーバー環境を保護することが最優先事項です。あなたが第一にやり遂げることができなければ、あなたの第二の優先順位はあなたの顧客への影響を最小限にするべきです。

いくつかの便利なリンク:#1再

関連する問題