我正在研究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" />
哪个更好用?
最佳答案
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
(在第二个示例中,您还将解密算法指定为“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位熵是“足够好”的条件。 (因此,为什么一开始没有对此进行全面记录)。 (更新结束)
关于asp.net-mvc-4 - 哪个machineKey配置更好?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18388076/