asp.net-mvc-4 - どの machineKey 設定が優れていますか?

Question

Web アプリケーションのセキュリティに取り組んでおり、これを使用しているかどうかを知りたい:

 <machineKey validationKey="AutoGenerate,IsolateApps" 
 compatibilityMode="Framework45"  decryptionKey="AutoGenerate,IsolateApps" 
 validation="SHA1"/>

私のweb.configで、最初のユーザーが最初のリクエストをサイトに送信し、この間にvalidationKeyが作成され、2番目のユーザーが2番目のリクエストを送信した後、validationkeyが再度作成されますか？

すべてのユーザーに対してこれらの検証キーは同じですか?

その設定とこれの間の違いは何ですか？

<machineKey compatibilityMode="Framework45"  
 validationKey="37BAD4B702C65CF39B1ED514AC4B3D88990DDF784AA0895659
 B528ED95F8CA0A9CD1AF5ED92A2599362684CB8D204AC30D07E6BF0CF65194A5129" 
 decryptionKey="B450FB3271C49E6BA89A0C5C8D06B61875BCE4916A40474ED" 
 validation="SHA1" decryption="AES" />

どちらを使うのが良いですか？

Answer 1

AutoGenerateは、キーが一度自動生成され、(Local Security Authority サービスによって) 保存されることを意味します。つまり、キーは要求間で変更されません。実際、同じマシン上で変更されることはありません。

IsolateAppsこれは、マシン上のすべてのアプリケーションが 1 つのキーを共有するのではなく、各アプリケーション (ETA:ほとんどの場合、以下を参照) が独自の検証/復号化キーを取得することを意味します。それでも、キーは生成され、最初に必要になったときに保存され、その後のすべてのリクエストで再利用されます。

更新 2017 : ASP.NET 4.5 が追加されIsolateByAppId、.NET と比較してさらに分離が追加されましたIsolateApps。仮想ディレクトリ パスに基づいて、IsolateAppsアプリごとに異なるキーを作成します。これは、同じサーバー上の 2 つのアプリが同じ仮想パス (例: ) を持ち、異なるポートまたはホスト名でホストされていることによってのみ区別される場合、それらは有効であっても同じキーを取得することを意味します。アプリケーションの に基づいて異なるキーを作成します。(更新終了)/IsolateAppsIsolateByAppIdAppDomainAppID

ただし、アプリケーションが Web ファーム、クラウド、クラスターなどでホストされている場合 - 要求が異なるマシンで処理される可能性がある場合、それらすべてのマシンで同じキーを使用する必要があります。 -2番目の例でキーを生成しました。これらは、他の人のものを再利用するのではなく、自分で生成する (そして適切に生成する) 必要があることを覚えておいてください。

IIS 7 でキーを生成する簡単な方法を次に示します。

ETA:リンクの腐敗を避けるために、上記のリンクの概要を以下に示します: IIS 7 以降には、IIS マネージャー UI にマシン キーの生成が含まれています: Machine KeyWeb サイト (ASP.NET セクションにあります) の下にGenerate Keysアクションがあります。アクションパネル。これは、RNGCryptoServiceProvider を使用して、復号化および検証キーを生成します。

(むかしむかし、 はSQLMembershipProvider自動生成されたキーについて不平を言うようでしたが、アプリケーションが単一のサーバーでホストされない場合に上記の問題を回避するためだけです)。

上記の状況が当てはまらない場合、Microsoft は既定値を使用することをお勧めします。

• アプリケーションが単一のサーバーでホストされている場合:AutoGenerate,IsolateApps
• アプリケーションが Web ファーム/クラウド サービス/クラスター化されたネットワーク上にある場合: 手動で生成されたキーを使用します。

(2 番目の例では、復号化アルゴリズムとして「AES」も指定していますが、AES がデフォルトであるため、2 つの違いはありません)。

2017 年更新: IsolateApps (および/または IsolateByAppId) を使用する必要があるのはなぜですか?

質問はむしろ、なぜあなたはそうしないのですか? デフォルトではオンになっています。その理由は、それがなく複数のアプリケーションをホストしているホストでは、すべてのアプリケーションを制御できない場合 (共有ホストなど)、すべてのアプリケーションが同じキーを取得するためです。これは最良のシナリオではありません。

欠点はありますか (Web ファーム/クラウド/クラスターで役に立たないこと以外に)? ええ、多少。IsolateAppsdncryption キーのエントロピーを 32 ビット (192 ビットから 160 に) 削減します。これは、キーの 32 ビットが仮想ディレクトリのハッシュであり、攻撃者に知られているためです (たとえば、アプリがドメインのルート、これらの 32 ビットは4e ba 98 b2.IsolateByAppIdさらに 32 ビット減らして 128 ビットにします。

これにより、(基本的に) 192 ビット AES ではなく 128 ビット AES の復号化キーが得られます。同様に、検証キーは 256 ビットのエントロピーから 192 ビットに削減されます。

免責事項:次の段落は、暗号化において言うのは危険なことです。したがって、セキュリティ クリティカルな作業を行っている場合、特に次の 10 年を超えて情報価値のあるデータのキーを使用している場合は、それを信頼するのではなく、さらに調査してください。 .

とにかく、上記のエントロピー削減の意味がわからない場合、それらの意味があなたを噛む可能性は低いです. AES による 128 ビット セキュリティと検証キー (ハッシュ) の 192 ビット エントロピーは、2017 年には「十分」以上のものです。(したがって、そもそもこれが完全に文書化されていない理由)。(更新終了)