在ASP.Net MVC中使用ASP.Net身份验证有什么好处吗?

alc*_*cal 2 asp.net authentication asp.net-mvc forms-authentication asp.net-membership

过去几天我一直在研究这个问题.

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

鉴于没有服务器控件,并且需要创建自定义membershipProvider,使用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这样的大公司可以推出一些体面的东西.

Tho*_*mas 6

创建安全身份验证系统的首要规则之一是您不应该尝试自己构建框架.有许多陷阱很容易被忽视.所以,我会说,除非有一个压倒性的理由不这样做,你应该使用像MembershipProvider这样的现有框架.

要列出"好处",需要列出FormsAuthentication类所采用的所有安全措施,这是一个很长的列表.在我的头顶,我可以想一些:

  1. 密码哈希
  2. 防止SQL注入
  3. 保护存储身份验证票证的cookie
  4. 使用和存储票证而不是在cookie中说出用户名.
  5. 检查每个页面以确保用户已通过身份验证
  6. 当前用户的IPrincipal和IIdentity的人口
  7. 登录后重定向(授予功能)
  8. 处理失败的登录尝试
  9. 锁定和解锁用户
  10. ActiveDirectory集成
  11. 能够轻松设置和更改密码长度和复杂性要求.
  12. 腌制(来自Hightechrider)....