asp.net-mvc-4 - 哪个machineKey配置更好？

Question

我正在研究Web应用程序的安全性，并想知道是否使用此功能:

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

在我的web.config中，现在第一个用户向我的站点发送第一个请求，并且这次将创建validateKey，在第二个用户发送第二个请求之后，现在将再次创建validationkey，或者是什么？

这些验证 key 是否适用于所有用户？

这个配置和这个之间有什么区别？

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

哪个更好用？

Answer 1

AutoGenerate意味着您的 key 会自动生成一次，然后(由本地安全机构服务)存储(换句话说，它不会在请求之间更改)-实际上，它永远不应在同一台计算机上更改。
IsolateApps意味着每个应用程序(ETA:大多数情况下，请参见下文)都具有自己的验证/解密 key -而不是计算机上的所有共享单个 key 的应用程序。但是仍然会生成 key ，并在第一次需要它时将其存储，并将其用于所有后续请求。

2017年更新:ASP.NET 4.5添加了IsolateByAppId，与IsolateApps相比，它添加了进一步的隔离。 IsolateApps基于每个应用程序的虚拟目录路径为其创建一个不同的 key 。这意味着，如果同一台服务器上的两个应用程序具有相同的虚拟路径(例如/)，仅通过托管在不同的端口或主机名上进行区分，即使启用了IsolateApps，它们仍将获得相同的 key 。 IsolateByAppId将基于应用程序的AppDomainAppID创建不同的 key 。 (更新结束)

但是，如果您的应用程序托管在Web场，云，群集等中-可能由不同的机器处理请求，则所有这些机器的 key 都必须相同-因此第二个示例中的预生成 key 。请记住，您需要自己生成(并正确生成)它们，而不是重用别人的。

Here's an easy way to generate the keys with IIS 7

ETA:为避免链接腐烂，下面是上面链接的摘要:IIS 7和更高版本在IIS管理器UI中包括了机器 key 生成:在网站的Machine Key下(位于ASP.NET部分)，您会找到操作面板中的Generate Keys操作。这使用RNGCryptoServiceProvider为您生成解密和验证 key 。

(从前，很显然SQLMembershipProvider会提示自动生成的 key -但这仅仅是为了避免如果应用程序最终不托管在单个服务器上，则可以避免上述问题)。

如果上述情况不适用于您，Microsoft建议使用默认值-即:

如果您的应用程序托管在单个服务器上:使用AutoGenerate,IsolateApps

如果您的应用程序位于Web场/云服务/群集网络上:使用手动生成的 key 。

(在第二个示例中，您还将解密算法指定为“AES”，但是由于AES是默认设置，因此两者之间没有区别)。

2017年更新:为什么要使用IsolateApps(和/或IsolateByAppId)？

问题实际上应该是，为什么不呢？默认情况下它是打开的。原因是没有该主机并托管多个应用程序的主机，如果您不控制所有应用程序(例如共享主机)，则每个应用程序都将获得相同的 key ，这不是最佳方案。

它有缺点吗(除了对Web场/云/群集无用)？是的，有点。 IsolateApps会将dncryption key 的熵减少32位(从192位减少到160位)，因为该 key 的32位将是您的虚拟目录的哈希，攻击者已知该哈希(例如，如果您的应用程序位于域的根，这32位将是 4e ba 98 b2。 IsolateByAppId将其进一步减少了32位，达到128位。

剩下的(基本上)相当于解密 key 的128位AES，而不是192位AES。类似地，验证 key 将从256位的熵减少到192位。

免责声明:下一段在密码学中是很危险的事情，因此，如果您正在执行安全性至关重要的工作，请不要对其进行进一步研究而不是信任它-尤其是如果您正在对信息值(value)超出范围的数据使用 key 下个十年。

无论如何:如果您不知道上述熵降低的含义，那么这些含义就不太可能咬您。在2017年，具有AES的128位安全性和用于验证 key (哈希)的192位熵是“足够好”的条件。 (因此，为什么一开始没有对此进行全面记录)。 (更新结束)