<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" />
哪一个更好用？
解决方法
IsolateApps意味着每个应用程序(ETA：主要是,见下文)都有自己的验证/解密密钥 – 而不是机器上的所有应用程序共享一个密钥.但仍然会生成密钥,然后在第一次需要时进行存储,并将重新用于所有后续请求.
2017年更新：ASP.NET 4.5添加了IsolateByAppId,与IsolateApps相比,它增加了进一步的隔离. IsolateApps根据每个应用程序的虚拟目录路径为其创建不同的密钥.这意味着如果同一服务器上的两个应用程序具有相同的虚拟路径(例如/),仅通过托管在不同的端口或主机名上进行区分,即使使用IsolateAppsenabled,它们仍将获得相同的密钥. IsolateByAppId将根据应用程序的AppDomainAppID创建不同的密钥. (更新结束)
但是,如果您的应用程序托管在Web场,云端,群集等中 – 其中请求可能由不同的计算机处理,则您需要所有这些计算机的密钥相同 – 因此预先第二个例子中生成的键.请记住,您需要自己生成这些(并正确生成它们),而不是重复使用其他人.
Here’s an easy way to generate the keys with IIS 7
ETA：为避免链接损坏,这里是上面链接的概要：IIS 7及更高版本包括IIS管理器UI中的机器密钥生成：在您的网站的机器密钥下(在ASP.NET部分中找到),您将找到在操作面板中生成密钥操作.这使用RNGCryptoServiceProvider为您生成解密和验证密钥.
(曾几何时,显然sqlMembershipProvider会抱怨自动生成的密钥 – 但只是为了避免上述问题,如果应用程序最终没有托管在单个服务器上).
如果上述情况不适用于您,Microsoft建议使用默认值 – 即：
>如果您的应用程序托管在单个服务器上：使用AutoGenerate,IsolateApps
>如果您的应用程序位于Web场/云服务/群集网络上：使用手动生成的密钥.
(您还在第二个示例中将“AES”指定为解密算法,但由于AES是默认值,因此两者之间没有区别).
2017年更新：为什么我要使用IsolateApps(和/或IsolateByAppId)？
问题应该是,你为什么不呢？它默认开启.原因在于没有它并托管多个应用程序的主机,如果您无法控制所有应用程序(例如共享主机),则每个应用程序都会获得相同的密钥,这不是最佳方案.
它是否有缺点(除了对Web场/云/集群没用)？是的,有点. IsolateApps会将dncryption密钥的熵减少32位(从192位减少到160),因为密钥的32位将是您的虚拟目录的哈希值,攻击者知道该哈希值(例如,如果您的应用程序位于域的根,32位将是4e ba 98 b2.IsolateByAppId将其进一步减少32位到128位.
这使得你(基本上)相当于128位AES而不是192位AES用于解密密钥.类似地,验证密钥将从256位的熵减少到192位.
免责声明：以下段落在密码学中是一个危险的事情,所以如果你正在进行安全关键工作,那么进一步研究它而不是相信它 – 特别是如果你使用密钥来获取信息价值超过下一个十年的数据.
无论如何：如果你不知道上述熵减少的影响,这些影响不太可能让你感到困惑.对于验证密钥(哈希),使用AES和192位熵的128位安全性在2017年超过“足够好”. (因此,为什么首先没有详细记录这一点). (更新结束)
