9

私は Web アプリケーションを持っており、Google が Google アカウントに追加したものと同様に、セキュリティを強化するために安全なサインオンを追加する任務を負っています。

使用事例

基本的に、ユーザーがログインするときに、ユーザーが以前にこのコンピューターを承認したかどうかを検出する必要があります。コンピュータが認証されていない場合、ユーザーはワンタイム パスワードを (電子メール、SMS、または電話で) 送信され、入力する必要があります。ユーザーは、このコンピュータを記憶することを選択できます。Web アプリケーションでは、許可されたデバイスを追跡し、ユーザーがそのデバイスから最後にいつ/どこでログインしたかを確認し、必要に応じてデバイスの許可を解除します。

非常に軽いタッチ (つまり、クライアント側のソフトウェアのインストールを必要としない) で、Safari、Chrome、Firefox、および IE 7+ (残念ながら) で動作するソリューションが必要です。十分なセキュリティを提供する x509 セキュリティを提供しますが、x509 を使用できない、または使用しない顧客向けのソリューションが必要です。

私の意図は、Cookie を使用して認証情報を保存することです (または、ローカル ストレージを使用して、フラッシュ Cookie に分解し、次に通常の Cookie を使用する可能性があります)。

最初の赤面

最初の安全なサインオンのシーケンス図 2 つの個別の値 (ローカル データまたは Cookie) を追跡します: 安全なサインオン トークンとデバイス トークンを表すハッシュ。どちらの値も Web アプリケーションによって駆動 (および記録) され、クライアントに指示されます。SSO トークンは、デバイスとシーケンス番号に依存します。これにより、デバイスの認証を効果的に解除し (すべての SSO トークンが無効になります)、シーケンス番号を使用してリプレイを軽減し (効果的ではないため、この質問をしているのです)、ナンスを使用します。

問題

このソリューションでは、だれかが SSO とデバイス トークンをコピーして、別の要求で使用することができます。シーケンス番号は、このような悪用を検出してデバイスの認証を解除するのに役立ちますが、検出と応答は、有効なデバイスと悪意のある要求の両方がアクセスを試みた後にのみ発生します。これは、損害が発生するのに十分な時間です.

HMACを使ったほうがいいような気がします。デバイス、シーケンスを追跡し、ノンス、タイムスタンプ、秘密鍵を使用してハッシュを作成し、ハッシュとそれらの値をプレーン テキストとして送信します。サーバーは (デバイスとシーケンスの検証に加えて) 同じことを行い、比較します。秘密鍵を安全にネゴシエート、交換、および保存できると仮定すると、それははるかに簡単で、はるかに信頼性が高いように思えます。

質問

では、許可されたデバイスの秘密鍵を安全にネゴシエートし、その鍵を安全に保管するにはどうすればよいでしょうか? 少なくとも、ローカル ストレージまたはフラッシュ Cookie を使用して秘密鍵を保存することに同意し、それで十分だと言うことは可能ですか? または、私が説明している脆弱性を軽減するために、元のドラフトにできることはありますか?

4

2 に答える 2

5

説明されているように、システムが提供できる以上のセキュリティを求めているのではないかと思います。簡単に言えば、クライアントを制御できない場合、ご存知のように、無数の (意図しない) 方法で SSO およびデバイス トークンを (誤) 使用する可能性があります。システムの他の部分をどれだけうまく設計しても問題ありません。これがシステムのアキレス腱です。

別の言い方をすれば、説明したシステムでは、クライアントの Web ブラウザにデバイス トークンと SSO トークンを提供するタスクを課し、信頼しています。右？もしそうなら、どうすればこれらのトークンが他のデバイスに移動するのを防ぐことができますか? (以下の緩和戦略を参照してください。)

さて、これを念頭に置いてあなたの質問に正面から答えてください：

「では、許可されたデバイスの秘密鍵を安全にネゴシエートし、その鍵を安全に保管するにはどうすればよいでしょうか?」

これを行っても害はありませんが、上で説明したように役に立ちません。

「少なくとも、ローカルストレージまたはフラッシュ Cookie を使用して秘密鍵を保存することに同意し、それで十分だと言うことは可能ですか?

「十分」とは言えません。「移動トークン」攻撃を明確に伝え、顧客が情報に基づいた決定を下せるようにする必要があります。

「または、私が説明している脆弱性を軽減するために、元のドラフトにできることはありますか?」

ユーザーのインストール ベースとリスクに対する許容度に依存する軽減戦略は確かにあります。

私が考える重要な問題は、あるマシンから別のマシンにトークンを移動する可能性のある人のスキルと能力について考えてみてください。あなたの緩和戦略は、システムのパフォーマンスと使いやすさを低下させることなく、その動作に大きな影響を与えることができますか? 「正直な」ユーザー？

ここにいくつかのアイデアがあります：

  • RSA SecurID などの 2 要素認証を使用できます。これはマシン トークンの移動を妨げるものではありませんが、TFA も一緒に移動する必要があります。

  • これらのトークンのローカル コピーを難読化または非表示にしようとすることはできますが、これはあいまいさだけによるセキュリティのようです。

  • マシンの MAC アドレスを確認できます。デバイス トークンを移動するよりも MAC アドレスを複製する方が難しい場合、これはセキュリティの有用なレイヤーになる可能性があります。

  • これらのトークンへのアクセスを「ロックダウン」する特定のカスタマイズされたブラウザーの使用を要求することができます。これは単なるアイデアです。実用的かどうかはわかりません。

  • マシンが物理的に移動することが想定されていないことがわかっている場合は、ネットワーク プロパティを調べて、マシンが別のネットワークの場所、つまり物理的な場所にあるという証拠を探すことができます。

  • (クライアントではなくサーバー上で) コンピューターの構成情報を照会して保存すると、ある構成のマシンから別の構成のマシンにトークンが移動するかどうかを検出できます。(もちろん、このアプローチでは、マシンがアップグレードされたときに問題が発生します。)

  • ローカル デバイス トークンを保存する代わりに、Web アプリケーションに認証 API を提供するアプリケーションのインストールを要求することができます。このアプリケーションは、ハッキング、ルート アウト、または移動が困難な場所に自分自身を埋め込む可能性があります。(このようにして、このアプリケーションはマシンに「2 要素認証」システムを提供します。)

  • 上記のアイデアに合わせて、またはそれとは別に、別の「phone home」アプリケーションをデバイスにインストールできます。サーバーに時々「チェックイン」します。ネットワークの場所やデバイスの構成が変更されたり、応答が停止したりすると、それに応じてアクセスが拒否される可能性があります。

これが役立つことを願っています。私は自分自身をセキュリティの専門家だとは考えていませんが、設計上の問題について考えるのは楽しいです。https://security.stackexchange.com/で尋ねると、より良い応答が得られる場合があります) 。

于 2012-06-21T03:14:09.243 に答える
1

コンピューターのMACアドレスを取得し、その情報をデータベースに保存するのはどうですか？ご存知のように、MACアドレスはすべてのコンピュータに固有であり、IPアドレスではありません。

Javaアプレットを使用してWebページでMACアドレスを取得する

オンラインで見ると、Webページやアプレットを介してMACアドレスを取得する方法がいくつかあります。

于 2012-06-21T16:10:50.453 に答える