哪种machineKey配置更好？

Question

我正在研究我的web应用程序安全性，我想知道我是否使用了以下内容：

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

在我web.config中，现在第一个用户向我的站点发送第一个请求，此时将创建validationKey，在第二个用户发送第二个请求后，现在是否会再次创建validationkey？

所有用户的验证密钥都是相同的吗？

该配置与此配置之间的区别是什么？

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

使用哪一个更好？

Answer 1

AutoGenerate意味着您的密钥是自动生成一次，然后存储(由本地安全机构服务)-换句话说，它不会在两次请求之间更改-事实上，它永远不应该在同一台机器上更改。

IsolateApps意味着每个应用程序(主要是ETA:见下文)都有自己的验证/解密密钥-而不是机器上的所有应用程序共享一个密钥。尽管如此，密钥还是会在第一次需要时生成并存储，并将在所有后续请求中重用。

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

然而，如果您的应用程序托管在web场、云中、集群等上-其中请求可能由不同的机器处理，您需要对所有这些机器使用相同的密钥-因此在您的第二个示例中需要预先生成的密钥。请记住，您需要自己生成这些代码(并正确生成它们)，而不是重用别人的代码。

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

IIS：为了避免链接损坏，这里是上面链接的概要:IIS7和更高版本在管理器UI中包括机器密钥生成:在您的网站的Machine Key下(在ASP.NET部分)，您可以在actions面板中找到一个Generate Keys操作。这将使用RNGCryptoServiceProvider为您生成解密和验证密钥。

(曾几何时，显然SQLMembershipProvider会抱怨自动生成的键-但只是为了避免上述问题，如果应用程序最终不应该托管在一台服务器上)。

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

如果您的应用程序托管在一台服务器上，请使用AutoGenerate,IsolateApps

• If
• 如果您的应用程序位于web场/云服务/群集网络上:使用手动生成的密钥。

(在第二个示例中，您还指定了" AES“作为解密算法，但是因为AES是缺省算法，所以这两种算法没有区别)。

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

问题应该是，你为什么不这样做呢？默认情况下，它处于打开状态。原因是一个没有密钥的主机托管了多个应用程序，每个应用程序都会得到相同的密钥，如果你不能控制所有的应用程序(例如一个共享主机)，这不是最好的方案。

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

这就给你留下了(基本上)相当于128位AES而不是192位AES的解密密钥。类似地，验证密钥将从256比特的熵减少到192比特。

免责声明：以下段落在密码学中是一件危险的事情，所以如果您正在进行安全关键工作，尤其是如果您要将密钥用于未来十年后具有信息价值的数据，请进一步研究它，而不要相信它。

无论如何:如果你不知道上述熵减少的含义，这些含义不太可能会咬你一口。在2017年，使用AES和验证密钥(散列)的192位熵的128位安全性已经超过了“足够好”。(这就是为什么一开始就没有完整的文档记录)。(更新结束)