将 ASP.Net 身份验证与 ASP.Net MVC 一起使用有什么真正的好处吗？答案

【问题标题】：Is there any real benefit to using ASP.Net Authentication with ASP.Net MVC?将 ASP.Net 身份验证与 ASP.Net MVC 一起使用有什么真正的好处吗？
【发布时间】：2010-04-17 10:49:00
【问题描述】：

过去几天我一直在认真研究这个问题。

我们正在开发一个需要支持 100,000 多个用户的 ASP.Net MVC 站点。我们希望让它保持快速、可扩展和简单。我们有自己的 SQL 数据库表，用于 user 和 user_role 等。我们没有使用服务器控件。

鉴于没有服务器控件，并且需要创建自定义的 membersProvider，使用 ASP.Net Auth/Membership 还有什么好处？

另一种选择似乎是创建自定义代码以将 UniqueID CustomerID 放入 cookie 并使用它进行身份验证。或者，如果我们对嗅探器有疑虑，我们也可以加密 cookie。

在这种情况下（MVC 和客户数据在我们自己的表中）使用 ASP.Net auth/membership 框架是否有任何真正的好处，或者完全自定义的解决方案是否可行？

更新：我发现一个人（马特布里格斯）似乎得出了一些与我相同的结论：这来自此链接：http://webcache.googleusercontent.com/search?q=cache:Xm1-OrRCZXIJ:mattcode.net/posts/asp-net-membership-sucks+asp.net+membership+sucks&hl=en&gl=us&strip=1

ASP.net 会员资格很差设计的 API 不安全盒子，保养得不好，而且给开发者一种错误的感觉安全。认证是一个周末如果你不建立一个项目框架，但仍然是大多数.net 开发者盲从官方 API，假设主要像MS这样的公司可以推出体面的东西。

【问题讨论】：

另见stackoverflow.com/questions/440568/…

标签： asp.net asp.net-mvc authentication asp.net-membership forms-authentication

【解决方案1】：

创建安全身份验证系统的首要规则之一是您不应该尝试自己构建框架。有许多容易被忽视的陷阱。因此，我想说除非有压倒性的理由不这样做，否则您应该使用现有的框架，例如 MembershipProvider。

要列出“好处”，需要列出 FormsAuthentication 类采取的所有安全措施，这是一个很长的列表。在我的脑海中，我能想到一些：

密码哈希
防止 SQL 注入
保护存储身份验证票的 cookie
使用和存储票证，而不是在 cookie 中说出用户名。
检查每个页面以确保用户已通过身份验证
当前用户的 IPrincipal 和 IIdentity 的数量
登录后重定向（授予功能）
处理失败的登录尝试
锁定和解锁用户
ActiveDirectory 集成
能够轻松设置和更改密码长度和复杂性要求。
加盐（来自 Hightechrider） ....

【讨论】：

你在说什么具体的陷阱？我正在寻找该框架提供的明确、具体的好处。
@alchemical - 我更新了我的帖子。 Microsoft 竭尽全力提供一个功能丰富、相对简单的库来进行身份验证。为什么要重新发明轮子？
一个很好的检查清单，但没有什么难的。添加#12 - 盐渍。当然，它还提供#13 - “能够在数据库中存储未加密的密码”，这真是个坏主意。
@Hightechrider - 开箱即用，我相信默认设置是使用哈希作为密码。即，您必须竭尽全力使其不安全。
@alchemical - 您在顶部的链接已损坏。

【解决方案2】：

在阅读了 ASP.NET Membership 提供程序中的所有存储过程后，我编写了自己的代码。这并不难，而且您在一天结束时拥有更多的控制权。

如果您喜欢 XML 配置、角色的弱类型字符串、默认情况下不安全、随机 web.config 文件散布在您的目录中，而不是在您的页面类上使用干净的标记界面来表示“不需要帐户”、多个数据库命中对于单次登录，未从您当前的 ObjectContext/DataContext 加载的用户对象以及动态更改提供程序的能力（哇哦，谁使用它？！）去内置的。

如果没有，请自己构建，但如果这样做，请确保添加盐并加密您的密码，并请做一个适当的加密 cookie。

【讨论】：

【解决方案3】：

只是为了澄清一个潜在的误解，使用无论是否加密的客户 ID 都极易受到嗅探器的攻击。相反，您要做的是在成功验证时创建一个登录票，并将该 ID 存储在 cookie 中。这不会保护嗅探器不窃取会话，但至少会话（最终）会过期，而客户 ID 不会。

【讨论】：

我明白了，所以您建议增加一层抽象。我认为这是合理的，实施起来也不算太糟糕。 Membership 不是将 UserID 存储在 cookie 中吗？来自 MSDN：“您可以在 cookie 中存储一个值，例如用户名和上次访问。”
它可能是，你可以。不要使用它来确定用户是否经过身份验证，这一点很重要。如果你想说“Hello ”，那么黑客欺骗值是没有危险的。另一方面，如果您尝试if(IsAdmin(Username))，您可能会遇到麻烦。

【解决方案4】：

如果您希望拥有自己的存储空间，您可以实现自己的成员资格提供程序（如您所述）。一个优点是您可以通过 IIS 的 .NET 用户配置工具来管理成员资格。

最大的优势是其他人已经说过的；为什么要重新发明轮子？

如果您使用 MVC 实现自己的自定义登录 UI，则在切换到不同的成员资格提供程序时也可以重用。

【讨论】：

我们不会使用用户配置工具，因为会有大量成员，任何成员管理工具都必须是自定义的。关于轮子，你开牛车还是凯美瑞上班？ :)
如果您可以换掉会员提供者，它仍然很有用，例如用于测试目的。当然，实现你自己的提供者模型并不是那么复杂。只需要把饼干做对。不要忘记 cookieless 身份验证 ASP.NET 也支持..
可以在没有任何形式的 Membership Provider 的情况下使用 FormAuthentication 位和 cookie 部分：stackoverflow.com/questions/2077858/…
这不仅仅是“为什么要重新发明轮子”。如果这就是你如何用千篇一律的方法来构建你的应用程序，那么你可能会说你不能编码。如果它是一个很好的实现，你可以抓取并运行它以减少你的时间和代码，但是这个会员提供程序对于大型网站来说完全是垃圾。
@CoffeeAddict 感谢近 2 年后的反对票。问题是，如果有的话，价值是多少。我试图找到一些。我同意会员提供者是垃圾。与其说是身份验证机制，这很好，而且您可以在没有会员提供者的情况下使用。

【解决方案5】：

您可以自定义构建自己的提供程序。在幕后，Membership 提供程序使用与您将编写的相同的 FormsAuthentication 实现。无论如何，我已经读到您将面临的有关性能的主要问题将与检索数据的 SQL SERVER 存储过程有关。在 Omar Al Zabir 的一本关于构建门户系统的书中，他提到了对存储过程的一些改进，这些改进可以提高性能。

【讨论】：

所以...Omar 的这篇文章在哪里，请至少发布它。