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

发布时间：2020-12-16 04:34:54 所属栏目：asp.Net 来源：网络整理

导读：我正在处理我的Web应用程序安全性,并想知道我是否使用它： machineKey validationKey="AutoGenerate,IsolateApps" compatibilityMode="Framework45" decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/ 在我的web.config中,现在第一个用户向我的

我正在处理我的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" />

哪一个更好用？

解决方法

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

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年超过“足够好”. (因此,为什么首先没有详细记录这一点). (更新结束)

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!