经过大量关于 EnableViewStateMac 的阅读以及将来在.NET框架中删除的可能性之后，我仍然想知道为什么这是一个设置为false的选项。
我知道你应该从不将其设置为false，但是谁决定创建该选项？如果有人真的想过它，那么为什么会将它设置为假？？
为什么你可以选择启用不安全感？
答案 0 :(得分：3)
这个开关是在我加入ASP.NET团队之前创建的，但我自己很好奇，并花了一些时间来探索旧的bug数据库。据我所知，引入它有两个主要原因。
该交换机被认为可能带来性能优势。在.NET Framework的早期预览中（真的是1.0 alpha），计算MAC确实很慢。这在1.0达到RTM之前就已得到修复，因此性能差异可以忽略不计。然而，损坏已经完成：种子被种植在早期的开发商和＃39;请注意，在某些情况下，为了提高性能，需要禁用MAC。这也引发了一系列MSDN文章，这些文章表明，禁用MAC可以提高性能，而且我仍然（在2014年！）找到并删除这些文章。
在Web场环境中，＆lt; machineKey＆gt;需要同步。不幸的是，我们不能轻松安全地生成机器密钥。因此，在ASP.NET测试的早期阶段，交换机的存在允许测试人员为服务器场部署做简单的事情，而不是农场部署的正确事情。我们今天仍在与此斗争：大多数开发人员使用不安全的在线机器密钥生成器。我正在与Visual Studio团队合作，以便更轻松地生成和保护机器密钥。
当时，人们认为，如果禁用MAC，可能发生的最糟糕的事情是你可以对网站进行XSS。结果证明这是一个不正确的评估。
最后，它的删除不再只是一种可能性。它已在我们的本地源存储库中删除。我们在世界上发布的下一个.NET Framework更新会在其中包含此有效负载，但我没有时间表来确定何时可能。我们只是坐在触发器上等待批准。 ：）
答案 1 :(得分：1)
最初在asp时期，HTML页面曾经被发布到完全不同的asp页面。这种类似的编码方法现在称为跨页面发布。 ViewState特定于页面，因此如果您尝试将asp.net页面发布到另一个asp.net页面，则viewstate会有所不同。现在在这种情况下，如果你有EnableViewStateMac（这意味着你想验证viewstate的完整性）设置验证将失败并导致错误。因此人们会禁用viewstatemac，以便他们可以继续以旧方式编程，Microsoft继续提供此功能以支持旧代码。
但正如您已经提到的，这是一个巨大的安全风险，为各种攻击打开您的应用程序。